linux-ext4 - Re: [PATCH v4 0/3] dioread

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: <20100115201521.GE7256@thunk.org>
Date:	Fri, 15 Jan 2010 15:15:21 -0500
From:	tytso@....edu
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH v4 0/3] dioread_nolock patch

On Fri, Jan 15, 2010 at 01:52:45PM -0600, Eric Sandeen wrote:
> 
> At least as far as that last bit goes, simply having the extents
> feature is not sufficient; we allow both formats of files to exist
> on a filesystem with the extents feature turned on.

... and I guess someone could be appending to a legacy file when the
system crashes.  I suppose we can at least exempt extent files from
ordered mode handling.

> As to the general idea I'll have to give it more thought. :)

Yeah, and we need to do a lot of performance and functional testing.
Jiaying has done a lot of testing of this in the past couple of
months, but more testing, especially power fail testing, is definitely
a good thing.  I also want to do power fail testing for journal
checksums and async commits so we can turn that feature on by default,
since with those features enabled, it almost doubles fs_mark
performance.  (Async commit is now badly named, what it does is
reduces the number of write barriers needed from two per commit to
just one.  But we do need to test it some more...)

This was more of a statement of intentions than a "we'll turn this on
by default in 2.3.34".  I figure we'll merge first, and then change
the default later, and still later we'll simplify the code paths by
removing the old code path.

Speaking of which, something more to think about --- does anybody
still care about nobh mode?  It was necessary to preserve lowmem for
32-bit kernels with lots of memory, and it was mainly useful for
database workloads.  But with 64-bit kernels, it's not clear the
tradeoffs of not caching the block number are really worth it any
more.  What would people think about potentially dropping the nobh
option and write paths from ext4?

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