6 ms·
I've never lost data with btrfs, but I have purposefully avoided anything other than basic disk configurations. I use it on my workstations because it's the def
by DominoTree 4y ago
I've never lost data with btrfs, but I have purposefully avoided anything other than basic disk configurations. I use it on my workstations because it's the default in Fedora these days and haven't had any complaints.
On the flip-side, I've done some of the most horrible things possible and screwed up my 30-disk ZFS array a number of times and I've never lost data. I doubt btrfs could recover from anything I've done to break my ZFS pool.
Overall I think it's a huge shame that it was determined that the CDDL was incompatible with the GPL, because it wasn't intentional, and we would be in a completely different spot for storage otherwise.
- fguerraz 4y agoNever lost any data either in 10y of use as main driver. I've ditched RAID 5 mostly because performance sucked so much, but I have never lost any data despite going through many changes of hard drives, changes of RAID mode, rebalancing, etc. The closest I've come to losing data is probably rotten HDD sectors, but it's always been caught and remapped by scrubs. Yes, there is the infamous write hole, but that's not a BTRFS only problem.
- Gigachad 4y agoI feel like the data loss risk doesn't really make sense to be worried about. It doesn't matter what FS or storage system you use, you _need_ a backup if you actually care about the data. And if you have backups, you are fine. As a random anecdote I've been using BTRFS for everything for over 7 years now and had no issues. Think the only FS I've ever had problems with was ExFAT.
- pavon 4y agoI think it is important for two reasons. First, the primary purpose of RAID is to improve availability of your data, such that you can continue operating in spite of a hardware failure. If the RAID feature of btrfs has serious data loss problems, then it is taking a feature that is supposed to increase availability, and instead decreasing it. It is like an UPS that is more likely to cause a power outage than to protect you from one. The other reason is that the atomic snapshot feature, and ability to easily transfer diffs of snapshots makes a wonderful foundation for incremental backups. But if I can't trust the filesystem to avoid corrupting my data, how can I trust it to avoid corrupting my snapshots? Hence I can't trust my backups. So I need to go back to a more independent backup processes like rsync. With those two features gone, my whole motivation for using btrfs over simpler file systems like ext4 is gone, so why bother.
- Gigachad 4y ago>With those two features gone Still seen no real proof this is true. It's always vague feelings and anecdotes. has anyone done any real testing to measure file corruption?
- Matthias247 4y agodata corruption is slightly orthogonal to data loss. If your filesystem silently corrupts some data in a way you don't notice, you might just replicate the corrupted data to your backup system over time. And in that case you will still have lost it. Data loss - e.g. due to a disk failure - is a lot more obvious.
- chasil 4y agoBtrfs is able to do one important thing that ZFS cannot: defragment. I see XFS as the performance leader (appears on TPC.org the most often that I can see), btrfs as the fullest featured, and ZFS with the strongest reliability.
- tagrun 4y agoThat's incorrect, you can defrag with btrfs filesystem defragment /path There is also the mount option autodefrag
- ttfkam 4y agoReread the comment you replied to. Slowly.
- cosmojg 4y agoXFS is the best filesystem for people who don't want to deal with filesystems. Btrfs is there for the rest of us.
- mananaysiempre 4y agoUnfortunately, as best as I can tell you can’t shrink an XFS volume other than by completely rewriting it. (Also mkfs.xfs formats with Y2038-susceptible 32-bit timestamps by default, but that can be overriden.)
- chasil 4y agoRedHat 8 and clones began creating safe XFS timestamps in their installers. I think they are safe with this version: XFS (sda1): Mounting V5 Filesystem
- chasil 4y agoAs far as that goes, Oracle prohibits the installation of their database on btrfs (note 2290489.1: "Oracle DB has specifically said that they do not support using BTRFS filesystems... BTRFS is optimized for non-database workloads."). XFS for databases is what is used on tpc.org, but perhaps these new improvements may help.
- simcop2387 4y agoOnly time I've lost data with zfs was when i was first doing something supremely stupid, mostly as a dare to see if it would work. I had recently upgraded my pool and had a bunch of old disks lying around so i fired them up in a new pool, 6x 4TB and 6x 8TB disks. I took the 4TB disks and set them in in a raid0 to get effectively 9x 8TB disks. Apparently doing this will work but you MUST make sure you properly wipe all of the newly raided disks of their old ZFS data or you can end up with ZFS trying to check that pool and breaking the mdadm superblocks. After I properly zeroed the 4TB disks it's been working fine for weeks. This let me set it up a pool in raidz3 with them all so i can loose any of the much older 4tb disks or up to 3 of the 8tb ones. I don't use it for anything that's absolutely critical to store, just random bulk data that i don't want to worry that much about, but it's been reliable enough since then.
- zeotroph 4y agoIs there a zfs native way to create raid0 disks now? On Linux I usually set up a linear mapping with dmsetup, and then point zfs to that. But this hides the native disks from zfs. I've done that a couple times to make a bunch of mismatched disk fit into zfs's requirement that all are of the same size. The ability to work with a mix of disk sizes is one advantage of btrfs - if you remember to be extra careful on a disk failure and bad shutdown. Plus the ability to dynamically grow the array, but there is work to improve that in the zfs side as well.