Hi,
I have thousands of files on xfs whose inode claims their size is zero, but
they have blocks allocated to them; du(1) reports a nonzero size. xfs_repair
3.1.9 ignores this. xfs_db can be used to recover the contents of the files
(using commands like inode 1234; write core.size 4567).
David Chinner explained to me that xfs_repair ignores these files because
it's legitimate to have blocks beyond eof (e.g. due to fallocate()), and
that unwritten extent flagging doesn't help because such extents don't need
to be flagged as it's impossible to read them.
My zero-sized files were likely effected by a crash (certainly not
fallocate()).
I think it would be useful to have the ability to distinguish between files
that legitimately have extents beyond EOF and files whose inode incorrectly
reports a too-small size.
Maybe an allocated-size field could be added to the inode, or extents
assigned to files via fallocate() could be flagged somehow? And if files
with incorrect sizes (i.e. where allocated-size div blocksize < number_of_blocks
OR allocated-size < core.size OR where a file contains extents beyond EOF
that are not fallocate-flagged) are found, xfs_repair could at least report
them?
--
Andras Korn <korn at elan.rulez.org>
WARNING: Do NOT look into laser with remaining eyeball.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
