xfs
[Top] [All Lists]

Re: review [1 of 3]: lazy superblock counters - core kernel

To: David Chinner <dgc@xxxxxxx>
Subject: Re: review [1 of 3]: lazy superblock counters - core kernel
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 23 Apr 2007 23:23:40 +0100
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20070423221622.GL32602149@xxxxxxxxxxxxxxxxx>
References: <20070419231459.GX48531920@xxxxxxxxxxxxxxxxx> <20070423220010.GA18325@xxxxxxxxxxxxx> <20070423221622.GL32602149@xxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.2i
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)


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