On Mon, Aug 04, 2014 at 10:48:28PM -0400, Theodore Ts'o wrote: > That being said, I'm pretty sure the problem will evaporate once we > move it to a raw image file --- the short write is something which is > fundamental to the block device, not the file system image.
OK, so you suggest I report this bug to the kernel mainainters? > > > I could send you instructions on how to build a patched e2fsprogs to > > Ok, do the following: > > git clone -b retry-write git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git > e2fsprogs-retry > cd e2fsprogs-retry > ./configure > make -j8 > > Then try using the resize/resize2fs and see if that works any better for you. Actually, it does not... The result is pretty much the same: # e2fsprogs-retry/resize/resize2fs /dev/home_move/home_move_tmp 4269800000 resize2fs 1.42.11 (09-Jul-2014) Resizing the filesystem on /dev/home_move/home_move_tmp to 4269800000 (4k) blocks. e2fsprogs-retry/resize/resize2fs: Attempt to write block to filesystem resulted in short write while trying to resize /dev/home_move/home_move_tmp Please run 'e2fsck -fy /dev/home_move/home_move_tmp' to fix the filesystem after the aborted resize operation. > If you can try to save a compressed raw image file, that would be > nice, but I expect the problem is device specific, as I mentioned > earlier. Should I attach it to this bug report? It took a few days to make it... So summing it up - there is probably a bug in block device code, that reports a short write, where there should be normal one, and as a result shrinking the FS is no longer possible. That is sad... But you have also said that you use the O_EXCL option. Maybe this casues some problems? Is it safe (assuming nothing else uses the block device) to remove this option and try without it? BR, M.W.
signature.asc
Description: Digital signature
