Have they fixed raid 5 yet? Last time I checked, they said "we don't care" and declared it stable.
You can still use with with plain old MD raid.
51–60 of 71 posts
Have they fixed raid 5 yet? Last time I checked, they said "we don't care" and declared it stable.
You can still use with with plain old MD raid.
I lost data with Btrfs, whereas ext4 has been rock solid for many years. No thanks.
I personally switched to btrfs years ago due to it being (anecdotally) more resilient to power outages and forced reboots. With ext4 it would sometimes result in corruption but btrfs so far has been rock solid. Not a big deal of course but 0 corruption per year is proportionally infinitely better than 1.
Earlier quoted context omitted.
I haven't heard of him objecting to the Sun origins of ZFS, but he has warned people away from ZFS on the grounds of Oracle's litigious reputation: > And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd. > Other…
Could GPL be amended to be compatible with ZFS? Something along the lines of a legal shim. (Clearly Linus already said no to this in extension.)
How often are people reevaluating their file system choice? As excited as Linux users tend to be about the little things, the file system is so close to being unnoticeable day-to-day that it’s not worth the hassle when the current one works perfectly fine.
It's unnoticeable when you don't reevaluate your choices. Once you get into the habit of automatic snapshots, ext4's lack of snapshotting is very noticeable.
I lost data with Btrfs, whereas ext4 has been rock solid for many years. No thanks.
About two years ago I tried it with second hand hdds thinking it would be good for checking the reliability of the drives. After writing some data in one of them and a reboot it failed to mount it again, total data loss while it would have been at most a partial data loss if using ext4 thanks to fsck. This happened 2-3 times as I was testing and didn't care about the data, on ext4 no issues at all. Still using btrfs as the root fs on a new ssd, the snapshots are really useful for backups, no problems in two years. But for reliability I would try zfs instead.
I’ve heard it lacks maturity and of a few cases of data corruption. Those cases are no doubt outdated now, but I haven’t heard any news to sway me that BTRFS is ready for prime time. Ditto for ZFS btw.
zfs is way simpler to manage than btrfs. also, there does not seem to be a proper guide to btrfs. only random of bits and bytes here and there. zfs on the other hand is very well documented.
Not sure I agree. On ZFS I have to worry about an out of tree kernel module and all the implications of that, extra things like setting the correct ashift, making sure the recordsize is tuned individually in datasets to not destroy performance for specific worksets, ensuring ARC doesn't cause OOM behavior with applications which allocate a lot of memory at once (since it doesn't use the page cache), etc etc.
With BTRFS however off the top of my head the only thing I remember doing was making sure nodatacow was set for subvolumes containing databases and VM disks.
You are absolutely correct about the ZFS ecosystem containing superior tooling however.
Earlier quoted context omitted.
It's unnoticeable when you don't reevaluate your choices. Once you get into the habit of automatic snapshots, ext4's lack of snapshotting is very noticeable.
I'm not GP, but I'm curious. What am I missing out on? When would I benefit from having a snapshot on say my laptop?
The snapshot is also a point in time to derive backups from, and usually costs nothing to make, as opposed to making a dd image of the disk, or tarballing everything, etc.
Whether you think you need those is debatable, but it's quick and easy enough, works for me.
There were some threads on HN related to BTRFS which made me look into its suitability as a RAID5 or RAID6 file system, and what I saw made me back-pedal very fast.
Its support for RAID1 or RAID10 (mirroring or stripe-mirror) is okay, but it has glaring issues in all other modes that have gone unresolved for many years. There are some fundamental design issues that might mean that these problems will never get solved, with data loss or data corruption being the inevitable consequence.
Storage is like multi-threading: you've either mathematically proved the correctness of your algorithm, or it is Wrong with a capital W. Storage is not like a web app where an occasional HTTP/500 is no big deal and recoverable. You stuff up something even a tiny bit, and the consequence is shredded or lost data and a very bad day for someone somewhere.
I'm just not seeing the right attitude from the team working on BTRFS. They've been very lax about data integrity issues, recovery from expected failures, etc...
My advice is: stay away.
Sorry, it's the only FS I've lost data with. It seems to have a problem when disks start getting hardware errors and some blocks become unreadable. I mean of course any FS suffers in this situation, but most don't lose the entire volume as easily as btrfs seems to.
I am using both. I've lost data on both, and near misses that required hair-raising metadata rebuild. BTRFS documentation still greatly trail behind ZFS, imo. It's RAID1 implementation is subpar in terms of monitoring.
Can I ask about the circumstances of losing data on ZFS? I've been viewing it as 100% rock-solid, so I'd very much like to know about any failure modes I'm missing.