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-next>] [day] [month] [year] [list]
Message-ID: <20110126071200.GE32261@tux1.beaverton.ibm.com>
Date:	Tue, 25 Jan 2011 23:12:00 -0800
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Tejun Heo <tj@...nel.org>, Vivek Goyal <vgoyal@...hat.com>,
	axboe@...nel.dk, tytso@....edu, shli@...nel.org, neilb@...e.de,
	adilger.kernel@...ger.ca, jack@...e.cz, snitzer@...hat.com,
	linux-kernel@...r.kernel.org, kmannth@...ibm.com, cmm@...ibm.com,
	linux-ext4@...r.kernel.org, rwheeler@...hat.com, hch@....de,
	josef@...hat.com
Subject: [PATCHSET] Refactor barrier=/nobarrier flags from fs to block layer

Hello,

>From what I can tell, most of the filesystems that know how to issue commands
to flush the write cache also have some mechanism for the user to override
whether or not the filesystem actually issues those flushes.  Unfortunately,
the term "barrier" is obsolete having been changed into flushes in 2.6.36, and
many of the filesystems implement the mount options with slightly different
syntaxes (barrier=[0|1|none|flush], nobarrier, etc).

This patchset adds to the block layer a sysfs knob that an administrator can
use to disable flushes, and removes the mount options from the filesystem code.
As a starting point, I'm removing the mount options and flush toggle from
jbd2/ext4.

Anyway, I'm looking for some feedback about refactoring the barrier/flush
control knob into the block layer.  It sounds like we want a knob that picks
the safest option (issue flushes when supported) unless the administrator
decides that it is appropriate to do otherwise.  I suspect that there are good
arguments for not having a knob at all, and good arguments for a safe knob.
However, since I don't see the barrier options being removed en masse, I'm
assuming that we still want a knob somewhere.  Do we need the ignore_fua knob
too?  Is this the proper way to deprecate mount options out of filesystems?

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ