On Mon, Aug 04, 2014 at 05:56:24PM -0400, Theodore Ts'o 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
Attached test_lvmVGLV_main.log.bz2 I do agree it is kind of weird setup - all I can say it is easier for me to mentally process completely separate structures - like another VG - especially when I'm tired. And I thought it should not matter. > 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. This is strange. Could it be related to the LV being stitched Frankenstein way? > 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. Is it possible to somehow extract the FS structures so it would be easier to experiment with this? I mean - if the FS structures take less space, I could store them and reclaim those puny 16TB; maybe some sparse image file would do? I'd be quite happy to help here, but I need guidance. Still, I would like to clean up all this mess I'm in - I (hopefully) have some data on this FS, that I would like to move away, but without resize2fs I do not have enough space. > 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. As I said, I'd be happy to investigate some more, but then again - I'd like to have my disk space back, and preferably not by removing the home_move_tmp. So if it is possible, I would like the patched resize2fs (or instructions to patch it), and maybe some instructions how to dump/preserve the current FS structures for further investigation. Thanks a lot, BR, M.W.
test_lvmVGLV_main.log.bz2
Description: Binary data
signature.asc
Description: Digital signature
