On Thu, Oct 29, 2015 at 10:29:50AM -0400, Brian Foster wrote:
> On Mon, Oct 19, 2015 at 02:27:15PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > DAX has a page fault serialisation problem with block allocation.
> > Because it allows concurrent page faults and does not have a page
> > lock to serialise faults to the same page, it can get two concurrent
> > faults to the page that race.
> >
> > When two read faults race, this isn't a huge problem as the data
> > underlying the page is not changing and so "detect and drop" works
> > just fine. The issues are to do with write faults.
> >
> > When two write faults occur, we serialise block allocation in
> > get_blocks() so only one faul will allocate the extent. It will,
> > however, be marked as an unwritten extent, and that is where the
> > problem lies - the DAX fault code cannot differentiate between a
> > block that was just allocated and a block that was preallocated and
> > needs zeroing. The result is that both write faults end up zeroing
> > the block and attempting to convert it back to written.
> >
> > The problem is that the first fault can zero and convert before the
> > second fault starts zeroing, resulting in the zeroing for the second
> > fault overwriting the data that the first fault wrote with zeros.
> > The second fault then attempts to convert the unwritten extent,
> > which is then a no-op because it's already written. Data loss occurs
> > as a result of this race.
> >
> > Because there is no sane locking construct in the page fault code
> > that we can use for serialisation across the page faults, we need to
> > ensure block allocation and zeroing occurs atomically in the
> > filesystem. This means we can still take concurrent page faults and
> > the only time they will serialise is in the filesystem
> > mapping/allocation callback. The page fault code will always see
> > written, initialised extents, so we will be able to remove the
> > unwritten extent handling from the DAX code when all filesystems are
> > converted.
> >
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
> > fs/dax.c | 5 +++++
> > fs/xfs/xfs_aops.c | 13 +++++++++----
> > fs/xfs/xfs_iomap.c | 21 ++++++++++++++++++++-
> > 3 files changed, 34 insertions(+), 5 deletions(-)
> >
> ...
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index c3cb5a5..f4f5b43 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> ...
> > tp = xfs_trans_alloc(mp, XFS_TRANS_DIOSTRAT);
> > +
> > + /*
> > + * For DAX, we do not allocate unwritten extents, but instead we zero
> > + * the block before we commit the transaction. Ideally we'd like to do
> > + * this outside the transaction context, but if we commit and then crash
> > + * we may not have zeroed the blocks and this will be exposed on
> > + * recovery of the allocation. Hence we must zero before commit.
> > + * Further, if we are mapping unwritten extents here, we need to zero
> > + * and convert them to written so that we don't need an unwritten extent
> > + * callback for DAX. This also means that we need to be able to dip into
> > + * the reserve block pool if there is no space left but we need to do
> > + * unwritten extent conversion.
> > + */
> > + if (IS_DAX(VFS_I(ip))) {
> > + bmapi_flags = XFS_BMAPI_CONVERT | XFS_BMAPI_ZERO;
> > + tp->t_flags |= XFS_TRANS_RESERVE;
> > + }
>
> Am I following the commit log description correctly in that block
> zeroing is only required for DAX faults? Do we zero blocks for DAX DIO
> as well to be consistent, or is that also required (because it looks
> like we still have end_io completion for dio writes anyways)?
DAX DIO will do the zeroing rather than using unwritten extents,
too. But we still have DIO IO completion as that needs to do file
size updates.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
