linux-kernel - Re: vfs: Add MS_FLUSHONFSYNC mount flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 15 Feb 2009 22:29:43 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....edu>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Christoph Hellwig <hch@...radead.org>,
	Jeff Garzik <jeff@...zik.org>,
	Eric Sandeen <sandeen@...hat.com>, Jan Kara <jack@...e.cz>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>, fernando@....ac.jp,
	Ric Wheeler <rwheeler@...hat.com>
Subject: Re: vfs: Add MS_FLUSHONFSYNC mount flag

Theodore Tso wrote:
> On Sun, Feb 15, 2009 at 04:23:26PM +0900, Fernando Luis Vázquez Cao wrote:
>> You mentioned "we should integrate this with the barrier settings". Do
>> you imply we should make it a per-device tunable too? Should we keep the
>> barrier-related mount options some filesystems provide?
>>
> 
> Making barriers to be a per-device tunable makes sense.  The only
> reason why we kept it as a mount option in ext4 is for benchmarking
> purposes, and in ext3, because the filesystem predated the barrier
> code, and there was a desire to be able to benchmark with and without
> the old behavior --- and because akpm is still worried about the
> performance hit of the barrier code, so he's been resistant about
> change the default for ext3.
> 
>        	   				- Ted

I agree that making barriers a per-device tunable probably does make the
most sense.  And talking w/ Dave, he points out that if it were this
way, the fs could just issue barrier IOs at every appropriate place, and
the bdev would just ignore them if they got tuned off, instead of the
current fs world of trying a barrier, always watching out for
-EOPNOTSUPP coming back up, then disabling barriers, etc.

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