linux-kernel - Re: Is nobh code still useful?

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 20 Sep 2009 20:17:20 +0200
From:	Jan Kara <jack@...e.cz>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Theodore Tso <tytso@....edu>,
	Badari Pulavarty <pbadari@...ibm.com>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Is nobh code still useful?

On Fri 18-09-09 16:25:54, Arjan van de Ven wrote:
> On Fri, 18 Sep 2009 10:12:26 -0400
> Theodore Tso <tytso@....edu> wrote:
> > On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote:
> > >
> > > Originally it was supported on ext2. I added support nobh support
> > > for ext3. At that time, the main
> > > issue/complaint was that, these bufferheads consume memory from  
> > > ZONE_NORMAL causing
> > > memory pressure on 32-bit (i386) configurations.
> > 
> > Specifically, it matters on very large configuration systems (i.e.,
> > 32GB-64GB using PAE-36) that today we'd probably just say, "use
> > x86_64, you moron".  It would probably matter if someone were to want
> > to upgrade a non-64-bit capable machine to a newer kernel.  
> > 
> > Dropping nobh from ext3 at this point might prevent some of these
> > older systems from upgrading, I'm not sure how much we would care; on
> > the one hand, these machines tended to be pretty expensive, so people
> > would probably want to use them for a while.  On the other hand, it
> > has been over five years now since x86_64 machines have been
> > available, and many of these customers are highly unlikely to want to
> > upgrade anyway.
> 
> isn't the converse to just make nobh the default but not an option a
> better approach then?
> I forgot why this was a good idea to be an option again ;-)
  Buffer heads cache useful information so without them, IO may become more
more CPU intensive (allocating and freeing temporary buffer heads, setting
up block mapping etc.).
  Also some features like delayed allocation need buffer head bits - that
is why e.g. ext4 doesn't really support nobh mount option.

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/