On Wed, May 15, 2013 at 10:47:36AM +1000, Dave Chinner wrote:
> > 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
>
> Actually due to speculative preallocation done by delayed
> allocation.
But if the space is preallocated speculatively and then remains unused,
shouldn't it get freed up somehow, eventually?
> > that unwritten extent flagging doesn't help because such extents don't need
> > to be flagged as it's impossible to read them.
>
> fallocate will leave unwritten extents beyond EOF, in which case we
> can detect it, but we know there's nothing to be done as there's no
> data....
OK, so we have the following cases:
1. fallocate. The file has more space allocated to it than the size field in
its inode says, and the extra extents are flagged as unwritten.
2. speculative preallocation. Same as above, but the extents are not flagged
as unwritten.
3. corruption. The file's inode reports an incorrect size for whatever
reason. If it's too much, that's easy to detect; the problem is telling if
it's too little.
Distinguishing between #1 and #2 is possible based on the unwritten flags.
In case #2, I think the extra space should be possible to free up (perhaps
by xfs_repair?). Of course, I suppose you could just run truncate(1) on all
files...
The problem is recognising #3.
Do I have that right?
> > 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.
>
> How? Add a transaction to track the data that has been written?
>
> Well, we already do that - with the inode size.
Ah, yes, that's true.
OK, thinking about it I realise there doesn't appear to be a good way of
preventing the problem, but I'm still not sure some heuristic couldn't be
invented to detect and partially remedy it after the fact.
--
Andras Korn <korn at elan.rulez.org>
C++ is like an onion. It's got so many layers that you can't help but cry.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
