All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Phillip Susi <phillsusi@gmail.com>
Cc: Andreas Dilger <adilger@whamcloud.com>,
	Lukas Czerner <lczerner@redhat.com>,
	Jacek Luczak <difrost.kernel@gmail.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: getdents - ext4 vs btrfs performance
Date: Tue, 13 Mar 2012 17:33:04 -0400	[thread overview]
Message-ID: <20120313213304.GB11969@thunk.org> (raw)
In-Reply-To: <4F5FAC9C.9070607@gmail.com>

On Tue, Mar 13, 2012 at 04:22:52PM -0400, Phillip Susi wrote:
> 
> I think a format change would be preferable to runtime sorting.

Are you volunteering to spearhead the design and coding of such a
thing?  Run-time sorting is backwards compatible, and a heck of a lot
easier to code and test...

The reality is we'd probably want to implement run-time sorting
*anyway*, for the vast majority of people who don't want to convert to
a new incompatible file system format.  (Even if you can do the
conversion using e2fsck --- which is possible, but it would be even
more code to write --- system administrators tend to be very
conservative about such things, since they might need to boot an older
kernel, or use a rescue CD that doesn't have an uptodate kernel or
file system utilities, etc.)

> So the index nodes contain the hash ranges for the leaf block, but
> the leaf block only contains the regular directory entries, not a
> hash for each name?  That would mean that adding or removing names
> would require moving around the regular directory entries wouldn't
> it?

They aren't sorted in the leaf block, so we only need to move around
regular directory entries when we do a node split (and at the moment
we don't support shrinking directories), so we don't have to worry the
reverse case.

> I would think that hash collisions are rare enough that reading a
> directory block you end up not needing once in a blue moon would be
> chalked up under "who cares".  So just stick with hash, offset pairs
> to map the hash to the normal directory entry.

With a 64-bit hash, and if we were actually going to implement this as
a new incompatible feature, you're probably right in terms of
accepting the extra directory block search.

We would still have to implement the case where hash collisions *do*
exist, though, and make sure the right thing happens in that case.
Even if the chance of that happening is 1 in 2**32, with enough
deployed systems (i.e., every Android handset, etc.) it's going to
happen in real life.

					- Ted





  reply	other threads:[~2012-03-13 21:33 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29 13:52 getdents - ext4 vs btrfs performance Jacek Luczak
2012-02-29 13:55 ` Jacek Luczak
2012-02-29 13:55   ` Jacek Luczak
2012-02-29 14:07   ` Jacek Luczak
2012-02-29 14:07     ` Jacek Luczak
2012-02-29 14:07     ` Jacek Luczak
2012-02-29 14:21     ` Jacek Luczak
2012-02-29 14:21       ` Jacek Luczak
2012-02-29 14:21       ` Jacek Luczak
2012-02-29 14:42     ` Chris Mason
2012-02-29 14:55       ` Jacek Luczak
2012-03-01 13:35         ` Jacek Luczak
2012-03-01 13:50           ` Hillf Danton
2012-03-01 14:03             ` Jacek Luczak
2012-03-01 14:18               ` Chris Mason
2012-03-01 14:43                 ` Jacek Luczak
2012-03-01 14:43                   ` Jacek Luczak
2012-03-01 14:51                   ` Chris Mason
2012-03-01 14:51                     ` Chris Mason
2012-03-01 14:51                     ` Chris Mason
2012-03-01 14:57                     ` Jacek Luczak
2012-03-01 14:57                       ` Jacek Luczak
2012-03-01 14:57                       ` Jacek Luczak
2012-03-01 18:42                   ` Ted Ts'o
2012-03-02  9:51                     ` Jacek Luczak
2012-03-01  4:44 ` Theodore Tso
2012-03-01  4:44   ` Theodore Tso
2012-03-01  4:44   ` Theodore Tso
2012-03-01 14:38   ` Chris Mason
2012-03-01 14:38     ` Chris Mason
2012-03-02 10:05     ` Jacek Luczak
2012-03-02 10:05       ` Jacek Luczak
2012-03-02 10:05       ` Jacek Luczak
2012-03-02 14:00       ` Chris Mason
2012-03-02 14:16         ` Jacek Luczak
2012-03-02 14:16           ` Jacek Luczak
2012-03-02 14:16           ` Jacek Luczak
2012-03-02 14:26           ` Chris Mason
2012-03-02 14:26             ` Chris Mason
2012-03-02 19:32             ` Ted Ts'o
2012-03-02 19:50               ` Chris Mason
2012-03-05 13:10               ` Jan Kara
2012-03-03 22:41             ` Jacek Luczak
2012-03-03 22:41               ` Jacek Luczak
2012-03-04 10:25               ` Jacek Luczak
2012-03-04 10:25                 ` Jacek Luczak
2012-03-05 11:32                 ` Jacek Luczak
2012-03-05 11:32                   ` Jacek Luczak
2012-03-05 11:32                   ` Jacek Luczak
2012-03-06  0:37                   ` Chris Mason
2012-03-06  0:37                     ` Chris Mason
2012-03-08 17:02   ` Phillip Susi
2012-03-09 11:29 ` Lukas Czerner
2012-03-09 14:34   ` Chris Mason
2012-03-10  0:09   ` Andreas Dilger
2012-03-10  4:48     ` Ted Ts'o
2012-03-11 10:30       ` Andreas Dilger
2012-03-11 16:13         ` Ted Ts'o
2012-03-15 10:42           ` Jacek Luczak
2012-03-15 10:42             ` Jacek Luczak
2012-03-15 10:42             ` Jacek Luczak
2012-03-18 20:56             ` Ted Ts'o
2012-03-13 19:05       ` Phillip Susi
2012-03-13 19:53         ` Ted Ts'o
2012-03-13 20:22           ` Phillip Susi
2012-03-13 21:33             ` Ted Ts'o [this message]
2012-03-14  2:48               ` Yongqiang Yang
2012-03-14  2:51                 ` Ted Ts'o
2012-03-14 14:17                   ` Zach Brown
2012-03-14 16:48                     ` Ted Ts'o
2012-03-14 17:37                       ` Zach Brown
2012-03-14  8:12               ` Lukas Czerner
2012-03-14  9:29                 ` Yongqiang Yang
2012-03-14  9:29                   ` Yongqiang Yang
2012-03-14  9:29                   ` Yongqiang Yang
2012-03-14  9:38                   ` Lukas Czerner
2012-03-14 12:50                 ` Ted Ts'o
2012-03-14 14:34                   ` Lukas Czerner
2012-03-14 17:02                     ` Ted Ts'o
2012-03-14 19:17                   ` Chris Mason
2012-03-14 14:28               ` Phillip Susi
2012-03-14 16:54                 ` Ted Ts'o
2012-03-10  3:52 ` Ted Ts'o
2012-03-15  7:59   ` Jacek Luczak
2012-03-15  7:59     ` Jacek Luczak
2012-03-15  7:59     ` Jacek Luczak
  -- strict thread matches above, loose matches on Subject: below --
2012-02-29 13:31 Jacek Luczak
2012-02-29 13:51 ` Chris Mason
2012-02-29 14:00   ` Lukas Czerner
2012-02-29 14:05   ` Chris Mason

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=20120313213304.GB11969@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@whamcloud.com \
    --cc=difrost.kernel@gmail.com \
    --cc=lczerner@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillsusi@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.