From: Andras Korn <korn-xfs@elan.rulez.org>
To: xfs@oss.sgi.com
Subject: Re: wishlist: xfs_repair should detect files with too small sizes
Date: Thu, 16 May 2013 05:56:51 +0200 [thread overview]
Message-ID: <20130516035651.GH17261@hellgate> (raw)
In-Reply-To: <20130515214105.GZ24635@dastard>
On Thu, May 16, 2013 at 07:41:05AM +1000, Dave Chinner wrote:
> > 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.
>
> Trying to remedy it in xfs_repair does more harm than good. What
> happens now allows recovery of data if the inode size was wrong. If
> we remove the blocks beyond EOF, we lose that ability and hence make
> unrecoverable data loss more likely in common failure scenarios.
That's clear (xfs_repair not freeing up the space is what allowed me to
recover the data). I meant "remedy" as in _either_ increase the inode size
OR free up the extra space. Perhaps xfs_db could be extended to do this?
Of course, increasing the size as stored in the inode can add garbage (at
the very least, binary zeroes) to the end of files, but if the data would
otherwise have been lost, this is probably still preferable. I can even
imagine an xfs_db command that increases file size up to the last non-zero
data byte in the allocated space.
--
Andras Korn <korn at elan.rulez.org>
No wanna work. Wanna bang on keyboard.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-05-16 3:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 21:55 wishlist: xfs_repair should detect files with too small sizes Andras Korn
2013-05-15 0:47 ` Dave Chinner
2013-05-15 8:03 ` Andras Korn
2013-05-15 21:41 ` Dave Chinner
2013-05-16 3:56 ` Andras Korn [this message]
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=20130516035651.GH17261@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