Happy user of btrfs-raid1 for more than ten years here, for what it’s worth.
Seconded, though I think my array is perhaps only... 8ish years old?
Examining Btrfs
61–70 of 112 posts
Re: Examining Btrfs
#62One thing I always found curious is that Synology supports Btrfs. Granted, they are not exactly what I'd call a company with a rock-solid track record, but they are still a rather large premium manufacturer in the NAS space. It seems they have either managed to contain Btrfs' complexity and prevent users from doing the dangerous things, or their own hybrid raid was even worse, or they are just very risk friendly.
Synology's implementation of BTRFS is rocksolid, in my experience. This guy [1] tried to break it and couldn't.
Re: Examining Btrfs
#63Earlier quoted context omitted.
> ZFS is not tied to the memory allocator in Solaris, I’m very unclear how you could have made that mistake > And yes, the 1G per TB is for the in memory block map, which is a requirement for deduplucation on the default block size. You actually answered your own question: it's antiquated because of the assumption it is possible to get contiguous RAM for that mapping. On modern Linux, that is only possible if you res…
> it's antiquated because of the assumption it is possible to get contiguous RAM for that mapping. source on that? (and even if that's the case, wouldn't that be an implementation detail? E.g. implementations can spill it to L2ARC, but somehow not to different memory locations?)
My memory is that this mapping does have to be contiguous, but I'll dig it up in the code and link it here either way.
Re: Examining Btrfs
#64Earlier quoted context omitted.
What about ZFS?
ZFS is a more mature and (maybe?) more performant solution to... the same wrong problem. The modern world doesn't want this stuff from its filesystems. It just doesn't. Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at th…
Isn't Lustre designed specifically for ZFS as its backing filesystem?
Re: Examining Btrfs
#65Earlier quoted context omitted.
> But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed. Except… there's nothing to really learn. All these weird edge cases that can kill your BTRFS simply don't exist in ZFS. The tooling is also much more polished and in the few cases that something does require user attention, it'll tell you in easily understandable terms, so as a new user the only co…
> Except… there's nothing to really learn. Would you mind explaining to us how to add a disk to an array with ZFS? Then same question but with a disk which is not the same size that the rest of the array.
You don't. There is NO real world use case to do that. It seems like they exist, but every time you dig into the details you discover that there is a horrible edge case that makes it a stupid idea.
What you do is buy not one drive, but a set of drives and add an second array to the system. Then RAID-0 between the two arrays.
Re: Examining Btrfs
#66Earlier quoted context omitted.
What about ZFS?
ZFS is a more mature and (maybe?) more performant solution to... the same wrong problem. The modern world doesn't want this stuff from its filesystems. It just doesn't. Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at th…
I just do software dev, but cp with reflink is absolutely killer, and the only reason I don't just go with ext4. Unless I'm crazy, ext4 doesn't seem to have any simple copy-on-write feature I can use to copy/paste an entire project directory instantly. I sometimes do that so I can have two instances of the same app running at the same time, on different branches. I've also used reflink in automated tests, testing a tool that relies on and changes a project's file structure. I can just duplicate an entire dummy project, operate on it, then throw it out and it's fast since it doesn't need to copy bit-by-bit.
Re: Examining Btrfs
#67Earlier quoted context omitted.
I disagree. I think that the traditional split between block devices and file systems is a premature optimization that ZFS fixes. And in practice ZFS is extraordinarily solid.
> And in practice ZFS is extraordinarily solid. As long as you never ever run into an edge case it's great, but then again the same goes for btrfs :)
Did you have anything specific in mind? Because otherwise that statement could apply to anything.
Re: Examining Btrfs
#68Earlier quoted context omitted.
Please correct me if I'm wrong, but the "1GB ram per TB" is for the de-duplication table. ZFS' memory cache (ARC) by default uses up to 50% of system ram and frees this under pressure. You can also set it lower.
Yes, this is what I'm talking about. With respect to ARC, it gets along very poorly with the native page cache and memory allocator. I would add that BTRFS has no such requirements for deduplication.
That’s because the btrfs deduplicator is quite a different animal. You could just as easily run fdupes or something similar. Meanwhile ZFS is doing something much more ambitious.
In any case, I don’t think that either of them are worth using in most cases. Deduplication is just too expensive to be worth it.
Re: Examining Btrfs
#69Earlier quoted context omitted.
> But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed. Except… there's nothing to really learn. All these weird edge cases that can kill your BTRFS simply don't exist in ZFS. The tooling is also much more polished and in the few cases that something does require user attention, it'll tell you in easily understandable terms, so as a new user the only co…
> Except… there's nothing to really learn. Would you mind explaining to us how to add a disk to an array with ZFS? Then same question but with a disk which is not the same size that the rest of the array.
zpool add tank mirror /dev/sdc1 /dev/sdd1
From the perspective of an individual user it's definitely a suboptimal part of ZFS. But standing in the shadow of business usage is the price to pay for it having been developed in the first place.
As an individual user you can play games with sparse files and failed members as a sibling comment says (and dragging some external drives into service can help, as well as restoring from your backups). But really, just try to plan for the space you want and buy at once. Disks are large enough these days that you should aim to not be tinkering with your storage.
Back in the day I had something like an 8 x 250GB disk external USB drive array for my FLAC collection, with each disk partitioned into 10 slices, raid6'd, and then LVM'd back together. This gave me the wiggle room to take down a single slice at a time for reshaping, and then I could even online grow the filesystem thanks to reiserfs. No backups of course. I did the online expanding thing once or twice and it was neat, but ultimately the whole thing was replaced by a simple 2TB mirror after several years.
There's no reason you couldn't do something similar with ZFS besides performance. But do you really want to?
Re: Examining Btrfs
#70I would definitely look again at btrfs once it gains raid5/6 capability.
Currently happily using ZFS. The only issue is not being able to use latest kernel releases as the ZFS folks usually don't release updates for a while, but overall it doesn't really bother me much nowadays.