Re: XFS metadata flushing design - current and future

[Christoph Hellwig <hch@infradead.org>]

On Mon, Aug 29, 2011 at 11:01:49AM +1000, Dave Chinner wrote:
> Right, that's how buffers are flushed, but for some metadata there
> is a layer above this - the in-memory object that needs to be
> flushed to the buffer before the buffer can be written. Inodes and
> dquots fall into this category, so describing how they are flushed
> would also be a good idea. something like:

Sounds fine.

> Delwri means the object is locked and written to the backing buffer,
> and the buffer is then written via it's delwri mechanism. The object
> remains locked (and so cannot be written to the buffer again) until
> the backing buffer is written to disk and marked clean. This allows
> multiple objects in the one buffer to be written at different times
> but be cleaned in a single buffer IO.

Locked is a bit to simple here - we keep the flush lock, but not the
main object lock.

> > inodes marked dirty directly using xfs_iflush.
> > 
> > The quotacheck code marks dquots dirty, just to flush them at the end of
> > the quotacheck operation.
> 
> This is safe because the filesystem isn't "open for business" until
> the quotacheck completes. The quotacheck needed flags aren't cleared
> until all the updates are on disk, so this doesn't need tobe done
> transactionally.

Yes, it's safe - but another different layer of dirty metadata to track.

> > 
> > We should get rid of both the reliance of the VFS writeback tracking, and
> > XFS-internal non-AIL metadata flushing.
> 
> I'm assuming you mean VFS level dirty inode writeback tracking, not
> dirty page cache tracking?

Yes, I'll clarify it.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs