On Mon, Aug 04, 2014 at 08:37:10PM +0200, Marcin Wolcendorf wrote:
> > Hmm. Ok, can you give me the outputs to the following two commands,
> > run as root:
> >
> > vgdisplay home_move
> > lvdisplay --maps /dev/home_move/home_move_tmp
>
> Attached test_lvmVGLV.log.bz2
Hmm, it looks like you are using nested LVM's. Which is wierd, but I
don't think that should cause problem. Can you send me the results of
vgdisplay main
lvdisplay --maps /dev/main/home_tmp
>As far as I understand the code - you have tried to do just that. And, as far
>as I can understand the result - it succeeded, and with resize2fs it does not.
>Could it be gcc optimisation related?
>Should I try different compile options?
Yes, that's what my test program was trying to do. I was trying to
create a short reproduction of what was apparently happening according
to strace. And I'm completely puzzled why it might be succeeding in
the small test program, and not in resize2fs.
About the only differences that I can see is that (a) we're opening
the file with the O_EXCL file, which shouldn't be making a huge
difference:
open("/dev/home_move/home_move_tmp", O_RDWR|O_EXCL) = 3
(b) that we're doing two ioctl's which are querying information about
the block device (so it shouldn't be modifying any state in the file
descriptor)
ioctl(3, BLKDISCARDZEROES, 0) = 0
ioctl(3, BLKROGET, 0) = 0
and (c) there are many other intervening read, write, and fsync system
calls between the read and write calls in the test program.
So I'm not sure what to do at this point. I could have e2fsprogs
retry short writes much like the "secondary write" in the test
program. The downside is that while it might fix things for you, for
others, in the case where we have a real I/O error, it doubles the
delay in reporting the error (especially since the device driver often
retries multiple times before it declares an error, and if we retry
the write, the driver will then retry the failed I/O operation
multiple times --- and for each kernel dispatched request, the HDD
will often retry the write multiple times).
It's clear from the strace that the kernel is reporting a short write,
which is a bug. But if we can't reproduce the bug in a short program,
then (a) we can't easily report this bug to the device mapper kernel
developers, and (b) I can't even be sure that the workaround is
guaranteed to work.
I could send you instructions on how to build a patched e2fsprogs to
see if the workaround works, but even if it does, I'm very hesitant
about whether this is something I would be willing to check in.
- Ted
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
