Re: [PATCH 2/7] ext3: call blkdev_issue_flush() on fsync()

[Jeff Garzik]

Jens Axboe wrote:
> On Tue, Mar 31 2009, Tejun Heo wrote:
> > Hello,
> >
> > Theodore Tso wrote:
> > > On Mon, Mar 30, 2009 at 10:15:51AM -0400, Chris Mason wrote:
> > > > I'm not sure we want to stick Fernando with changing how barriers are
> > > > done in individual filesystems, his patch is just changing the existing
> > > > call points.
> > > Well, his patch actually added some calls to block_issue_flush().  But
> > > yes, it's probably better if he just changes the existing call points,
> > > and we can have the relevant filesystem maintainers double check to
> > > make sure that there aren't any new call points which are needed.
> > How about having something like blk_ensure_cache_flushed() which
> > issues flush iff there hasn't been any write since the last flush?
> > It'll be easy to implement and will filter out duplicate flushes in
> > most cases.
>
> My original ide implementation of flushes actually did this. My memory
> is a little hazy on why it was dropped, I'm guessing because it
> basically never triggered anyway.

Yeah, and it probably wouldn't trigger today unless we add new code that 
starts generating enough duplicate cache flushes for this to be 
significant...

And since duplicate cache flushes are harmless to the drive, you're only 
talking about no-op ATA command overhead.  Which is only mildly notable 
on legacy IDE (eight or so inb/outb operations).

I would put duplicate cache flush filtering way, way down on the 
priority list, IMO.

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/