On Tue, Aug 21, 2018 at 04:23:52PM -0400, Theodore Y. Ts'o wrote: > On Tue, Aug 21, 2018 at 10:59:37AM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > Since ext4 verity is going to be an RO_COMPAT feature rather than an > > INCOMPAT one, the on-disk i_size of verity inodes needs to be the data > > size rather than the full size. Consequently, verity inodes will have > > initialized blocks past i_size, containing the Merkle tree and other > > verity metadata. So e2fsck must not fix the i_size of such inodes as it > > normally would. > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > Thanks, applied. > > We should have some tests, in e2fsprogs and/or xfstests that tests > this. The work-in-progress verity 9XX xfstests don't seem to have a > problem with this, probably because we weren't unmounting a file > system, and then running fsck. (Since it's a scratch partition, > the test harness doesn't run fsck after any of the 9XX tests.) > > Thanks for catching this! > > - Ted Actually xfstests does run fsck on the scratch device. This reason this wasn't causing problems before is that the ext4 verity kernel patches were leaving the on-disk i_size as the full size (size of data + verity metadata) rather than setting it to just the data size. I actually just changed this today, in order to match 'verity' being a RO_COMPAT feature, and I've pushed out updates to both the kernel [1] and xfstests [2] fs-verity patchsets to start using the ext4 feature flag. So this *is* tested by the work-in-progress xfstests now, though a test could be added to e2fsprogs too. [1] https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=fsverity [2] https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git/log/?h=fsverity Note that we also need to decide whether f2fs will set the on-disk i_size to the data size as well. Currently I still have it setting i_size to the full size. - Eric