Live data from Hacker News

DwarFS: A fast high compression read-only file system

github.com

31–40 of 112 posts

Re: DwarFS: A fast high compression read-only file system

#31
post #15

Why not use BTRFS with file deduplication and transparent compression (zstd specifically)?

This is a read-only file system, so it’s able to exploit certain properties of that—- locating similar files next to each other, for example.

I don’t see how read only helps at all.

Btrfs can dedupe at the block level.

Re: DwarFS: A fast high compression read-only file system

#34
post #10

> I started working on DwarFS in 2013 and my main use case and major motivation was that I had several hundred different versions of Perl that were taking up something around 30 gigabytes of disk space, and I was unwilling to spend more than 10% of my hard drive keeping them around for when I happened to need them. It fills me with joy that someone has been coding a fs for 7 years due to perl installs taking too much…

Hahaha, I haven't actually been coding on this for that long, it's more that I coded for a few weeks back in 2013 and only found the motivation to resurrect the whole thing a few weeks back.

> "taking up something around 30 gigabytes of disk space, and I was unwilling to spend more than 10% of my hard drive"

I imagine these days you have more than 300GB hard disk space, making this all moot?

Re: DwarFS: A fast high compression read-only file system

#35
post #18

Earlier quoted context omitted.

Funny thing about it is that I've got a similar problem powering https://perl.bot/ (and the associated irc bot). I don't have as many installs as you currently but It's not far off and I want to add more compile time settings to them. I'd need to setup a full build server/system though because I need to regularly update them with new modules. How opposed would you be to this being reworked to being able to be mainlin…

> How opposed would you be to this being reworked to being able to be mainline kernel support too? I don't see any way of getting this anywhere near the kernel without a full rewrite. It's C++ and it depends on libraries that aren't even shipped by a lot of distributions (folly & fbthrift). And, tbh, I don't see much benefit given that FUSE these days doesn't seem to be significantly worse in terms of performance. >…

Is it possible to rebuild a DwarFS fs to incorporate changes from an overlay fs without decompressing, then recompressing?

It seems feasible that a second DwarFS fs could be built from an overlay/DwarFS, then delete the original overlay/DwarFS fs. That would require 2N storage as the new DwarFS is being built. Is it possible to patch an existing DwarFS?

By overlay, are you referring to overlayfs [0]?

https://wiki.archlinux.org/index.php/Overlay_filesystem

Re: DwarFS: A fast high compression read-only file system

#37
post #15

Why not use BTRFS with file deduplication and transparent compression (zstd specifically)?

Is Btrfs stable yet?

For most use-cases, yes. But not if you plan on using raid5+ [0]

[0]: https://btrfs.wiki.kernel.org/index.php/Gotchas#Parity_RAID

My own experience indicates it's brittle to power failures and will corrupt in annoying ways in the event of a power failure (or hard reboot) as of ~1 year ago.

Re: DwarFS: A fast high compression read-only file system

#40

Earlier quoted context omitted.

Is Btrfs stable yet?

For most use-cases, yes. But not if you plan on using raid5+ [0] [0]: https://btrfs.wiki.kernel.org/index.php/Gotchas#Parity_RAID My own experience indicates it's brittle to power failures and will corrupt in annoying ways in the event of a power failure (or hard reboot) as of ~1 year ago.

Year isnt as useful as kernel version.
Post reply on HN