[nycbug-talk] DragonFly HAMMER filessytem
spork at bway.net
Wed Oct 17 16:43:27 EDT 2007
On Wed, 17 Oct 2007, Isaac Levy wrote:
> Hi All,
> On Oct 15, 2007, at 12:18 PM, Pete Wright wrote:
>> On Mon, Oct 15, 2007 at 11:44:45AM -0400, Yarema wrote:
>>> I've gathered you like the ZFS implementation in FreeBSD.
>>> Check out Matt Dillon's HAMMER filesystem design document:
>>> ... and why he why he chose not to use Sun's ZFS:
> Excellent docs, thanks Yarema for boiling this down to URL's with the
> simplest explanations!
>>> Anyway the December release of DragonFly 2.0 should have a usable
>>> fs. Should be fun having two kick ass filesystems coming out in
>>> BSDs next
> Agreed :)
> And to be honest, UFS2 isn't all that bad ;)
> Aside from grief as we all begin fsck'ing multi-TB volumes, it's a
> solid performer- and still *the* benchmark classic UNIX filesystem.
> We're lucky in *BSD-land.
>> yea this is really exciting! i think matt hit's the nail on the head
>> here (wow that's a bad pun) having hammer focus on his clustering
> I see what Hammer is trying to accomplish, and the clustering/
> replication goals are AMAZING- however, I have one big show-stoppers
> for me using it:
> "...A volume is thus limited to 16TB..."
It does look like Matt is planning for the future though, his announcement
HAMMER's storage management limits it to 32768 volumes, 32768 clusters
per volume, and 32768 16K filesystem buffers per cluster. A volume
is thus limited to 16TB and a HAMMER filesystem as a whole is limited
to 524288TB. HAMMER's on-disk structures are designed to allow future
expansion through expansion of these limits. In particular, the volume
id is intended to be expanded to a full 32 bits in the future and using
a larger buffer size will also greatly increase the cluster and volume
size limitations by increasing the number of elements the buffer-
restricted radix trees can manage."
So two things: only the components are limited to 16TB, a filesystem can
total 524288TB, and the "on-disk structures" are setup such that the 16TB
limit can be raised later without redesigning the whole thing.
Dragonfly should be quite the interesting OS in the next few years - it
sounds like clustering is his goal...
> I can't move foreword with this. Right now the largest filesystems I
> touch are just over 10TB, so I'm under the limit- but the people
> using them are outgrowing them at a quick pace. In another year I
> expect to be working with 30TB for single fileservers.
> (btw those boxes use UFS2 on FreeBSD-6-REL, and the boxes are SOOOO
> I don't mean to sound macho about the disk space, but it's a real and
> growing concern for me right now.
> Managing it (with new features) is one thing, Hammer and ZFS both
> provide great tools for dealing with the increased space- but the raw
> idea of simply storing more bits is most important.
> Maximum filesystem size comparison (what about maximum file size for
> Hammer btw?):
> Hammer: 16TB
> UFS2: 1YiB (1 Yobibyte = ) http://en.wikipedia.org/wiki/Yobibyte
> ZFS: 16EiB (Exbibytes) http://en.wikipedia.org/wiki/EiB
> No time to do the math and figure out how many TB fit into a Yobibyte
> or an Exbibyte, but as far as my little brain can comprehend, both
> UFS2 and ZFS will meet my needs in the coming years.
> Sidenote, pretty neat specs (someone should add an entry for Hammer?!):
>> I see ZFS as being a great candidate for SAN/NAS solutions - with alot
>> of nice features for jail's etc.
> YES. ZFS + Jail is SOOOOOO exciting to me!
>> hammer seems to be addressing another very important niche - a well
>> written clustered filesystem. execellent!
> Sure, yes- but can't it scale beyond 16TB?! Please?!?!
>> thanks for the heads up!
> talk mailing list
> talk at lists.nycbug.org
> We meet the first Wednesday of the month
> Be sure to join our Announce list at http://lists.nycbug.org
More information about the talk