access beyond end of device?

[Benjamin Scott]

On Jul 13 at 11:08am, Bill McGonigle wrote:
> Right.  If you assume a filesystem was truncated.  I was assuming a bad 
> partition table lead mkfs to create an incorrect superblock which lead to an 
> inode with an invalid data block location.

   mke2fs writes to the end of the device, so if the device ends prematurely, 
mke2fs will abort and you don't get a filesystem.  So that's not it.

   Sample output of a test I just performed, using a 16 MiB loopback device 
(irrelevant output trimmed for brevity):

>--------------------------------------------------------------------<
$ mke2fs /dev/loop0 16384
mke2fs 1.36 (05-Feb-2005)
4096 inodes, 16384 blocks
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
$

$ mke2fs /dev/loop0 16385
mke2fs 1.36 (05-Feb-2005)
mke2fs: Filesystem larger than apparent device size.
Proceed anyway? (y,n) y
4096 inodes, 16385 blocks

Writing inode tables: 0/2
Could not write 8 blocks in inode table starting at 69: Attempt to write block 
from filesystem resulted in short write
$ 
>--------------------------------------------------------------------<

> Does e2fsck validate the existence of blocks in the ext2 allocation bitmap 
> without trusting the partition table?

   Well, e2fsck doesn't know about partition tables.  It asks the kernel how 
big the device is.  Of course, the kernel mainly uses the partition table to 
determine device size, but I don't think it will let you have a partition 
bigger then the containing block device.

   But let's say a filesystem does get truncated somehow.  What happens?

   I created my test filesystem on a loopback device of 16 MiB.  fsck works 
fine.  I undid the loop dev and used "dd" to copy the image, but 1024 bytes 
short.  I then looped that and ran e2fsck.  The results are interesting:

>--------------------------------------------------------------------<
$ e2fsck /dev/loop0
e2fsck 1.36 (05-Feb-2005)
The filesystem size (according to the superblock) is 16384 blocks
The physical size of the device is 16383 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no
/dev/loop0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop0: 11/4096 files (9.1% non-contiguous), 661/16384 blocks
$
>--------------------------------------------------------------------<

   So it correctly identified the problem, but when told to do the check 
anyway, passed the filesystem as okay!

   Even more bizarre: If I try to copy a large file into that filesystem, it 
fails with ENOSPC (No space left on device), reports the filesystem as 
(practically) full, but otherwise appears to be okay.  I expected the 
filesystem driver to consider this error serious enough to remount-ro (which 
is the error behavior I set with tune2fs).  I saw the following in the kernel 
log:

>--------------------------------------------------------------------<
attempt to access beyond end of device
loop0: rw=1, want=32768, limit=32766
Buffer I/O error on device loop0, logical block 16383
lost page write due to I/O error on loop0
>--------------------------------------------------------------------<

   e2fsck still passes the filesystem, too!  (Other then the warning about the 
size mismatch, which is, admittedly, pretty serious.)

   I can only assume (1) there is no important metadata in the last block of 
the device and (2) when the filesystem driver gets a premature EOF on the 
write, it just fails the call as if the filesystem was "normally full". 
Still, I'm not sure I would call this "expected behavior".

   Finally, I tried truncating the loop image to 1 MiB (losing 15 of the 
original 16 MiB).  *That* resulted in immediate puke from e2fsck, even if I 
forced it to continue.

> I'm hoping we'll get a report when the cause is determined.

   Indeed!

-- 
Ben <dragonhawk at iname.com>