What are the use cases for a read only file system?
DwarFS: A fast high compression read-only file system
41–50 of 112 posts
Re: DwarFS: A fast high compression read-only file system
#42Is this viable as a backup/archive format? Would it make sense to e.g. have an incremental backup as a DwarFS file, referring to the base backup in another DwarFS file?
You could theoretically try to build this with dwarfs, by using overlayfs and then compressing the upper layer again with dwarfs, but that sounds pretty fragile and cumbersome.
Re: DwarFS: A fast high compression read-only file system
#43It looks like the benefit is some kind of block or file deduplication. @OP: Can you please explain why you keep 50 gigs of perl around? :-) I use compressed read-only file systems all the time to save space on my travel laptop. I have one squashfs for firefox, one for the TeX base install, one for LLVM, one for qemu, one for my cross compiler collection. I suspect the gains over squashfs will be far less pronounced t…
Re: DwarFS: A fast high compression read-only file system
#44Earlier 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. >…
It would be nice to be able to build a new read-only filesystem in incremental mode: given a compressed filesystem and some new uncompressed data, incorporate the uncompressed data without completely re-doing all the work.
Re: DwarFS: A fast high compression read-only file system
#45It would amazing to see this work on OpenWRT, I think it would fit perfectly using less resources than squashfs. The other location would be on a Raspberry pi for scenarios where power can be cut at any time.
Author here :) I'm not sure low-spec hardware is necessarily the best use case for DwarFS. It doesn't necessarily use less resources than SquashFS, although it can create file systems that are smaller with much less CPU resources. However, it'll still need a reasonable amount of memory at run time to cache active, decompressed blocks.
Re: DwarFS: A fast high compression read-only file system
#46Re: DwarFS: A fast high compression read-only file system
#47Earlier quoted context omitted.
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.
Re: DwarFS: A fast high compression read-only file system
#48Does the performance benchmark show DwarFS versus single-threaded gzip compressed SquashFS?
Re: DwarFS: A fast high compression read-only file system
#49Re: DwarFS: A fast high compression read-only file system
#50have you investigated why this might be the case?