Well, you're more concerned with files than large blocks of data, so I don't think either matter - other than standard filesystem performance. I've had some experience with ZFS, and practically none with btrfs. ZFS is nice, but resource intensive. I suspect btrfs is similar, but probably not in standard Linux development uses.
How about choosing btrfs so we (the community) can learn more about it?! --Bruce On 2/23/22 11:25, Ben Scott wrote: > Hi all, > > We haven't had a really good flamewar ^W discussion on here in far too long... > > SUMMARY > > Btfrs vs ZFS. I was wondering if others would like to share their > opinions on either or both? Or something else entirely? (Maybe you > just don't feel alive if you're not compiling your kernel from > patches?) Especially cool would be recent comparisons of two or more. > > I'll provide an info dump of my plans below, but I do so mainly as > discussion-fodder. Don't feel obligated to address my scenario in > particular. Of course, commentary on anything in particular that > seems like a good/bad/cool idea is still welcome. > > RECEIVED WISDOM > > This is the stuff every article says. I rarely find anything that goes > deeper. > > - ZFS has been around/stable/whatever longer > - btfrs has been on Linux longer > - btfrs is GPL, ZFS is CDDL or whatever > - Licensing kept ZFS off Linux for a while > - ZFS is available on major Linux distros now > - People say one is faster, but disagree on which one > - Oracle is a bag of dicks > - ZFS is easier to pronounce > > For both, by coupling the filesystem layer and the block layer, we get > a lot of advantages, especially for things like snapshots and > deduplication. The newcomers also get you things like checksums for > every block, fault-tolerance over heterogenous physical devices, more > encryption and compression options. Faster, bigger, longer, lower, > wider, etc., etc. More superlatives than any other filesystem. > > MY SCENARIO > > I'm going to be building a new home server soon. Historically I've > used Linux RAID and LVM and EXT2/3/4/5/102, but all the cool kids are > using smarter filesystems these days. I should really get with the > times. They do seem to confer a lot of advantages, at least on paper. > > USE CASES > > User community is me and my girlfriend and a motley collection of > computing devices from multiple millenia. Administrator community is > me. > > Mostly plain old network file storage. Mixed use within that. I'm a > data hoarder. > > All sorts of stuff I've downloaded over the years, some not even from > the Internet (ZMODEM baby!). So large numbers of large write-once > files. "Large" has changed over the years, from something that fills > a floppy diskette to something that fills a DVD, but they don't change > once written. ISO images, tarballs, music and photo collections > (FLAC, MP3, JPEG). > > Also large numbers of small write-once files. I've got 20 GB of mail > archives in maildir format, one file per message, less than 4K per > file for the old stuff (modern HTML mail is rather bloated). These > generally don't change once written either, but there are lots of > them. Some single directories have over 200 K files. > > Backups of my user systems. Currently accomplished via rsnapshot and > rsync (or ROBOCOPY for 'doze). So small to medium-small files, but > changing and updating and hardlinking and moving a lot. With a > smarter filesystem I can likely dispense with rsnapshot, but I doubt > I'm going to move away from plain-old-files-as-backup-storage any time > soon. (rsync might conceivably be replaced with a smarter network > filesystem someday, but likely not soon.) > > ANTI USE CASES > > Not a lot of mass-market videos -- the boob tube is one area where I > let others do it for me. (Roku, Netflix, Blu-ray, etc.) > > No plans to network mount home directories for my daily-driver PCs. > For laptops especially that's problematic (and sorting apps > (particularly browsers) that can copy with a distributed filesystem > seems unlikely to pay off). > > Not planning on any serious hosting of VMs or containers or complex > application software on this box. I can't rule it out entirely for > (especially as an experiment), but this is mainly intended to be a > NAS-type server. It will run NFS, Samba, SSH, rsync. It might run > some mail daemons (SMTP, IMAP) just to make accessing archives easier, > but it won't be the public-facing MX for anything. > > It's unlikely to run any point-and-drool administration (web) GUIs. I > have a set of config files I've been carrying around with me since I > kept them on floppy diskette, and they've served me well. Those that > like them, more power to you, but they're not for me. I inevitably > bump into their limitations and have to go outside them anyway. > > I've tried a few consumer NAS appliances and have generally been > disappointed. It's the same as the GUI thing above, except I hit the > limits sooner and in more ways. Some of them have really disgusting > software internals. (A shame, because some of the hardware is > appealing, especially in terms of watts and price.) > > I don't want to put this on somebody else's computer. > > HARDWARE > > I'm shooting for a super compact PC chassis, mini-ITX mainboard, 4 x > 3.5-inch hot swap bays, SATA interfaces, x86-64 processor. Initially > it will be two spinning disks. Somewhere in the neighborhood of 3 to > 6 TB effective. The disks will be relatively slow, favoring lower > price-per-GB and less heat over performance. This is bulk data > storage. The user PCs have SSDs. If fancy filesystems weren't a > thing, it would start with two mirrored drives, with plans to expand > to RAID 10 (stripes across mirrors), and multiple LVM logical volumes. > > Off-site off-line backup will be accomplished with one or more > physical disks attached to the system, sync'ed at some level (be it > rsync or filesystem or whatever). Initially it will be a bare disk > and a hot swap bay, with options for eSATA or USB in the future. > > Specific processor and RAM are undecided. I'm not looking to run 40 > VMs, and lower watts would be nice. At the same time, I want it to be > able to handle what I throw at it, and I know the fancy filesystems > can be more demanding, plus I keep meaning to set up plain text > indexing/search. > > -- Ben > _______________________________________________ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
