Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 May 2001 00:11:13 -0400 (EDT)
From:      "Albert D. Cahalan" <acahalan@cs.uml.edu>
To:        ccf@master.ndi.net, gordont@bluemtn.net, jkh@osd.bsdi.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: technical comparison
Message-ID:  <200105220411.f4M4BDX101825@saturn.cs.uml.edu>

next in thread | raw e-mail | index | archive | help

Gordon Tetlow writes:
> On Mon, 21 May 2001, Jordan Hubbard wrote:
>> [Charles C. Figueire]

>>> c) A filesystem that will be fast in light of tens of thousands of
>>>    files in a single directory (maybe even hundreds of thousands)
>>
>> I think we can more than hold our own with UFS + soft updates.  This
>> is another area where you need to get hard numbers from the Linux
>> folks.  I think your assumption that "Linux handles this effectively"
>> is flawed and I'd like to see hard numbers which prove otherwise;
>> you should demand no less.
>
> Also point out the reliability factor here which is a bit harder to point
> to a magic number and "See, we *are* better!" ext2 runs async by default
> which can lead to nasty filesystem corruption in the event of a power
> loss. With softupdates, the filesystem metadata will always be in sync and
> uncorrupted (barring media failure of course).

It should be immediately obvious that ext2 is NOT the filesystem
being proposed, async or not. For large directories, ext2 sucks
as bad as UFS does. This is because ext2 is a UFS clone.

The proposed filesystem is most likely Reiserfs. This is a true
journalling filesystem with a radically non-traditional layout.
It is no problem to put millions of files in a single directory.
(actually, the all-in-one approach performs better than a tree)

XFS and JFS are similarly capable, but Reiserfs is well tested
and part of the official Linux kernel. You can get the Reiserfs
team to support you too, in case you want to bypass the normal
filesystem interface for even better performance.

So, no async here, and "UFS + soft updates" can't touch the
performance on huge directories.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105220411.f4M4BDX101825>