Live data from Hacker News

DwarFS: A fast high compression read-only file system

github.com

21–30 of 112 posts

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

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

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

#24
post #16

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

Nowadays you can have the same problem with Python and Javascript too!

Same with Ruby (Gems).

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

#27
post #6

What are the use cases for a read only file system?

Game asset packages - all game assets are read only and need to be compressed and nowadays with SSD's you don't want duplication.

Just to clarify that last statement (and something to think about) with HDD's you want duplicate assets so that you don't cause seeks which are VERY slow on 5400rpm HDD's still found on some/alot of systems.

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

#28
post #26

I'm curious, why do you have so many perl installations around. I thought I'd got a fair number of python venvs kicking around for each of the repos I'm dealing with, but nowhere near that many.

My Python shits have pip requirements that easily dump 3-4 gigs in a venv folder. Do that once or twice a month when starting a new project for a couple of years and it gets messy...

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

#30
post #19

I wish there was a semi-compressed transparent filesystem layer which slowly compresses the least recently used files in the background, and un-compresses files upon use. That way you could store much more mostly unused content than space on the disk, without sacrificing accessibility.

I believe NT file compression works like this, and before that MSDOS "DriveSpace" ...

NTFS requires that files be manually converted to the compressed format. They're uncompressed in parts as requested, but this is only kept in RAM. I'm not aware of any built-in background task that converts files to/from the compressed format.
Post reply on HN