linux-kernel - Re: [PATCH 00/23] per device dirty throttling -v8

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]

Message-ID: <20070805224646.GC32217@thunk.org>
Date:	Sun, 5 Aug 2007 18:46:47 -0400
From:	Theodore Tso <tytso@....edu>
To:	Florian Weimer <fw@...eb.enyo.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, miklos@...redi.hu, neilb@...e.de,
	dgc@....com, tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
	trond.myklebust@....uio.no, yingchao.zhou@...il.com,
	richard@....demon.co.uk
Subject: Re: [PATCH 00/23] per device dirty throttling -v8

On Sat, Aug 04, 2007 at 09:16:35PM +0200, Florian Weimer wrote:
> * Andrew Morton:
> 
> > The easy preventive is to mount with data=writeback.  Maybe that should
> > have been the default.
> 
> The documentation I could find suggests that this may lead to a
> security weakness (old data in blocks of a file that was grown just
> before the crash leaks to a different user).  XFS overwrites that data
> with zeros upon reboot, which tends to irritate users when it happens.
> 
> From this point of view, data=ordered doesn't seem too bad.

The other alternative which addresses the security concern is
data=journal, which if you have a big enough journal, can sometimes be
*faster* than data=ordered or even data=writeback, because it reduces
seeking.  The problem is that it's workload dependent which is better;
if the workload is very, very heavy on data writes, each data block
ends up getting writen twice, once to the journal and once to the
final location on disk, and so this halves your total max write
bandwidth.  But if the workload doesn't do as much writing, and is
very seeky, and or is very, very, fsync()-centric (like a mailhub),
data=journal is probably the right answer.

						- Ted
-
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/