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?

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.

https://docs.oracle.com/cd/E53394_01/html/E54818/chapterzfs-...

Is that in comparison to other filesystems that provide the same level of data integrity as ZFS? Otherwise you're comparing apples and oranges.

1) data integrity

2) low memory use

3) 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.

There are pros and cons to each approach, and as usual with storage, a lot depends on implementation and workload.

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.

For example some filesystems can be grown online, but can shrink only offline.

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.

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).

Especially if the default is to have a read only snapshot, I do not rule that out.

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.

Does it support RAID and subvolumes like Btrfs? How is the stability?

> 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.

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.