2

I just resized a .vdi from my host from 15.5G to 120G. I tried to resize the partition from the guest (ubuntu server) using resize2fs

root@ubuntu:~# sudo resize2fs /dev/sda2 115G
resize2fs 1.42.13 (17-May-2015)
resize2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2
Couldn't find valid filesystem superblock.

Now, according to my understanding of the situation /dev/sda2 is corrupt. However, my server-VM still works fine and has no problems running on the partition. fdisk -l /dev/sda outputs:

Disk /dev/sda: 120 GiB, 128849018880 bytes, 251658240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x32955267

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *       2048   999423   997376  487M 83 Linux
/dev/sda2       1001470 33552383 32550914 15.5G  5 Extended
/dev/sda5       1001472 33552383 32550912 15.5G 8e Linux LVM

Now to my question: Is this normal and healthy for the server and if not, how do I fix it?

0

resize2fs and other tools in the e2fsprogs suite assume that the read system call either returns the whole requested size of encounters an error. This is not true in general: read is allowed to return less, you're supposed to call this in a loop. I think the Linux kernel guarantees that read returns all the data from block devices in some circumstances, but I've been bitten by this in the past, with e2fsprogs making wrong assumptions on the kernel.

The fact that e2fsprogs don't loop around read is really a bug. At best it's a limitation: maybe the way the code is written is correct for some versions of the Linux kernel when accessing a block device. But that limitation is not documented anywhere. The code is definitely buggy when accessing an image file.

Check the kernel logs for errors. If the kernel reports an error, then the problem is not a bug in resize2fs (or at least, nothing more than poor error reporting).

If the kernel doesn't report disk errors, run

strace -o resize2fs.strace sudo resize2fs /dev/sda2 115G

and check the read system calls.

read(3, "…", REQUESTED)                = READ

There is a short read if REQUESTEDREAD. If you observe this, and you can reproduce it, it would be worth making a bug report. Explain exactly how you triggered this: exact kernel version, how the kernel was compiled, exact version of resize2fs, what hardware driver manages /dev/sda, what virtual machine software it's running on. I recommend reporting the bug to Ubuntu rather than to upstream, as upstream is often not good at talking to non-experts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.