5 ms·

[Disclosure: I work for SUSE] > an estimate which definitely proved optimistic with regard to Btrfs. SUSE has had Btrfs support for enterprises since SLE11SP2

by cyphar 10y ago

[Disclosure: I work for SUSE] > an estimate which definitely proved optimistic with regard to Btrfs. SUSE has had Btrfs support for enterprises since SLE11SP2[1,2] (2012). And it's been the default for the root partition since SLE12[3] (2014). So it wasn't overly optimistic at all, it was actually a very accurate estimate. The same support apples for openSUSE, but I think they had it for longer. [1] https://www.linux.com/news/snapper-suses-ultimate-btrfs-snapshot-manager https://www.linux.com/news/snapper-suses-ultimate-btrfs-snap... [2] https://www.suse.com/communities/blog/introduction-system-rollbacks-btrfs-and-snapper-sles-11-sp2/ https://www.suse.com/communities/blog/introduction-system-ro... [3] https://www.suse.com/documentation/sles-12/stor_admin/index.html?page=/documentation/sles-12/stor_admin/data/sec_filesystems_major.html https://www.suse.com/documentation/sles-12/stor_admin/index....

viraptor 10y ago
Do you have any good source to point people at when they say btrfs is unstable and corrupts data? (and I mean, either positive or negative data, I don't want to be biased either way) I'm kind of tired of people posting comments like that, which are based on "google is full of people saying this", or "I know one person who lost data" (but no idea which kernel was it - could well be from 2014). If I look at btrfs patches on lkml, on one hand side I can see some fixes for data loss, but on the other they're usually close to "if you change the superblock while log is zeroed and new superblock is already committed and there's a power loss exactly at the point, you'll get corruption" - which are just really obscure edge cases people are unlikely to ever hit. So what can I look at to get a realistic picture of what's going on? (what would SUSE point me at) (for the negative results, I know of the recent filesystem fuzzing presentation where btrfs comes out worst, but honestly I don't consider it interesting for real world usage - car analogy, I'm interested how the car behaves on a typical road, not which fizzy drinks added to the gas tank will break it)
- cmurf 10y ago
  RE: the fs fuzzing, David Sterba a Btrfs developer @ Suse replied to this: https://www.spinics.net/lists/linux-btrfs/msg54454.html https://www.spinics.net/lists/linux-btrfs/msg54454.html As for unstable and corrupts data, this is just not true. Many more users using it on stable hardware don't have problems. I've used Btrfs single, raid0, raid10 and raid1 for years, and haven't had corruptions at all ever that I didn't myself induce. I have stumbled upon, just days ago, parity corruptions in raid5 however. The raid56 stuff is much much newer and hasn't been as well tested, and has been regarded as definitely not ready for prime time. So that's a bug, and it'll get fixed. Bunches of problems happen on mdadm and LVM raid also due to drive SCT ERC being unset or unsupported, resulting in bad sector recovery times that are longer than the kernel will tolerate. That results in SATA link resets, rather than the fs being informed what sector is bad so it can recover from a copy and fix up the bad sector. So there are bugs all over the place, it's just the way it goes and things are getting quite a bit better. It is totally true that Apple can produce their own hardware that doesn't do things like lie to the fs about FUA or its equivalent of req_flush being complete when it's not, or otherwise violating the order of writes the fs is expecting in order to be crash tolerant. But we're kinda seeing Apple go back to the old Mac days where you bought only Apple memory and drives, 3rd party stuff just didn't happen then. The memory is now soldered on the board and it looks like the next generation of NVMe and storage technologies may be the same. Windows and Linux will by necessity have file systems that are more general purpose than Apple's.
- the_why_of_y 10y ago
  The thing about btrfs is, it's got lots and lots of optional features, of widely varying maturity. Hence it's not very surprising that the supported btrfs in SuSE is a sub-set of all the available features: the ones that are most mature. This is an illustrative patch from a couple years ago, not sure if still current: http://kernel.opensuse.org/cgit/kernel-source/plain/patches.suse/btrfs-8888-add-allow_unsupported-module-parameter.patch?h=SLE12 http://kernel.opensuse.org/cgit/kernel-source/plain/patches....

by cyphar 10y ago

viraptor 10y ago

Do you have any good source to point people at when they say btrfs is unstable and corrupts data? (and I mean, either positive or negative data, I don't want to be biased either way) I'm kind of tired of people posting comments like that, which are based on "google is full of people saying this", or "I know one person who lost data" (but no idea which kernel was it - could well be from 2014). If I look at btrfs patches on lkml, on one hand side I can see some fixes for data loss, but on the other they're usually close to "if you change the superblock while log is zeroed and new superblock is already committed and there's a power loss exactly at the point, you'll get corruption" - which are just really obscure edge cases people are unlikely to ever hit. So what can I look at to get a realistic picture of what's going on? (what would SUSE point me at) (for the negative results, I know of the recent filesystem fuzzing presentation where btrfs comes out worst, but honestly I don't consider it interesting for real world usage - car analogy, I'm interested how the car behaves on a typical road, not which fizzy drinks added to the gas tank will break it)

cmurf 10y ago
RE: the fs fuzzing, David Sterba a Btrfs developer @ Suse replied to this: https://www.spinics.net/lists/linux-btrfs/msg54454.html https://www.spinics.net/lists/linux-btrfs/msg54454.html As for unstable and corrupts data, this is just not true. Many more users using it on stable hardware don't have problems. I've used Btrfs single, raid0, raid10 and raid1 for years, and haven't had corruptions at all ever that I didn't myself induce. I have stumbled upon, just days ago, parity corruptions in raid5 however. The raid56 stuff is much much newer and hasn't been as well tested, and has been regarded as definitely not ready for prime time. So that's a bug, and it'll get fixed. Bunches of problems happen on mdadm and LVM raid also due to drive SCT ERC being unset or unsupported, resulting in bad sector recovery times that are longer than the kernel will tolerate. That results in SATA link resets, rather than the fs being informed what sector is bad so it can recover from a copy and fix up the bad sector. So there are bugs all over the place, it's just the way it goes and things are getting quite a bit better. It is totally true that Apple can produce their own hardware that doesn't do things like lie to the fs about FUA or its equivalent of req_flush being complete when it's not, or otherwise violating the order of writes the fs is expecting in order to be crash tolerant. But we're kinda seeing Apple go back to the old Mac days where you bought only Apple memory and drives, 3rd party stuff just didn't happen then. The memory is now soldered on the board and it looks like the next generation of NVMe and storage technologies may be the same. Windows and Linux will by necessity have file systems that are more general purpose than Apple's.
the_why_of_y 10y ago
The thing about btrfs is, it's got lots and lots of optional features, of widely varying maturity. Hence it's not very surprising that the supported btrfs in SuSE is a sub-set of all the available features: the ones that are most mature. This is an illustrative patch from a couple years ago, not sure if still current: http://kernel.opensuse.org/cgit/kernel-source/plain/patches.suse/btrfs-8888-add-allow_unsupported-module-parameter.patch?h=SLE12 http://kernel.opensuse.org/cgit/kernel-source/plain/patches....