On Mon, Apr 23, 2007 at 11:23:40PM +0100, Christoph Hellwig wrote:
> On Tue, Apr 24, 2007 at 08:16:23AM +1000, David Chinner wrote:
> > > > + INT_SET(sb->sb_fdblocks, ARCH_CONVERT,
> > > > mp->m_sb.sb_fdblocks);
> > > > + XFS_SB_UNLOCK(mp, s);
> > >
> > > This is really quite nasty. Should we at least force a cache flush here?
> > Well, that is what it's doing - xfs_log_sbcount() flushes the counters and
> > logs the changes to the superblock. If that fails (very rare) we've already
> > got the current values in mp->m_sb and so all we need to do is push them
> > into the disk superblock and write it.
> Sorry, should have been more detailed. I meant the disk cache, as in
> blkdev_issue_flush, to make sure the data hits the disk, even if it doesn't
> go through a transaction which would normally do that. (in the barriers case)
Ah, gotcha. Hmmm - if this is necessary, I may as well add the flush to
the closing of the buftargs - that way we will always be certain that
an unmount leaves everything on disk and not in disk caches. That sounds
like a better approach to me than putting an explicit flush in this
particular case. Sound fair?
SGI Australian Software Group