| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: review [1 of 3]: lazy superblock counters - core kernel, David Chinner |
|---|---|
| Next by Date: | Re: review: allocate alloc args, David Chinner |
| Previous by Thread: | Re: review [1 of 3]: lazy superblock counters - core kernel, David Chinner |
| Next by Thread: | Re: review [1 of 3]: lazy superblock counters - core kernel, David Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |