From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, Brian Foster <bfoster@redhat.com>,
xfs@oss.sgi.com, Dave Chinner <dchinner@redhat.com>
Subject: Re: fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent"
Date: Mon, 17 Mar 2014 01:38:00 +0000 [thread overview]
Message-ID: <20140317013759.GV18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140317012804.GU18016@ZenIV.linux.org.uk>
On Mon, Mar 17, 2014 at 01:28:04AM +0000, Al Viro wrote:
> but that is unsafe - consider a situation when you are writing 20Kb from e.g.
> 0.5Kb offset from the beginning of last (4Kb) block. You have 6 blocks
> affected, right? One old, five new. And you want the last half-kilobyte
s/the last/all but the first/, sorry. Basically, we want to get from
OOOOOOOO (8 sectors of old data)
to
ONNNNNNN|NNNNNNNN|NNNNNNNN|NNNNNNNN|NNNNNNNN|NZZZZZZZ (1 sector of old data,
40 sectors of new data, 7 sectors of zeroes). We want the last 7 sectors
zeroed out, but we do *not* want that to happen to the one sector of old data.
OTOH, if the file had been 4K shorter (and all blocks had been new) we would
want
ZNNNNNNN|NNNNNNNN|NNNNNNNN|NNNNNNNN|NNNNNNNN|NZZZZZZZ. IOW, it's not just
the last block we want to know about. There's simply not enough bandwidth
in that interface to pass the information we would need for such mixed
block runs...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-17 1:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-15 21:02 fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent" Al Viro
2014-03-15 21:02 ` Al Viro
2014-03-16 2:21 ` Al Viro
2014-03-16 2:39 ` Al Viro
2014-03-16 2:39 ` Al Viro
2014-03-16 20:56 ` Al Viro
2014-03-16 20:56 ` Al Viro
2014-03-17 1:36 ` Dave Chinner
2014-03-17 1:36 ` Dave Chinner
2014-03-17 2:43 ` Dave Chinner
2014-03-18 1:16 ` Dave Chinner
2014-03-17 0:11 ` Dave Chinner
2014-03-17 0:11 ` Dave Chinner
2014-03-17 0:29 ` Al Viro
2014-03-17 0:29 ` Al Viro
2014-03-17 1:28 ` Al Viro
2014-03-17 1:38 ` Al Viro [this message]
2014-03-17 1:41 ` Dave Chinner
2014-03-17 1:41 ` 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=20140317013759.GV18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=linux-fsdevel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.