linux-ext4 - Re: fallocate support for bitmap-based files

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:	Sat, 30 Jun 2007 01:14:36 -0400
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Theodore Tso <tytso@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sreenivasa Busam <sreenivasac@...gle.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: fallocate support for bitmap-based files

On Jun 29, 2007  18:26 -0400, Mike Waychison wrote:
> Andreas Dilger wrote:
> >I don't think ext2 is safe for > 8TB filesystems anyways, so this
> >isn't a huge loss.
> 
> This is reference to the idea of overloading the high-bit and not 
> related to the >PAGE_SIZE blocks correct?

Correct - just that the high-bit use wouldn't unduely impact the
already-existing 8TB limit of ext2.

The other thing to note is that Val Henson already ported the ext3
reservation code to ext2, so this is a pretty straight forward
option for you and also doesn't affect the on-disk format.

> >The other possibility is, assuming Google likes ext2 because they
> >don't care about e2fsck, is to patch ext4 to not use any
> >journaling (i.e. make all of the ext4_journal*() wrappers be
> >no-ops).  That way they would get extents, mballoc and other speedups.
> 
> We do care about the e2fsck problem, though the cost/benefit of e2fsck 
> times/memory problems vs the overhead of journalling doesn't weigh in 
> journalling's favour for a lot of our per-spindle-latency bound 
> applications.  These apps manage to get pretty good disk locality 
> guarantees and the journal overheads can induce undesired head movement.

You could push the journal to a separate spindle, but that may not be
practical.

> ext4 does look very promising, though I'm not certain it's ready for our 
> consumption.

FYI, the extents code (the most complex part of ext4) has been running for
a couple of years on many PB of storage at CFS, so it is by no means new
and untried code.  There are definitely less-well tested changes in ext4
but they are mostly straight forward.  I'm not saying you should jump right
into ext4, but it isn't as far away as you might think.

> What are people's thoughts on providing ext3 non-journal mode?  We could 
> benefit from several of the additions to ext3 that aren't available in 
> ext2 and disabling journalling there sounds much more feasible for us 
> instead of trying to backport each ext3 component to ext2.

This is something we've talked about for a long time, and I'd be happy to
have this possibility.  This would also allow you to take similar advantage
of extents, the improved allocator and other features.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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