[msysGit] [PATCH] Fix checkout of large files to network shares under Windows XP

[Sebastian Schuberth]

This fixes msysGit issue 409, see
http://code.google.com/p/msysgit/issues/detail?id=409

Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
---
compat/mingw.c | 24 ++++++++++++++++++++++++
compat/mingw.h | 3 +++
2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 7ec615c..672d074 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -293,6 +293,30 @@ int mingw_open (const char *filename, int oflags, ...)
return fd;
}

+#undef write
+ssize_t mingw_write(int fd, const void *buf, size_t count)
+{
+ ssize_t written = 0;
+ size_t total = 0, size = count;
+
+ while (total < count && size > 0) {
+ written = write(fd, buf, size);
+ if (written < 0 && errno == EINVAL) {
+ // There seems to be a bug in the Windows XP network stack that
+ // causes writes with sizes > 64 MB to fail, so we halve the size
+ // until we succeed or ultimately fail.
+ size /= 2;
+ } else {
+ buf += written;
+ total += written;
+ if (total + size > count)
+ size = count - total;
+ }
+ }
+
+ return written < 0 ? written : total;
+}
+
#undef fopen
FILE *mingw_fopen (const char *filename, const char *otype)
{
diff --git a/compat/mingw.h b/compat/mingw.h
index 756f3ab..751bb4c 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -178,6 +178,9 @@ int mingw_rmdir(const char *path);
int mingw_open (const char *filename, int oflags, ...);
#define open mingw_open

+ssize_t mingw_write(int fd, const void *buf, size_t count);
+#define write mingw_write
+
FILE *mingw_fopen (const char *filename, const char *otype);
#define fopen mingw_fopen

--
1.7.0.2.msysgit.0.898.gbf4f.dirty




--
Subscription settings: http://groups.google.com/group/msysgit/subscribe?hl=en

[Johannes Schindelin]

Hi,

On Mon, 19 Apr 2010, Sebastian Schuberth wrote:

> This fixes msysGit issue 409, see
> http://code.google.com/p/msysgit/issues/detail?id=409
>
> Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>

With a slightly more stand-alone commit message, I think it makes sense to
push to 4msysgit.git's devel right away.

Ciao,
Dscho

[Sebastian Schuberth]

On Mon, Apr 19, 2010 at 17:00, Johannes Schindelin
<Johannes....@gmx.de> wrote:

> On Mon, 19 Apr 2010, Sebastian Schuberth wrote:
>
>> This fixes msysGit issue 409, see
>> http://code.google.com/p/msysgit/issues/detail?id=409
>>
>> Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
>
> With a slightly more stand-alone commit message, I think it makes sense to
> push to 4msysgit.git's devel right away.

I didn't want to repeat myself in the commit message as I already
explain the details in a source code comment, and I preferred a
comment because anyone stumbling across that piece of code would
probably ask himself / herself what this work-around is good for.

--
Sebastian Schuberth

[Johannes Schindelin]

Hi,

On Mon, 19 Apr 2010, Sebastian Schuberth wrote:

> On Mon, Apr 19, 2010 at 17:00, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> > On Mon, 19 Apr 2010, Sebastian Schuberth wrote:
> >
> >> This fixes msysGit issue 409, see
> >> http://code.google.com/p/msysgit/issues/detail?id=409
> >>
> >> Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
> >
> > With a slightly more stand-alone commit message, I think it makes sense to
> > push to 4msysgit.git's devel right away.
>
> I didn't want to repeat myself in the commit message as I already
> explain the details in a source code comment, and I preferred a
> comment because anyone stumbling across that piece of code would
> probably ask himself / herself what this work-around is good for.

Why not just copy-past it, then? At least for occasional history browsers
like me, a commit message is what I read mostly.

Ciao,
Dscho

[Sebastian Schuberth]

On Mon, Apr 19, 2010 at 17:10, Johannes Schindelin

<Johannes....@gmx.de> wrote:

>> > On Mon, 19 Apr 2010, Sebastian Schuberth wrote:
>> >
>> >> This fixes msysGit issue 409, see
>> >> http://code.google.com/p/msysgit/issues/detail?id=409
>> >>
>> >> Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
>> >
>> > With a slightly more stand-alone commit message, I think it makes sense to
>> > push to 4msysgit.git's devel right away.
>>
>> I didn't want to repeat myself in the commit message as I already
>> explain the details in a source code comment, and I preferred a
>> comment because anyone stumbling across that piece of code would
>> probably ask himself / herself what this work-around is good for.
>
> Why not just copy-past it, then? At least for occasional history browsers
> like me, a commit message is what I read mostly.

Because, like I said, I did not want to repeat myself, and for
occasional history browsing I find the commit message title to be
clear enough. But for you pleasure, I've amended the commit message on
work/issue-409 ;-)

--
Sebastian Schuberth

[Johannes Schindelin]

Hi,

On Mon, 19 Apr 2010, Sebastian Schuberth wrote:

> On Mon, Apr 19, 2010 at 17:10, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> >> > On Mon, 19 Apr 2010, Sebastian Schuberth wrote:
> >> >
> >> >> This fixes msysGit issue 409, see
> >> >> http://code.google.com/p/msysgit/issues/detail?id=409
> >> >>
> >> >> Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
> >> >
> >> > With a slightly more stand-alone commit message, I think it makes sense to
> >> > push to 4msysgit.git's devel right away.
> >>
> >> I didn't want to repeat myself in the commit message as I already
> >> explain the details in a source code comment, and I preferred a
> >> comment because anyone stumbling across that piece of code would
> >> probably ask himself / herself what this work-around is good for.
> >
> > Why not just copy-past it, then? At least for occasional history browsers
> > like me, a commit message is what I read mostly.
>
> Because, like I said, I did not want to repeat myself, and for
> occasional history browsing I find the commit message title to be
> clear enough. But for you pleasure, I've amended the commit message on
> work/issue-409 ;-)

Thank you. And I am confident that you will find the overall time-balance
in favor of this, as it was easy and quick for you, and it is easy and
quick for possibly all recipients of this mail now, too.

BTW I would actually just merge the thing and be done with the issue ;-)
Hmm?

Ciao,
Dscho

[René Scharfe]

C style comments (/*...*/) are preferred over C++ style comments (//...)
for git.

Is there a known-good size, or at least a mostly-working one? Would it
make sense to start with that size instead of halving and trying until
that size is reached?

> + size /= 2;
> + } else {
> + buf += written;
> + total += written;

What about other errors? You need to break out of the loop instead of
adding -1 to buf and total, right?

> + if (total + size > count)
> + size = count - total;
> + }
> + }

Shouldn't the loop be left in the successful case, too? write(2) is
allowed to write less than requested, so the caller already needs to
deal with that case anyway.

> +
> + return written < 0 ? written : total;
> +}
> +
> #undef fopen
> FILE *mingw_fopen (const char *filename, const char *otype)
> {
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 756f3ab..751bb4c 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -178,6 +178,9 @@ int mingw_rmdir(const char *path);
> int mingw_open (const char *filename, int oflags, ...);
> #define open mingw_open
>
> +ssize_t mingw_write(int fd, const void *buf, size_t count);
> +#define write mingw_write
> +
> FILE *mingw_fopen (const char *filename, const char *otype);
> #define fopen mingw_fopen
>



--

Subscription settings: http://groups.google.com/group/msysgit/subscribe?hl=en

[Albert Dvornik]

On Mon, Apr 19, 2010 at 4:43 PM, René Scharfe
<rene.s...@lsrfire.ath.cx> wrote:
[...]

>> +                     if (total + size > count)
>> +                             size = count - total;
>> +             }
>> +     }
>
> Shouldn't the loop be left in the successful case, too?  write(2) is
> allowed to write less than requested, so the caller already needs to
> deal with that case anyway.

That's what I thought initially, since the code would be cleaner, but
I don't like the fact that you could actually end up making a lot more
failed write() calls that way, since you restart the size search on
each call to mingw_write().

For example, suppose you were calling mingw_write() with a count that
was exactly 11.5 times bigger than whatever maximum size write() was
willing to accept. If you only did one write() per mingw_write(),
letting the caller restart, this will result in 47 failed writes and
16 successes. Letting mingw_write() do the restart (as in the
existing code) will end up with 4 failed writes and 16 successes.
Now, I assume (wait, this is Windows-- I'd *like to hope*) that a
failed write() is a lot cheaper than a successful one, but this still
rubs me the wrong way.

Of course, if we know (or can guess) the maximum size write() will
take, that would be best.

--bert

[Johannes Sixt]

Thanks for a thorough review. I had the gut feeling that something's wrong
with the code due to its structure, but didn't stare at the code long
enough to notice this.

I suggest to have this structure

write
if success or failure is not EINVAL
return

do
reduce size
if larger than known (presumed?) maximum
reduce to that maximum
write
while not success and failure is EINVAL

while not failure and exactly reduced size written
write more

I don't think that we will observe any short writes *after* the size was
reduced, which Albert is concerned about. Somebody who observes the
failure that this works around could instrument the function to see
whether short writes are really a problem.

-- Hannes

[Johannes Schindelin]

Hi,

On Mon, 19 Apr 2010, Junio C Hamano wrote:

> Dscho, I saw that you are planning to queue this to your tree; would it
> make your job easier if I queue this myself now, or if I refrain from
> queueing this myself and instead wait for you to tell me to pull or
> apply?

It seems to be contested still, but I have no problem with cooking it in
devel directly.

Ciao,
Dscho

[Sebastian Schuberth]

On Mon, Apr 19, 2010 at 22:43, René Scharfe <rene.s...@lsrfire.ath.cx> wrote:

>> +             if (written < 0 && errno == EINVAL) {
>> +                     // There seems to be a bug in the Windows XP network stack that
>> +                     // causes writes with sizes > 64 MB to fail, so we halve the size
>> +                     // until we succeed or ultimately fail.
>
> C style comments (/*...*/) are preferred over C++ style comments (//...)
> for git.

Oh well, I've changed that.

> Is there a known-good size, or at least a mostly-working one?  Would it
> make sense to start with that size instead of halving and trying until
> that size is reached?

As the comment says, the greatest size that worked in my experiments
is 64 MB, and other posts on the Internert suggest the same limit, but
it's still an unconfirmed / undocumented issue. Anyway, I'm now
starting with 64 MB right away if a write failed.

>> +                     size /= 2;
>> +             } else {
>> +                     buf += written;
>> +                     total += written;
>
> What about other errors?  You need to break out of the loop instead of
> adding -1 to buf and total, right?

Right, I've fixed that, thanks.

>> +                     if (total + size > count)
>> +                             size = count - total;
>> +             }
>> +     }
>
> Shouldn't the loop be left in the successful case, too?  write(2) is
> allowed to write less than requested, so the caller already needs to
> deal with that case anyway.

I prefer to make the wrapper as transparent as possible. If a direct
call to write would not write less than requested, the wrapper should
not either.

I've updated work/issue-409 in 4msysgit.git accordingly.

--
Sebastian Schuberth

[Johannes Sixt]

Sure, but René meant the opposite case: When fewer bytes than requested
were written, then you shouldn't retry to write more! That is, you should
exit the loop when write(fd, buf, n) does not return n.

I still find your code unnecessarily hard to read. In particular, you
should extract the non-problematic case out of the loop. If you followed
my suggestion elsewhere in the thread, you wouldn't have to write any
conditionals that 'break' out of a loop.

-- Hannes

[Sebastian Schuberth]

On Tue, Apr 20, 2010 at 14:57, Johannes Sixt <j.s...@viscovery.net> wrote:

> Am 4/20/2010 14:42, schrieb Sebastian Schuberth:
>> On Mon, Apr 19, 2010 at 22:43, René Scharfe <rene.s...@lsrfire.ath.cx> wrote:
>>> Shouldn't the loop be left in the successful case, too?  write(2) is
>>> allowed to write less than requested, so the caller already needs to
>>> deal with that case anyway.
>>
>> I prefer to make the wrapper as transparent as possible. If a direct
>> call to write would not write less than requested, the wrapper should
>> not either.
>
> Sure, but René meant the opposite case: When fewer bytes than requested
> were written, then you shouldn't retry to write more! That is, you should
> exit the loop when write(fd, buf, n) does not return n.

I see what you mean, but I do not fully agree. Who guarantees that (on
some obscure OS) a following call to write(fd, buf, n) will not return
n again, maybe because write() temporarily decided to write fewer
bytes than requested to make the next write() call do aligned writes
to something? That case then is probably already handled in the caller
to write(), but at least my code is not wrong in that respect.

> I still find your code unnecessarily hard to read. In particular, you
> should extract the non-problematic case out of the loop. If you followed
> my suggestion elsewhere in the thread, you wouldn't have to write any
> conditionals that 'break' out of a loop.

I didn't follow your suggestion on purpose because I experimented with
it and I found *yours* to be hard to read. It has three calls to
write() and more places where errors need to be checked. As I do not
have the will to waste more time on style discussions about code that
fixes other people's issues, and not the time to test the code on
Windows XP over and over again, I hope you are willing to accept code
that is different from how you would have written it. So it's take it
or leave it (or modify it yourself, if you feel like it).

--
Sebastian Schuberth

[René Scharfe]

Am 20.04.2010 14:42, schrieb Sebastian Schuberth:
>> Shouldn't the loop be left in the successful case, too? write(2) is
>> allowed to write less than requested, so the caller already needs to
>> deal with that case anyway.
>
> I prefer to make the wrapper as transparent as possible. If a direct
> call to write would not write less than requested, the wrapper should
> not either.

After the call failed, we don't know how many bytes would have been
written had it succeeded.

But I agree with Albert's reasoning to use the knowledge of a working
chunk size in order to minimize the number of write(2) calls. Otherwise
we'd have to search for a working size again and again, generating lots
of failing calls.

> I've updated work/issue-409 in 4msysgit.git accordingly.

This patch doesn't help in the test case I cobbled together quickly.
It's a Windows XP SP3 client on VMWare mapping a file share exported by
a Netapps filer, over a VPN. It's very slow, and I admit that it's a
weird setup. I wouldn't actually use it that way, but couldn't find
another file share momentarily.

I can check out a 1MB file, but checking out a 32MB file fails. I've
added a fprintf() to the loop and I can see that it's halving the size
and retries, as intended, until it eventually hits zero.

The file is created using the correct file size (32MB), though.The first
failed write(2) call needs to be undone somehow before we can try again,
it seems. Do we have to seek back or truncate the file?

Replacing the body of mingw_write() with the following line allows me to
check out the 32MB file, by the way:

return write(fd, buf, min(count, 1024 * 1024));

René

[René Scharfe]

OK, I've been searching the web looking for documentation that explains
the issue, but haven't found any watertight evidence.

With Process Monitor [1], I found out that local write() calls are
translated to WriteFile() calls with a maximum size of 64KB on Windows XP
and 256KB on Vista. Writes to a network drive are translated to
WriteFile() calls without applying a size cap.

In a forum discussion [2], someone explained that unbuffered writes using
WriteFile() have certain size limits, depending on the processor:

x86: 67,076,096
X64: 33,525,760
IA64: 67,051,520

This post is cited by an MS employee in the comment section of the online
documentation for WriteFile() [3].

A Knowledge Base article [4] documents a size limit of 67,076,095 for
fwrite() to a file on a network drive. fwrite() calls translate to
WriteFile() calls, too. The reason for this is said to be an OS problem,
but no OS versions are named at all in this article.

Please note that the size limit of fwrite() is suspiciously close to the
one for an unbuffered WriteFile().

In my test setup, write() calls to a network drive fail with a size
parameter of 32MB, while with 33,525,760 bytes they succeed.

Based on these two observations, I suspect that there's a connection
between writes to a network drive and unbuffered writes. Perhaps writes
over the net are passed to the NIC driver in one piece which is locked
into RAM?

The connection is a bit weak (it would be good to have someone comment on
this who actually knows something about this topic and doesn't have to
guesswork through a bunch of websites), but I think it's enough to create
a patch. Based on the numbers above, I think 31MB is a good size to
simply cap writes.

When we learn that other systems need a lower limit still, we can easily
reduce our cap, without affecting local performance.

It would be nice to reach chris.gcode, who originally reported this
problem [5], and ask him to test. I couldn't find an email address on
that webpage, though. His proposed patch there also used an upper limit
slightly below 32MB, but tried to compensate for capping by looping until
the full requested size was written. That's not really needed.

René


[1] http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
[2] http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/fef1c9b5-fd92-4ada-8de5-44c2eb30b516
[3] http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx#5
[4] http://support.microsoft.com/kb/899149
[5] http://code.google.com/p/msysgit/issues/detail?id=409

-- >8 --
Bigger writes to network drives on Windows XP fail. Cap them at 31MB to
allow them to succeed. Callers need to be prepared for write() calls
that do less work than requested anyway.

On local drives, write() calls are translated to WriteFile() calls with
a cap of 64KB on Windows XP and 256KB on Vista. Thus a cap of 31MB won't
affect the number of WriteFile() calls which do the actual work. There's
still room for some other version of Windows to use a chunk size of 1MB
without increasing the number of system calls.

Signed-off-by: Rene Scharfe <rene.s...@lsrfire.ath.cx>
---
compat/mingw.c | 17 +++++++++++++++++
compat/mingw.h | 3 +++
2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index f90a114..9a8e336 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -140,6 +140,23 @@ int mingw_open (const char *filename, int oflags, ...)

return fd;
}

+#undef write
+ssize_t mingw_write(int fd, const void *buf, size_t count)
+{

+ /*
+ * While write() calls to a file on a local disk are translated
+ * into WriteFile() calls with a maximum size of 64KB on Windows
+ * XP and 256KB on Vista, no such cap is placed on writes to
+ * files over the network on Windows XP. Unfortunately, there
+ * seems to be a limit of 32MB-28KB on X64 and 64MB-32KB on x86;
+ * bigger writes fail on Windows XP.
+ * So we cap to a nice 31MB here to avoid write failures over
+ * the net without changing the number of WriteFile() calls in
+ * the local case.
+ */
+ return write(fd, buf, min(count, 31 * 1024 * 1024));

+}
+
#undef fopen
FILE *mingw_fopen (const char *filename, const char *otype)
{
diff --git a/compat/mingw.h b/compat/mingw.h

index 7c2ab64..0e3e743 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -170,6 +170,9 @@ int link(const char *oldpath, const char *newpath);

int mingw_open (const char *filename, int oflags, ...);
#define open mingw_open

+ssize_t mingw_write(int fd, const void *buf, size_t count);
+#define write mingw_write
+
FILE *mingw_fopen (const char *filename, const char *otype);
#define fopen mingw_fopen

--

1.7.1

[Johannes Sixt]

Am 4/29/2010 22:01, schrieb René Scharfe:
> +#undef write
> +ssize_t mingw_write(int fd, const void *buf, size_t count)
> +{
> + /*
> + * While write() calls to a file on a local disk are translated
> + * into WriteFile() calls with a maximum size of 64KB on Windows
> + * XP and 256KB on Vista, no such cap is placed on writes to
> + * files over the network on Windows XP. Unfortunately, there
> + * seems to be a limit of 32MB-28KB on X64 and 64MB-32KB on x86;
> + * bigger writes fail on Windows XP.
> + * So we cap to a nice 31MB here to avoid write failures over
> + * the net without changing the number of WriteFile() calls in
> + * the local case.
> + */
> + return write(fd, buf, min(count, 31 * 1024 * 1024));
> +}
> +

Thanks, I have verified that this fixes the problem in my setup as well.
I'll queue the patch with the below test case squashed in.

-- Hannes

diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh
index adfaae8..8afbdd4 100755
--- a/t/t5705-clone-2gb.sh
+++ b/t/t5705-clone-2gb.sh
@@ -12,7 +12,7 @@ test_expect_success 'setup' '

git config pack.compression 0 &&
git config pack.depth 0 &&
- blobsize=$((20*1024*1024)) &&
+ blobsize=$((100*1024*1024)) &&
blobcount=$((2*1024*1024*1024/$blobsize+1)) &&
i=1 &&
(while test $i -le $blobcount
@@ -36,9 +36,15 @@ test_expect_success 'setup' '

'

-test_expect_success 'clone' '
+test_expect_success 'clone - bare' '

- git clone --bare --no-hardlinks . clone
+ git clone --bare --no-hardlinks . clone-bare
+
+'
+
+test_expect_success 'clone - with worktree, file:// protocol' '
+
+ git clone file://. clone-wt

'

[Sebastian Schuberth]

On Thu, Apr 29, 2010 at 22:01, René Scharfe <rene.s...@lsrfire.ath.cx> wrote:

> OK, I've been searching the web looking for documentation that explains
> the issue, but haven't found any watertight evidence.

Thanks René for your research and for finally finishing the fix!

> It would be nice to reach chris.gcode, who originally reported this
> problem [5], and ask him to test.  I couldn't find an email address on
> that webpage, though.  His proposed patch there also used an upper limit
> slightly below 32MB, but tried to compensate for capping by looping until
> the full requested size was written.  That's not really needed.

I believe to have found his e-mail address on the msysGit mailing list
and put him on CC.

--
Sebastian Schuberth

[Junio C Hamano]

Johannes Sixt <j.s...@viscovery.net> writes:

> Thanks, I have verified that this fixes the problem in my setup as well.
> I'll queue the patch with the below test case squashed in.

Thanks.

[René Scharfe]

Hi,

I've cc:'d the mailing lists and the participants of the earlier
discussion to share your findings and to see if someone else may have an
explanation for this behaviour, or a solution.

The patch in question is c8b296450e5148c576697ea4709072b7855aacd5 and
has made it into git versions 1.7.1.1 and 1.7.2 (and up). It caps
writes at 31MB to fix a problem with network drives in certain versions
of Windows.

Am 14.10.2010 21:26, schrieb Chad Warner:
> I am experiencing issues with the patch you suggested. I am working
> with a repository via its UNC path and it is failing on large files.
> I first tried lowing to several different values such as 4MB and still
> had problems. I eventually got it to work with the following:
>
> return write(fd, buf, min(count, 1024 * 27));
>
> I didn't notice any real delays with having to call write that many
> more times. However, I really don't know how to go about fixing this
> issue or validating that this really fixes the problem.

Reducing the write cap to 27KB unconditionally sounds pretty drastic to
me; it could hurt the local case. I didn't measure it, though, so I
might be wrong. Depending on that measurement we perhaps need to find a
different solution.

Also, 27KB is an odd number. I take it that 28KB won't fix the issue
for you?

I wonder about the cause of this threshold. Wild guess: network driver
bug or other network issue?

Which version of Windows do you use on the client? Which OS runs on the
server? Do you have any other information that might help in
reproducing the problem?

Thanks,
Ren�

[Dmitry Potapov]

On Sat, Oct 16, 2010 at 9:23 PM, René Scharfe
<rene.s...@lsrfire.ath.cx> wrote:
>
> Also, 27KB is an odd number.  I take it that 28KB won't fix the issue
> for you?

I guess the beginning of the written buffer is not page aligned, and the
system locks pages. Thus depending on the buffer alignment, the written
maximum can vary up to the size of one page.

>
> I wonder about the cause of this threshold.  Wild guess: network driver
> bug or other network issue?

Memory pressure? Git may consume large amount of virtual memory
during some operations, but I am not sure how it is translated in the
number of physical memory consumed by the process as well as what
quotas could be on that system. It would be interesting to see what
GetProcessMemoryInfo() returns when write() fails.

Dmitry