Messages in this thread | | | Date | Wed, 01 Apr 2009 10:03:21 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 2/7] ext3: call blkdev_issue_flush() on fsync() |
| |
Jeff Garzik wrote: > 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...
Well, the thread was about adding such a call, so...
> 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.
Yeap, unless FS guys need it, there's no reason to push it. Although having dup flush detection Theodore described (w/ callstack saving at issue time) would be nice for debugging.
Thanks.
-- tejun
| |