Re: Question on fallocate/ftruncate sequence

[Andreas Dilger <adilger@sun.com>]

On Jul 21, 2009  14:29 -0700, Frank Mayhar wrote:
> I've spent a little while today digging into this.  My guess (only a
> guess at this point until I have a chance to prove it) is that
> i_disksize should be updated by fallocate() even when KEEP_SIZE is
> specified.  It's currently not updated in that case.

No, that isn't correct.  The intent of KEEP_SIZE is to allow fallocate
to preallocate blocks beyond the EOF, so that it doesn't affect the
file data visible to userspace, but can avoid fragmentation from e.g.
log files or mbox files.

The i_disksize variable is just to handle the lag in updating the on-disk
file size during truncate, because the VFS updates i_size to indicate a
truncate, but in order to handle the truncation of files within finite
transaction sizes the on-disk file size needs to be shrunk incrementally.

> It's my
> understanding that i_disksize should be the real allocation, right?
> While i_size is the size that has actually been used?  If so, then
> setting i_disksize is probably what's missing.

The difference is that i_size is in the VFS inode, and represents the
current in-memory state, while i_disksize is in the ext4 private inode
data and represents what is currently in the on-disk inode.

If we were to change i_disksize then on the next reboot the filesize
would become whatever is stored in i_disksize.

That said, we might need to have some kind of flag in the on-disk
inode to indicate that it was preallocated beyond EOF.  Otherwise,
e2fsck will try and extend the file size to match the block count,
which isn't correct.  We could also use this flag to determine if
truncate needs to be run on the inode even if the new size is the
same.

As a workaround for now, you could truncate to (size+1), then again
truncate to (size) and it should have the desired effect.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.