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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
