xfs
[Top] [All Lists]

Re: [PATCH 5/8] xfs: split direct IO write path from xfs_file_aio_write

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 5/8] xfs: split direct IO write path from xfs_file_aio_write
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 7 Jan 2011 20:21:36 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110107085830.GC10829@xxxxxxxxxxxxx>
References: <1294116518-14908-1-git-send-email-david@xxxxxxxxxxxxx> <1294116518-14908-6-git-send-email-david@xxxxxxxxxxxxx> <20110107085830.GC10829@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jan 07, 2011 at 03:58:30AM -0500, Christoph Hellwig wrote:
> > +This also clearly indicates that XFS
> > + * does not fall back to buffered IO in the direct IO write path.
> 
> I don't think this comment belongs into the function header.  It's
> already present in the right place anyway, so it can just be removed.

OK.

> > +   xfs_buftarg_t           *target = XFS_IS_REALTIME_INODE(ip) ?
> > +                                   mp->m_rtdev_targp : mp->m_ddev_targp;
> 
> struct xfs_buftarg, please.

Was copy-n-paste. Will fix.

> > +   trace_xfs_file_direct_write(ip, count, iocb->ki_pos, 0);
> > +   ret = generic_file_direct_write(iocb, iovp,
> > +                   &nr_segs, pos, &iocb->ki_pos, count, ocount);
> > +
> > +   /* No fallback to buffered IO on errors for XFS. */
> > +   return ret;
> 
> I'd add an
> 
>       ASSERT(ret < 0 || ret == count);
> 
> here to make sure we don't get problems due to changes in the core
> direct I/O code.

Yup, good idea.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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