xfs
[Top] [All Lists]

Re: fs corruption exposed by "xfs: increase prealloc size to double that

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent"
From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Mon, 17 Mar 2014 01:38:00 +0000
Cc: Brian Foster <bfoster@xxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, Dave Chinner <dchinner@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140317012804.GU18016@xxxxxxxxxxxxxxxxxx>
References: <20140315210216.GP18016@xxxxxxxxxxxxxxxxxx> <20140317001130.GA7072@dastard> <20140317002918.GT18016@xxxxxxxxxxxxxxxxxx> <20140317012804.GU18016@xxxxxxxxxxxxxxxxxx>
Sender: Al Viro <viro@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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...

<Prev in Thread] Current Thread [Next in Thread>