6 ms·

Very exciting to see implementation progress on HAMMER2. Some basics about the design: - This is DragonflyBSD's next-gen filesystem. - copy-on-write, implying

by 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.
    - tedunangst 9y ago
      You didn't say the memory use was justified by providing better integrity. You said it was optional.
      - chongli 9y ago
        Yes, the memory use is optional. Pick two: 1) data integrity 2) low memory use 3) performance
        dozzie 9y ago
        With ZFS I hear it's "pick one, and you cannot pick `low memory'".
        aidenn0 9y ago
        You can run ZFS with megabytes of ram, it's just slow, so it is pick 2. That being said, ZFS metadata is much bigger than it needs to be (most infamously dedupe has this issue).
wahern 9y ago
The original plan for HAMMER2 included multi-master synchronous replication. I don't know if that's still on the roadmap, or if something less ambitious is planned. IIRC, years ago Dillon sold some proprietary synchronous multi-master replication product that provided ACID guarantees while also being relatively performant. (Because synchronous multi-master had historically been quite slow.) I always thought HAMMER2's replication model was going to be an evolution of that tech.
- lobster_johnson 9y ago
  Dillon's database was called Backplane, and most of it was open source. I was always disappointed that he never (as far as I know) finished it, because it seemed very promising.
X86BSD 9y ago
If I were the Linux camp, I would seriously look at the work required to port this to the kernel. Since they can't mainline zfs this may be their next best option. Not that they will look outside their echo chamber but they should.
- jlgaddis 9y ago
  The first release -- which will have very few of the planned features -- hasn't even happened yet. If I were "the Linux camp", I wouldn't even bother looking into H2 for at least another five years or so.
takeda 9y ago
I'm glad Hammer FS exist, it is always great to have options, and new filesystems have more to build on. But this one seems weird to me: > copy-on-write, implying snapshots and such, like ZFS, but snapshots are writable. snapshot by definition should be read-only, also ZFS allows to create a new filesystem from snapshot (through zfs clone) which is also O(1) operation.
- antongribok 9y ago
  Read-only and read-write snapshots are possible with LVM, ZFS, Btrfs, and many commercial storage solutions. One reason why you would want a writable snapshot is during backup validation. An application may need to do crash recovery before being able to read data, and having a writable filesystem makes things a lot easier. I know that ZFS and LVM both send writes to a separate area, so the original snapshot is never modified (don't know about Btrfs implementation details).
  - takeda 9y ago
    Yes, what I said in ZFS you can instantly (and without using extra space) create a writable filesystem from snapshot using zfs clone (you can create multiple filesystems from one snapshot), but snapshots by itself are always read only.
- Someone 9y ago
  That looks a bit like git versus svn. So, it _might_ be an insane idea that ends up being a good idea. Especially if the default is to have a read only snapshot, I do not rule that out.
Dylan16807 9y ago
How does the deduplication work, in terms of user interface and performance? For comparison: ZFS has an online-only dedup, so it can save space as data is written, but it can't combine identical pieces of already-written data. It also scatters the segments of files to the winds, needing lots of ram and fast disks or it slows to a crawl. BTRFS has mostly-offline dedup, so it doesn't save space as data is written, but you can combine identical pieces of data later. You can also make CoW copies of files instantly. It has minimal performance impact.
- antongribok 9y ago
  I believe the correct terms are inline vs. post-processing deduplication. There are pros and cons to each approach, and as usual with storage, a lot depends on implementation and workload.
  - Dylan16807 9y ago
    > I believe the correct terms are inline vs. post-processing deduplication. Thanks. > There are pros and cons to each approach, and as usual with storage, a lot depends on implementation and workload. I would probably argue that the biggest factors in different performance between ZFS and BTRFS deduplication are nearly independent of when the deduplication happens, and boil down to implementation decisions specific to those two filesystems.
  - snovv_crash 9y ago
    The term online and offline are also correct, although they tend to be used in the machine learning field more.
    - antongribok 9y ago
      Offline is a completely different term when speaking about filesystems. Offline means that the filesystem needs to be unmounted before an operation can proceed. For example some filesystems can be grown online, but can shrink only offline.
needusername 9y ago
> 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 I always though it care about performance of SQL databases you bypass the filesystem / kernel and go directly to the LUN with something like ASM.

by jitl 9y ago

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.
  - tedunangst 9y ago
    You didn't say the memory use was justified by providing better integrity. You said it was optional.
    - chongli 9y ago
      Yes, the memory use is optional. Pick two: 1) data integrity 2) low memory use 3) performance
      - dozzie 9y ago
        With ZFS I hear it's "pick one, and you cannot pick `low memory'".
        aidenn0 9y ago
        You can run ZFS with megabytes of ram, it's just slow, so it is pick 2. That being said, ZFS metadata is much bigger than it needs to be (most infamously dedupe has this issue).

wahern 9y ago

The original plan for HAMMER2 included multi-master synchronous replication. I don't know if that's still on the roadmap, or if something less ambitious is planned. IIRC, years ago Dillon sold some proprietary synchronous multi-master replication product that provided ACID guarantees while also being relatively performant. (Because synchronous multi-master had historically been quite slow.) I always thought HAMMER2's replication model was going to be an evolution of that tech.

lobster_johnson 9y ago
Dillon's database was called Backplane, and most of it was open source. I was always disappointed that he never (as far as I know) finished it, because it seemed very promising.

X86BSD 9y ago

If I were the Linux camp, I would seriously look at the work required to port this to the kernel. Since they can't mainline zfs this may be their next best option. Not that they will look outside their echo chamber but they should.

jlgaddis 9y ago
The first release -- which will have very few of the planned features -- hasn't even happened yet. If I were "the Linux camp", I wouldn't even bother looking into H2 for at least another five years or so.

takeda 9y ago

I'm glad Hammer FS exist, it is always great to have options, and new filesystems have more to build on. But this one seems weird to me: > copy-on-write, implying snapshots and such, like ZFS, but snapshots are writable. snapshot by definition should be read-only, also ZFS allows to create a new filesystem from snapshot (through zfs clone) which is also O(1) operation.

antongribok 9y ago
Read-only and read-write snapshots are possible with LVM, ZFS, Btrfs, and many commercial storage solutions. One reason why you would want a writable snapshot is during backup validation. An application may need to do crash recovery before being able to read data, and having a writable filesystem makes things a lot easier. I know that ZFS and LVM both send writes to a separate area, so the original snapshot is never modified (don't know about Btrfs implementation details).
- takeda 9y ago
  Yes, what I said in ZFS you can instantly (and without using extra space) create a writable filesystem from snapshot using zfs clone (you can create multiple filesystems from one snapshot), but snapshots by itself are always read only.
Someone 9y ago
That looks a bit like git versus svn. So, it _might_ be an insane idea that ends up being a good idea. Especially if the default is to have a read only snapshot, I do not rule that out.

Dylan16807 9y ago

How does the deduplication work, in terms of user interface and performance? For comparison: ZFS has an online-only dedup, so it can save space as data is written, but it can't combine identical pieces of already-written data. It also scatters the segments of files to the winds, needing lots of ram and fast disks or it slows to a crawl. BTRFS has mostly-offline dedup, so it doesn't save space as data is written, but you can combine identical pieces of data later. You can also make CoW copies of files instantly. It has minimal performance impact.

antongribok 9y ago
I believe the correct terms are inline vs. post-processing deduplication. There are pros and cons to each approach, and as usual with storage, a lot depends on implementation and workload.
- Dylan16807 9y ago
  > I believe the correct terms are inline vs. post-processing deduplication. Thanks. > There are pros and cons to each approach, and as usual with storage, a lot depends on implementation and workload. I would probably argue that the biggest factors in different performance between ZFS and BTRFS deduplication are nearly independent of when the deduplication happens, and boil down to implementation decisions specific to those two filesystems.
- snovv_crash 9y ago
  The term online and offline are also correct, although they tend to be used in the machine learning field more.
  - antongribok 9y ago
    Offline is a completely different term when speaking about filesystems. Offline means that the filesystem needs to be unmounted before an operation can proceed. For example some filesystems can be grown online, but can shrink only offline.

needusername 9y ago

> 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 I always though it care about performance of SQL databases you bypass the filesystem / kernel and go directly to the LUN with something like ASM.