xfs
[Top] [All Lists]

Re: [PATCH 17/30] db: rewrite IO engine to use libxfs

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 17/30] db: rewrite IO engine to use libxfs
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 1 Nov 2013 08:59:50 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131031151046.GB7457@xxxxxxxxxxxxx>
References: <1383107481-28937-1-git-send-email-david@xxxxxxxxxxxxx> <1383107481-28937-18-git-send-email-david@xxxxxxxxxxxxx> <20131031151046.GB7457@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Oct 31, 2013 at 08:10:46AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 30, 2013 at 03:31:08PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > Now that we have buffers and xfs_buf_maps, it is relatively easy to
> > convert the IO engine to use libxfs routines. This gets rid of the
> > most of the differences between mapped and straight buffer reads,
> > and tracks xfs_bufs directly in the IO context that is being used.
> > 
> > This is not yet a perfect solution, as xfs_db does different sized
> > IOs for the same block range which will throw warnings like:
> > 
> > xfs_db> inode 64
> > 7ffff7fde740: Badness in key lookup (length)
> > bp=(bno 0x40, len 8192 bytes) key=(bno 0x40, len 4096 bytes)
> > xfs_db>
> 
> Maybe we should use uncached buffer I/O in xfs_db, similar to what we do
> in the mount path in the kernel?

Possibly. I have thought about it, but we'd need a new interface and
a rework of the libxfs read/write code to do that, and that has
wider impact than just xfs_db. I also found lots of interesting
issues as a result of the re-read behaviour which I wouldn't have
easily found otherwise. i.e. the output is an early warning that
something isn't quite right in xfs_db, so it does have some use
right now.

> >     mp->m_flags = (LIBXFS_MOUNT_32BITINODES|LIBXFS_MOUNT_32BITINOOPT);
> > +   if (flags & LIBXFS_MOUNT_ROOTINOS)
> > +           mp->m_flags |= LIBXFS_MOUNT_ROOTINOS;
> > +
> >     mp->m_sb = *sb;
> >     INIT_RADIX_TREE(&mp->m_perag_tree, GFP_KERNEL);
> >     sbp = &(mp->m_sb);
> > @@ -866,6 +869,8 @@ libxfs_umount(xfs_mount_t *mp)
> >     int                     agno;
> >  
> >     libxfs_rtmount_destroy(mp);
> > +   if ((mp->m_flags & LIBXFS_MOUNT_ROOTINOS) && mp->m_rootip)
> > +           libxfs_iput(mp->m_rootip, 0);
> 
> Seems like the patch to remove m_rootip should go before this one?

Yeah, good idea.

> > -struct xfs_buf *
> > -libxfs_readbuf_map(struct xfs_buftarg *btp, struct xfs_buf_map *map, int 
> > nmaps,
> > -           int flags, const struct xfs_buf_ops *ops)
> > +int
> > +libxfs_readbufr_map(struct xfs_buftarg *btp, struct xfs_buf *bp,
> > +               struct xfs_buf_map *map, int nmaps, int flags)
> 
> Shouldn't these sort of changes go into a separate patch?

I can do that.

Thanks for looking at these patches, Christoph.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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