Messages in this thread | | | Date | Sun, 15 Feb 2009 13:48:07 +1100 | From | Dave Chinner <> | Subject | Re: vfs: Add MS_FLUSHONFSYNC mount flag |
| |
On Sat, Feb 14, 2009 at 10:03:53PM +0900, Fernando Luis Vázquez Cao wrote: > On Sat, 2009-02-14 at 22:24 +1100, Dave Chinner wrote: > > On Sat, Feb 14, 2009 at 01:29:28AM +0900, Fernando Luis Vazquez Cao wrote: > > > On Fri, 2009-02-13 at 23:20 +1100, Dave Chinner wrote: > > > > On Fri, Feb 13, 2009 at 12:20:17AM -0600, Eric Sandeen wrote: > > > > > I'm just a little leery of the "dangerous" mount option proliferation, I > > > > > guess. > > > > > > > > You're not the only one, Eric. It's bad enough having to explain to > > > > users what barriers do once they have lost data after a power loss, > > > > let alone confusing them further by adding more mount options they > > > > will get wrong by accident.... > > > > > > That is precisely the reason why we should use sensible defaults, which > > > in this case means enabling barriers and flushing disk caches on > > > fsync()/fdatasync() by default. > > > > > > Adding either a new mount option (as you yourself suggest below) or a > > > sysfs tunable is desirable for those cases when we really do not need to > > > flush the disk write cache to guarantee integrity (battery-backed block > > > devices come to mind), or we want to be fast at the cost of potentially > > > losing some data. > > > > Mount options are the wrong place for this. if you want to change > > the behaviour of the block device, then it should be at that level. > > To be more precise, what we are trying to change is the behavior of > fsync()/fdatasync(), which users might want to change on a per-partition > basis. I guess this is the reason the barrier switch was made a mount > option, and I just wanted to be consistent.
This has no place in the kernel. Use LD_PRELOAD to make fsync() a no-op.
> > No mount option - too confusing for someone to work out what > > combination of barriers and flushing for things to work correctly. > > As I suggested in a previous email, it is just a matter of using a safe > combination by default so that users do not need to figure out anything.
Too many users think that they need to specify everything rather than rely on defaults...
> > Just make filesystems issue the necessary flush calls or barrier IOs > > "ext3: call blkdev_issue_flush on fsync" and "ext4: call > blkdev_issue_flush on fsync" in this patch set implement just that for > ext3/4. > > > and allow the block devices to ignore flushes. > > Wouldn't it make more sense to avoid sending bios down the block layer > which we can know in advance are going to be ignored by the block > device?
As soon as the block layer reports EOPNOTSUPPORTED to a barrier IO, the filesystem will switch them off and not issue them anymore.
> > I don't think we want (1) at all, and I thought that if ext3/4 are using > > barriers then the barrier I/O issued by the journal does the flush > > already. Hence (3) is redundant, right? > > No, it is no redundant because a barrier is not issued in all cases. The > aforementioned two patches fix ext3/4 by emitting a device flush only > when necessary (i.e. when a barrier would not be emitted).
Then that is a filesystem fix, not something that requires VFS modifications or new mount options....
Cheers,
Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |