From: Andras Korn <korn-xfs@elan.rulez.org>
To: xfs@oss.sgi.com
Subject: wishlist: xfs_repair should detect files with too small sizes
Date: Tue, 14 May 2013 23:55:50 +0200 [thread overview]
Message-ID: <20130514215550.GK17260@hellgate> (raw)
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2013-05-14 21:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 21:55 Andras Korn [this message]
2013-05-15 0:47 ` wishlist: xfs_repair should detect files with too small sizes Dave Chinner
2013-05-15 8:03 ` Andras Korn
2013-05-15 21:41 ` Dave Chinner
2013-05-16 3:56 ` Andras Korn
2013-05-17 0:16 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130514215550.GK17260@hellgate \
--to=korn-xfs@elan.rulez.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox