I guess it's unfortunate for btrfs that it has so much "raid" functionality. Otherwise it could be known for its useful other functionality - snapshots, subvolumes, checksums, compression!
Examining Btrfs
91–100 of 112 posts
Re: Examining Btrfs
#92Earlier 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…
Sure, I give you that ZFS' tooling is much, much more polished. But of course there are peculiarities that have 'bitten' people (softly) in the past: - dedup has hardly any use case, novices get enticed to try something that doesn't do what they think it does - ZIL and SLOG sound like "a simple cache" when in reality they are much more complex - You can add single devices to a (redundant) pool, at which point you've…
- No copy-on-write file copies.
- Very limited ability to make snapshots writable.
Re: Examining Btrfs
#93Earlier quoted context omitted.
> 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.
There is NO real world use case to buy fewer than six to eight drives at a time? (assuming I'm using raidz2 or so)
Really?
Re: Examining Btrfs
#94Earlier quoted context omitted.
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.
> You could just as easily run fdupes or something similar.
If you only deduplicate whole files and soft links or hard links are suitable for your situation.
Re: Examining Btrfs
#95Earlier quoted context omitted.
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.
There is NO real world use case to buy fewer than six to eight drives at a time? (assuming I'm using raidz2 or so) Really?
The smallest number you can safely go is 3 at a time - put them in a mirror configuration. This is expensive for the amount of storage you get, so few people are willing to spend that much. Once you want to be cost effective 6-8 is the sweet spot - enough drives for a good amount of usable space, but not so many that multiple drive failures are likely to compromise the array. Nobody is stopping you from other configurations, but 6-8 drives in your array is about the best compromise between performance, cost effective and total storage.
Re: Examining Btrfs
#96Can someone recommend a good overview of modern filesystems that covers performance and licensing issues? I liked this article but was left with the question "so what else do you use?" It's been awhile (too long really) since I really tried to read up on this area. Last time I did I concluded that it was sort of a mess but lots of things were still in progress.
Use ZFS if you can. However for legal reasons it is hard to use on linux, which pushes you to FreeBSD (I'm not sure about the others). FreeBSD can replace linux, but you will find a number of places where the software you use assumes linux and so things don't work right. If you are doing NAS all on your own, then don't hesitate to run to FreeBSD. However if you want to a not do it yourself NAS it is a little harder.…
Too late to edit, but I just discovered the synology isn't use BRTF for redundancy, they are somehow using linux device manager in a way that I don't understand. Since I don't understand what they are doing I don't know how it compares to ZFS.
Re: Examining Btrfs
#97Earlier quoted context omitted.
There is NO real world use case to buy fewer than six to eight drives at a time? (assuming I'm using raidz2 or so) Really?
The smallest number you can safely go is 3 at a time - put them in a mirror configuration. This is expensive for the amount of storage you get, so few people are willing to spend that much. Once you want to be cost effective 6-8 is the sweet spot - enough drives for a good amount of usable space, but not so many that multiple drive failures are likely to compromise the array. Nobody is stopping you from other configu…
I want to work up to 8 drives in a vdev as my storage needs grow, because that's cost-effective. But I don't want to spend 8 drives of money up front, because it's a lot and because drive prices drop over time. Am I not a real use case?
Re: Examining Btrfs
#98Earlier quoted context omitted.
In BTRFS, RAID1 simply means 2 copies on different devices. There is RAID1C3 and RAID1C4 if you want more redundancy/copies. This whole critique boils down to poorly chosen naming and bad documentation. Both VERY valid critique. But feature-wise, BTRFS delivers „classic“ RAID1 and more/better. It’s just hard to find and easy to misread.
The critique is more about the fact that it'll stripe across any two devices in the pool. So in an 8+4+2+2 setup, you could run into serious trouble after only losing the two 2Tb drives (which are likely the oldest and flakiest two in a bodged-together-from-leftovers style array). I do agree that this is still strictly better than not being able to do it at all so long as you understand the risks, but being able to d…
The btrfs allocation policy is to put data on the device with the most free space, after respecting requirements for redundancy. So if your drives are sized 8+4+2+2 and you're using the RAID1 profile, it will in fact operate as 8+(4+2+2), using only the 8 and 4TB devices until the 4TB device is half full, at which point it starts using the 2TB devices.
You can still end up in the situation where there's data that is duplicated across the two 2TB devices, if those are the two you started with and you added the larger devices later. But that can be fixed by doing a rebalance operation at any time after adding more devices. That's usually a good idea, though sometimes you might want to avoid a full rebalance so as not to put too much IO load on a single disproportionately large device.
(If you want a hard guarantee that no data will ever be mirrored across the two 2TB drives, use dm/md to concatenate them into a 4TB block device, and add that to the btrfs array.)
I have a btrfs array currently consisting of a mix of 1TB, 2TB and 4TB devices; 10 drives with a nominal total capacity of 26TB. This is using the RAID1 profile for data, and has been using the RAID1c3 profile for metadata since that feature became available. The number of drives in this array has fluctuated up and down over the years and it has survived drive failures and the accidental removal of the wrong drive from the hot-swap bay, and hasn't lost data in that time. But the current allocation is a bit uneven, because I don't always rebalance after adding or removing devices.
Re: Examining Btrfs
#99Earlier quoted context omitted.
There’s no need for changing mount options. If you want to allow mounting of degraded arrays, just put the degraded option there from the start.
That sounds to me like it was originally set up that way early in development because they wanted people to give immediate manual attention to a system before booting it in that state. If btrfs is mature enough that it's "safe" to boot missing a disk now I think either the defaults or the documentation probably want changing to make that clearer. Like, I get "oh just add this option" as a response but in this case th…
Whether to include the degraded option by default is a policy choice that's far beyond the purview of filesystem developers, and not something that most distros can give a clear answer to, either. It boils down to a question of the end user's use cases and risk tolerance. But it seems pretty reasonable to state that a loss of redundancy should either be handled by the user, or by a piece of software sitting between the user and the filesystem itself and acting in accordance with the user's preferences. Silently continuing to operate but with less safety than the user originally requested is the kind of dangerous that should be an opt-in feature, not a default.
Moving the decision into the filesystem itself only makes sense if the filesystem is equipped to enact mitigating actions such as claiming a hot spare as the replacement device, notifying the user/sysadmin through whatever logging/reporting mechanism is actually monitored by a human, signalling applications like load balancers to stop relying on this particular machine if a healthy alternative is available, etc.
(There's also an implementation detail that can trip up users who are trying to live dangerously: you're not supposed to mount a degraded btrfs array as writable until you're prepared to fix the problem making it degraded—such as by providing the devices needed to restore redundancy, or converting it to not be a redundant array anymore.)
Re: Examining Btrfs
#100Earlier quoted context omitted.
There is NO real world use case to buy fewer than six to eight drives at a time? (assuming I'm using raidz2 or so) Really?
The smallest number you can safely go is 3 at a time - put them in a mirror configuration. This is expensive for the amount of storage you get, so few people are willing to spend that much. Once you want to be cost effective 6-8 is the sweet spot - enough drives for a good amount of usable space, but not so many that multiple drive failures are likely to compromise the array. Nobody is stopping you from other configu…
> The smallest number you can safely go is 3 at a time - put them in a mirror configuration. This is expensive for the amount of storage you get, so few people are willing to spend that much.
You're talking in circles. You're assuming the limitations of ZFS, then providing advice based on those limitations, then declaring that there's no advisable use case for a filesystem that's free of those limitations.
On btrfs, you can start with two or three drives, then expand your array one drive at a time up to 8+ without lowering your redundancy at any point, and each time you add a drive the usable capacity of the array really does increase.