21 ms·

Initial Hammer2 filesystem implementation

228 points by joeschmoe3 9y ago

gigatexal 9y ago
Dillon, I had always thought was a hack when he forked FreeBSD at 4.x but he’s proven to have some novel ideas when it comes to these things and I’m looking forward to trying out the production ready Hammer2 FS
- jacobush 9y ago
  I have great respect for his ability to get shit done ever since Amiga days, so my thought was not "a hack" but rather - "how can he have this much patience and stamina?!"
  - laumars 9y ago
    I'm not aware of this work on the Amiga. What kind of projects was he involved in?
    - rodgerd 9y ago
      The DICE C compiler/IDE was his best-known bit of work.
jitl 9y ago
Very exciting to see implementation progress on HAMMER2. Some basics about the design: - This is DragonflyBSD's next-gen filesystem. - copy-on-write, implying snapshots and such, like ZFS, but snapshots are writable. - compression and de-duplication, like ZFS - a clustering system - extra care to reduce RAM needs, in contrast to ZFS - extra care to allow pre-allocation of files by writing zeros, something that will make SQL databases easier to run performantly on HAMMER2 than on ZFS And much more. The design doc is an interesting read, take a look: https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/sys/vfs/hammer2/DESIGN https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...
- Mayzie 9y ago
  I'm curious, how does it perform against ZFS and Btrfs (and probably a non-COW filesystem, like EXT4)? Are there any preliminary benchmarks available? Does it support RAID and subvolumes like Btrfs? How is the stability?
  - digitalzombie 9y ago
    It's been years and it's one dude that's doing it iirc. > Are there any preliminary benchmarks available? He spent years just to write the doc and spec. And the post just said the preliminary code will be in September so that's probably a no. Even with the september code being posted, preliminary isn't going to mean much because it most likely have very little features compare to ZFS and Btrfs. You probably have to wait longer for a fair comparison... IIRC it's a one man team and the dude is a unicorn.
- chongli 9y ago
  snapshots are writable Isn't that an oxymoron? I thought the entire point of a snapshot was that it's an immutable record of the filesystem at a moment in time. extra care to reduce RAM needs, in contrast to ZFS ZFS utilizes a lot of RAM for caching. That's not the same thing as needing a lot of RAM. I've seen this same complaint about modern operating systems. People will buy a lot of RAM and then get annoyed when they see the OS making use of it. As long as the memory is available to be allocated to applications, why should we care whether or not the operating system makes use of it?
  - tedunangst 9y ago
    Is it better if we call a snapshot a branch point? I believe the complaint about ZFS and RAM is that the caching cannot be considered optional. Performance is substantially worse than other filesystems with more modestly sized caches, so the memory isn't really available to applications.
    - chongli 9y ago
      Performance is substantially worse than other filesystems with more modestly sized caches, so the memory isn't really available to applications. Is that in comparison to other filesystems that provide the same level of data integrity as ZFS? Otherwise you're comparing apples and oranges.
pmoriarty 9y ago
Is there any work to get HAMMER2 on Linux?
- jacquesm 9y ago
  A fuse port would seem to be the way to go.
  - dbsddev 9y ago
    You are so full of crap sometimes. A FUSE port would go against many of the design principles of HAMMER2. You do understand how FUSE works, right?
  - sipos 9y ago
    This is certainly the easiest way to get a working implementation, yes. There is an existing (but I don't think maintained) FUSE port of HAMMER and it would not be a huge amount of work to have HAMMER2 FUSE support I don't think. I am interested in a kernel port of HAMMER/HAMMER2 because I think this is likely to give the best performance in the long run.
- blinkingled 9y ago
  Portability doesn't seem to have been a primary goal for HAMMER/2 - I remember reading on mailing list that the reason was to not let portability impede other goals. Thus even with FreeBSD a port would not be straight forward because of VFS API differences, required scheduler support and buffer cache implementation differences[1]. Linux I would assume is even more work. [1]https://wiki.freebsd.org/PortingHAMMERFS https://wiki.freebsd.org/PortingHAMMERFS
  - craftkiller 9y ago
    According to this forum post[1] HAMMER2 is supposed to be portable, but I don't see any mention of that on the HAMMER2 design document. [1] https://forums.freebsd.org/threads/49789/#post-278338 https://forums.freebsd.org/threads/49789/#post-278338
alberth 9y ago
It's amazing how much work the Dfly has acompkksjed given how few developers there are. I really hope Dfly gets more adoption and broader use.
blue1 9y ago
Does H2 feature data integrity (checksums etc)? For me that is one of the best features of ZFS
- mjevans 9y ago
  It's a short email post. Yes, they're build in to the inode structure and would be used for de-duplication. (However I'd hope that for a production system there's still a /verify/ pass on the data being de-duped to confirm it actually __is__ a dupe.)
  - mrighele 9y ago
    Interestingly, this is not what happens in ZFS [1] (unless the defaults have changed since a few years ago): If you accept the mathematical claim that a secure hash like SHA256 has only a 2\^-256 probability of producing the same output given two different inputs, then it is reasonable to assume that when two blocks have the same checksum, they are in fact the same block. You can trust the hash. An enormous amount of the world's commerce operates on this assumption, including your daily credit card transactions. However, if this makes you uneasy, that's OK: ZFS provies a 'verify' option that performs a full comparison of every incoming block with any alleged duplicate to ensure that they really are the same, and ZFS resolves the conflict if not. To enable this variant of dedup, just specify 'verify' instead of 'on': [1] https://blogs.oracle.com/bonwick/zfs-deduplication-v2 https://blogs.oracle.com/bonwick/zfs-deduplication-v2
    - loeg 9y ago
      And HAMMER2 will use even larger 512 bit hashes for blind dedupe, making the possibility of a collision causing data loss vanishingly small.
      - Dylan16807 9y ago
        Bah, 256 bits is already so vanishingly small it's hard to comprehend. If you put a thousand disks into a pool you might reach 2^40 blocks, leaving you with 256-80=176 bits of margin. That is never going to collide. You could make such a filesystem for each atom on Earth and the odds of a single collision would be less than 0.1% You could put a billion disks in a pool and still have 136 bits of margin. 512 bit hashing is basically placebo.
beastman82 9y ago
This sounds like a weapon system designed by Stark Industries.
- qbrass 9y ago
  Not Hammer Industries?
  - beastman82 9y ago
    bah! yes that's much better.
TallGuyShort 9y ago
Other than the design doc (which, being BSD, is bound to be the primary source of truth), does anyone know of any tech talks or more visual presentations about the design of Hammer FS? I sure do love being available, but for just starting to wrap your head around an FS architecture, talking through some slides would sure be neat. I'm not immediately seeing much on YouTube...
- JdeBP 9y ago
  Well, there's BSD Now #53, although that's primarily verbal.

228 points by joeschmoe3 9y ago

Dillon, I had always thought was a hack when he forked FreeBSD at 4.x but he’s proven to have some novel ideas when it comes to these things and I’m looking forward to trying out the production ready Hammer2 FS

jacobush 9y ago
I have great respect for his ability to get shit done ever since Amiga days, so my thought was not "a hack" but rather - "how can he have this much patience and stamina?!"
- laumars 9y ago
  I'm not aware of this work on the Amiga. What kind of projects was he involved in?
  - rodgerd 9y ago
    The DICE C compiler/IDE was his best-known bit of work.

jitl 9y ago

Very exciting to see implementation progress on HAMMER2. Some basics about the design: - This is DragonflyBSD's next-gen filesystem. - copy-on-write, implying snapshots and such, like ZFS, but snapshots are writable. - compression and de-duplication, like ZFS - a clustering system - extra care to reduce RAM needs, in contrast to ZFS - extra care to allow pre-allocation of files by writing zeros, something that will make SQL databases easier to run performantly on HAMMER2 than on ZFS And much more. The design doc is an interesting read, take a look: https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/sys/vfs/hammer2/DESIGN https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...

Mayzie 9y ago
I'm curious, how does it perform against ZFS and Btrfs (and probably a non-COW filesystem, like EXT4)? Are there any preliminary benchmarks available? Does it support RAID and subvolumes like Btrfs? How is the stability?
- digitalzombie 9y ago
  It's been years and it's one dude that's doing it iirc. > Are there any preliminary benchmarks available? He spent years just to write the doc and spec. And the post just said the preliminary code will be in September so that's probably a no. Even with the september code being posted, preliminary isn't going to mean much because it most likely have very little features compare to ZFS and Btrfs. You probably have to wait longer for a fair comparison... IIRC it's a one man team and the dude is a unicorn.
chongli 9y ago
snapshots are writable Isn't that an oxymoron? I thought the entire point of a snapshot was that it's an immutable record of the filesystem at a moment in time. extra care to reduce RAM needs, in contrast to ZFS ZFS utilizes a lot of RAM for caching. That's not the same thing as needing a lot of RAM. I've seen this same complaint about modern operating systems. People will buy a lot of RAM and then get annoyed when they see the OS making use of it. As long as the memory is available to be allocated to applications, why should we care whether or not the operating system makes use of it?
- tedunangst 9y ago
  Is it better if we call a snapshot a branch point? I believe the complaint about ZFS and RAM is that the caching cannot be considered optional. Performance is substantially worse than other filesystems with more modestly sized caches, so the memory isn't really available to applications.
  - chongli 9y ago
    Performance is substantially worse than other filesystems with more modestly sized caches, so the memory isn't really available to applications. Is that in comparison to other filesystems that provide the same level of data integrity as ZFS? Otherwise you're comparing apples and oranges.

pmoriarty 9y ago

Is there any work to get HAMMER2 on Linux?

jacquesm 9y ago
A fuse port would seem to be the way to go.
- dbsddev 9y ago
  You are so full of crap sometimes. A FUSE port would go against many of the design principles of HAMMER2. You do understand how FUSE works, right?
- sipos 9y ago
  This is certainly the easiest way to get a working implementation, yes. There is an existing (but I don't think maintained) FUSE port of HAMMER and it would not be a huge amount of work to have HAMMER2 FUSE support I don't think. I am interested in a kernel port of HAMMER/HAMMER2 because I think this is likely to give the best performance in the long run.
blinkingled 9y ago
Portability doesn't seem to have been a primary goal for HAMMER/2 - I remember reading on mailing list that the reason was to not let portability impede other goals. Thus even with FreeBSD a port would not be straight forward because of VFS API differences, required scheduler support and buffer cache implementation differences[1]. Linux I would assume is even more work. [1]https://wiki.freebsd.org/PortingHAMMERFS https://wiki.freebsd.org/PortingHAMMERFS
- craftkiller 9y ago
  According to this forum post[1] HAMMER2 is supposed to be portable, but I don't see any mention of that on the HAMMER2 design document. [1] https://forums.freebsd.org/threads/49789/#post-278338 https://forums.freebsd.org/threads/49789/#post-278338

alberth 9y ago

It's amazing how much work the Dfly has acompkksjed given how few developers there are. I really hope Dfly gets more adoption and broader use.

blue1 9y ago

Does H2 feature data integrity (checksums etc)? For me that is one of the best features of ZFS

mjevans 9y ago
It's a short email post. Yes, they're build in to the inode structure and would be used for de-duplication. (However I'd hope that for a production system there's still a /verify/ pass on the data being de-duped to confirm it actually __is__ a dupe.)
- mrighele 9y ago
  Interestingly, this is not what happens in ZFS [1] (unless the defaults have changed since a few years ago): If you accept the mathematical claim that a secure hash like SHA256 has only a 2\^-256 probability of producing the same output given two different inputs, then it is reasonable to assume that when two blocks have the same checksum, they are in fact the same block. You can trust the hash. An enormous amount of the world's commerce operates on this assumption, including your daily credit card transactions. However, if this makes you uneasy, that's OK: ZFS provies a 'verify' option that performs a full comparison of every incoming block with any alleged duplicate to ensure that they really are the same, and ZFS resolves the conflict if not. To enable this variant of dedup, just specify 'verify' instead of 'on': [1] https://blogs.oracle.com/bonwick/zfs-deduplication-v2 https://blogs.oracle.com/bonwick/zfs-deduplication-v2
  - loeg 9y ago
    And HAMMER2 will use even larger 512 bit hashes for blind dedupe, making the possibility of a collision causing data loss vanishingly small.
    - Dylan16807 9y ago
      Bah, 256 bits is already so vanishingly small it's hard to comprehend. If you put a thousand disks into a pool you might reach 2^40 blocks, leaving you with 256-80=176 bits of margin. That is never going to collide. You could make such a filesystem for each atom on Earth and the odds of a single collision would be less than 0.1% You could put a billion disks in a pool and still have 136 bits of margin. 512 bit hashing is basically placebo.

beastman82 9y ago

This sounds like a weapon system designed by Stark Industries.

qbrass 9y ago
Not Hammer Industries?
- beastman82 9y ago
  bah! yes that's much better.

TallGuyShort 9y ago

Other than the design doc (which, being BSD, is bound to be the primary source of truth), does anyone know of any tech talks or more visual presentations about the design of Hammer FS? I sure do love being available, but for just starting to wrap your head around an FS architecture, talking through some slides would sure be neat. I'm not immediately seeing much on YouTube...

JdeBP 9y ago
Well, there's BSD Now #53, although that's primarily verbal.