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 00:29:18 +0000
Cc: Brian Foster <bfoster@xxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, Dave Chinner <dchinner@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140317001130.GA7072@dastard>
References: <20140315210216.GP18016@xxxxxxxxxxxxxxxxxx> <20140317001130.GA7072@dastard>
Sender: Al Viro <viro@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Mar 17, 2014 at 11:11:30AM +1100, Dave Chinner wrote:

> Yes, we've known about this since 2011.  Right - that's a long
> standing problem, and one I've never been able to isolate and so
> reproduce with any luck. It can only be reproduced when you use mmap
> and direct IO on the same file, and every time I've added debug to
> find out where the tail block corruption was being introduced, the
> data corruption goes away. It behaves just like a race condition....

See downthread.  And I would be *very* surprised if it was a race -
don't forget the msync() done before that write().

I think I know what's going on - O_DIRECT write starting a bit before
EOF on a file with the last extent that can be grown.  It fills
a buffer_head with b_size extending quite a bit past the EOF; the
blocks are really allocated.  What causes the problem is that we
have the flags set for the *first* block.  IOW, buffer_new(bh) is
false - the first block has already been allocated.  And for
direct-io.c it means "no zeroing the tail of the last block".

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