public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Mike Waychison <mikew@google.com>
Cc: Theodore Tso <tytso@mit.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sreenivasa Busam <sreenivasac@google.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: fallocate support for bitmap-based files
Date: Sat, 30 Jun 2007 01:14:36 -0400	[thread overview]
Message-ID: <20070630051436.GB5535@schatzie.adilger.int> (raw)
In-Reply-To: <46858716.2050901@google.com>

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.

  reply	other threads:[~2007-06-30  5:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 20:01 fallocate support for bitmap-based files Andrew Morton
2007-06-29 20:36 ` Dave Kleikamp
2007-06-29 20:52   ` Mike Waychison
2007-06-29 21:24     ` Dave Kleikamp
2007-06-29 20:55 ` Theodore Tso
2007-06-29 21:38   ` Andrew Morton
2007-06-29 22:07     ` Mike Waychison
2007-07-04 23:11       ` Valerie Henson
2007-07-06 21:15         ` Mike Waychison
2007-06-29 21:46   ` Andreas Dilger
2007-06-29 22:26     ` Mike Waychison
2007-06-30  5:14       ` Andreas Dilger [this message]
2007-06-30 14:31         ` Mingming Cao
2007-06-30 14:13 ` Mingming Cao
2007-06-30 17:29   ` Andreas Dilger
2007-07-02 14:44     ` Mingming Cao
2007-07-02 17:44   ` Badari Pulavarty
2007-07-06 21:33     ` Mike Waychison
2007-07-07  2:05       ` Badari Pulavarty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070630051436.GB5535@schatzie.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=sreenivasac@google.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox