BTRFS

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

mstone

Active Member
Mar 11, 2015
505
118
43
46
2/3 of my btrfs attempts have ended up eating their data. It still has issues under heavy load in a low free space situation. I'll stick with xfs for the foreseeable future.
 

canta

Well-Known Member
Nov 26, 2014
1,012
216
63
43
2/3 of my btrfs attempts have ended up eating their data. It still has issues under heavy load in a low free space situation. I'll stick with xfs for the foreseeable future.
what btrf version ?
 

mstone

Active Member
Mar 11, 2015
505
118
43
46
what btrf version ?
Who knows, probably been a year since the last time I tried. At some point it doesn't matter--there's no compelling reason for me to try again for a filesystem that's still unstable (that is, still changing rapidly). Maybe some years after it's settled down I'll look again.
 

canta

Well-Known Member
Nov 26, 2014
1,012
216
63
43
Who knows, probably been a year since the last time I tried. At some point it doesn't matter--there's no compelling reason for me to try again for a filesystem that's still unstable (that is, still changing rapidly). Maybe some years after it's settled down I'll look again.
it is stable for 0 and 1 ....

I am using 0 and 1 on centos 7.X

I am waiting 5 and 6 actually.. planning to move from zol to btrfs that no worry about dkms or broken (easy to fix, just need time) zfs when upgrading to newer kernel version.

my current:
btrfs 0/1 and zol(zfs) raidz1/2/3
 

vl1969

Active Member
Feb 5, 2014
634
76
28
it is stable for 0 and 1 ....

I am using 0 and 1 on centos 7.X

I am waiting 5 and 6 actually.. planning to move from zol to btrfs that no worry about dkms or broken (easy to fix, just need time) zfs when upgrading to newer kernel version.

my current:
btrfs 0/1 and zol(zfs) raidz1/2/3
like I said before, I like using BTRFS and have been using it for the last 2+ years.
so far I had only one incident leading to loss of data using btrfs raid1 pools.
and I do believe I found a bug when it comes to btrfs and raw devices.
so now I simply prepare my disks beforehand with gdisk or something
create a partition table and a single partition on the disk and use the partition in the pool.
an extra step but nothing we did not have to do before.
 

mstone

Active Member
Mar 11, 2015
505
118
43
46
A lot has changed in recent kernel releases..
Yes, that's why I'm confused that people are talking about it being stable. :-D Look, the btrfs devs haven't exactly developed a reputation for being careful not to lose data. Given my experience (none of which was on systems that actually mattered for anything, fwiw) I'm not going to suddenly assume that's changed based on anecdotal reports. Given that a lot of guidance from the btrfs devs consists of features which are and are not working well (meaning that it's up to the user to make sure they don't actually try to use a function which will eat their data) it's basically more trouble than it's worth: what I really want from a filesystem is the ability to put bits in and then get the same bits back out, while I'm really thinking about other things which should be more important/interesting than the filesystem.

For context, we've done this all before--I heard people talk for years about how reiserfs was going to change the world, for example, then how the new reiserfs was going to change the world because it was even better. And I'm still not using reiserfs. There was a hype cycle for jfs, and various overlay filesystems, and distributed filesystems like coda, and most of them never go anywhere. If you've got some sort of really unique requirements which mean that you can't get your work done without a boutique filesystem, then go for it; but if you don't have a really unique requirement (or a love for filesystem development in an academic sense), you'd have to be nuts to jump on the btrfs boat at this point.

Note that if you have unique requirements, you're that much more likely to be using the not-very-well-tested parts of the filesystem...
 

TuxDude

Well-Known Member
Sep 17, 2011
616
338
63
Yes, that's why I'm confused that people are talking about it being stable. :-D
Because most of those changes are directly related to making it more stable. A lot has changed in Windows 10 as well and yet it also appears to be stable.

BTRFS is now production ready for basic use-cases eg. a regular desktop/laptop with a single drive. Lots of people using it on a daily basis is pretty much required at this point to find the remaining bugs and get them fixed. RAID-0/1/10 across multiple drives is also quite mature and is safe to use although there are still additional features on the roadmap (eg. N-way mirroring if you want more than 2 copies) Parity-raid is not yet ready for production use (and is also not something that an average user even knows what means), but is code-complete now for the minimal features and is ready for public testing.

Ya there are a lot of niche filesystems out there that can be fun to play with if you're a storage geek, or that fill a need in some rare use-case. BTRFS happens to have a planned feature-set though that imho will make it the best filesystem available for the majority of at-home uses as well as many enterprise uses. All of the data protection abilities of ZFS combined with the flexibility to use a bunch of drives of varying capacity and also add/remove drives from the volume on the fly would be the ultimate home NAS, just needing a nice UI to make it simple to use (eg. Rockstor). We just need to wait a little bit longer for a few final features to materialize/mature - raid5/6 with the current variable-stripe-width chunk allocation should be mature enough for most of us after a few more kernel releases, likely around 4.4
 

mstone

Active Member
Mar 11, 2015
505
118
43
46
Because most of those changes are directly related to making it more stable. A lot has changed in Windows 10 as well and yet it also appears to be stable.
Windows 10 didn't change the filesystem. People are very conservative about their stored data, for good reason. MS had NTFS in production for almost a decade before it was the default for everything, and ReFS is on a similar trajectory.

BTRFS is now production ready for basic use-cases eg. a regular desktop/laptop with a single drive. Lots of people using it on a daily basis is pretty much required at this point to find the remaining bugs and get them fixed. RAID-0/1/10 across multiple drives is also quite mature and is safe to use although there are still additional features on the roadmap (eg. N-way mirroring if you want more than 2 copies) Parity-raid is not yet ready for production use (and is also not something that an average user even knows what means), but is code-complete now for the minimal features and is ready for public testing.
For a regular desktop with a single drive, why use a boutique filesystem at all? You won't know the difference in the best case, and it will eat your data in the worst case. If you have a sacrificial machine that you're willing to dedicate to the cause, great--but my desktop is running on an image which has been continuously upgraded and migrated for well over a decade and I don't want to start losing data now. :) You're right that it's essential that people actually use a filesystem before the bugs are shaken out, but it's critical that they go in with their eyes open. Suggesting that a filesystem in that shakeout period is a safe replacement for something with a long track record for stability does a disservice both to users and to fs developers. I also question your assertion that parity raid is a rare beast in the context of a system wherein a boutique filesystem is interesting.

Ya there are a lot of niche filesystems out there that can be fun to play with if you're a storage geek, or that fill a need in some rare use-case. BTRFS happens to have a planned feature-set though that imho will make it the best filesystem available for the majority of at-home uses as well as many enterprise uses. All of the data protection abilities of ZFS combined with the flexibility to use a bunch of drives of varying capacity and also add/remove drives from the volume on the fly would be the ultimate home NAS, just needing a nice UI to make it simple to use (eg. Rockstor). We just need to wait a little bit longer for a few final features to materialize/mature - raid5/6 with the current variable-stripe-width chunk allocation should be mature enough for most of us after a few more kernel releases, likely around 4.4
Which is it that makes this attractive? The minimal stable set of features that (at best) make btrfs pretty much like any other filesystem, or the planned exotic set of features that isn't stable yet? How do I know which ones are safe on any given day?
 

TuxDude

Well-Known Member
Sep 17, 2011
616
338
63
Windows 10 didn't change the filesystem. People are very conservative about their stored data, for good reason. MS had NTFS in production for almost a decade before it was the default for everything, and ReFS is on a similar trajectory.
MS has been adding features to NTFS with almost every OS release, which is common thing for filesystems to do. MS just doesn't advertise it as much. But don't go believing that every line of code in NTFS has 20 years of testing behind it.

For a regular desktop with a single drive, why use a boutique filesystem at all? You won't know the difference in the best case, and it will eat your data in the worst case.
Why does it have to be labeled boutique? Is everything except NTFS/FAT boutique? Are ext2/3/4/xfs/zfs boutique? Ext2/3/4 have been the default filesystems of many linux distro's over the years, xfs is now the default for RHEL7 (and clones), ZFS is the default for solaris and some BSDs. Btrfs is the default filesystem for suse and is lined up to replace ext4 as the default in many other distro's as it gets more mature. As to why to use it - because even on a single drive it provides benefits. The checksumming may not be able to repair your data if you only have a single drive but you will at least be certain that your data is safe or not, and duplicated metadata should allow the filesystem to at least mount in the case of corruption and recover at least some of the data. Snapshots are also a very handy feature (that is plenty mature), in some cases also integrating into the system package manager for automated snaps at every package upgrade. I'm now using btrfs for all desktop installs I do, whether it is a new system or just an OS upgrade to an older one.


Suggesting that a filesystem in that shakeout period is a safe replacement for something with a long track record for stability does a disservice both to users and to fs developers. I also question your assertion that parity raid is a rare beast in the context of a system wherein a boutique filesystem is interesting.
What I've been "suggesting" is that btrfs is no longer in that shakeout period, only certain features are. I was also only asserting that parity raid is rare in the context of the average desktop user, where virtually all boutique filesystems would also be rare. I don't however consider btrfs to be "boutique", and I do believe that there are many non-technical users out there running linux desktops (mostly ubuntu) that could benefit from some of the already stable features in btrfs.

Which is it that makes this attractive? The minimal stable set of features that (at best) make btrfs pretty much like any other filesystem, or the planned exotic set of features that isn't stable yet? How do I know which ones are safe on any given day?
I will admit that knowing when new features become safe to use is a problem - its not a problem specific to btrfs but affects many open-source projects. It is easier in the closed-source world of expensive software and expensive support contracts - the code may not be any more mature but at least you have a large corporate entity giving you a written guarantee that stuff will work as it should, and a phone number to call when it doesn't. If you want that for btrfs feel free to give oracle a call as they certify/support it for production use.

As for what makes it really attractive are the data protection and flexibility in growth/shrinking. And yes those are both mature and stable parts of the filesystem. You could take a system right now with 10 drives of mixed capacity and make a single btrfs volume spanning all of it with raid-1 data and metadata protection and make full use of the capacity of all of the drives. It won't be very capacity-efficient until parity raid is more mature, but it is safer than parity raid, and will migrate online to parity raid as soon as the user decides that code is mature enough. It's the level of data protection that ZFS/ReFS provides, and the flexibility to add/remove drives that the original Windows Home Server had - both very popular things now combined.
 
  • Like
Reactions: Kristian

cptbjorn

Member
Aug 16, 2013
100
19
18
btrfs is still in RHEL tech preview, if and when they take it out I'll start using it for real.

I'm using it at home with mdadm and bcache in writeback mode and I'm liking it, but I have backups and I'm not afraid to use them.
 

canta

Well-Known Member
Nov 26, 2014
1,012
216
63
43
like I said before, I like using BTRFS and have been using it for the last 2+ years.
so far I had only one incident leading to loss of data using btrfs raid1 pools.
and I do believe I found a bug when it comes to btrfs and raw devices.
so now I simply prepare my disks beforehand with gdisk or something
create a partition table and a single partition on the disk and use the partition in the pool.
an extra step but nothing we did not have to do before.
I am getting used to create a partition on the drive. this is my habit since 4 years ago :D...
all my btrfs are running on non raw disk.

I remember that you can use raw disk on mdadm :D, I think I did before move to btrfs 0/1
 

vl1969

Active Member
Feb 5, 2014
634
76
28
I am getting used to create a partition on the drive. this is my habit since 4 years ago :D...
all my btrfs are running on non raw disk.

I remember that you can use raw disk on mdadm :D, I think I did before move to btrfs 0/1
mine too now...
 

TuxDude

Well-Known Member
Sep 17, 2011
616
338
63
Many years back I switched to using raw devices for everything except the boot drive, mostly due to problems getting the kernel to recognize resized partitions without needing a reboot. With a Pile'o'VMs at work the standard is a 20GB boot drive partitioned into /boot, swap, and / (root) which should last the life of the system without issues (most are thin-provisioned VMDKs that are still under 10GB total size after years of updates). After that all other drives are used raw as LVM physical volumes - when a server needs to grow it is very simple to expand the disk from the vSphere client, then inside the VM just pvresize, lvresize, and resize2fs or xfs_growfs depending on filesystem - that same procedure has been working great since RHEL4, never downtime when a server needs another 10/100/1000GB of capacity.

Of course with real physical disks you don't have to deal with them magically changing size behind the scenes, the only real downsize to having a single partition per drive is the ~1MB of wasted space at the very start of the disk.
 
  • Like
Reactions: Cheddoleum

mstone

Active Member
Mar 11, 2015
505
118
43
46
MS has been adding features to NTFS with almost every OS release, which is common thing for filesystems to do. MS just doesn't advertise it as much. But don't go believing that every line of code in NTFS has 20 years of testing behind it.
I didn't say that every line of code hasn't changed in 20 years. I did suggest that they're not making radical consumer-facing changes. ext4, xfs, zfs all change things also but (unlike btrfs) start with a stable foundation, introduce relatively small and comprehensible changes, and don't generally use the changed code by default until its been used in the wild for a while.

Why does it have to be labeled boutique? Is everything except NTFS/FAT boutique? Are ext2/3/4/xfs/zfs boutique?
ext2 et al, as well as xfs have been used for years, have a large userbase, are fairly stable, and have a straightforward and well understood set of features and interfaces. So no, not boutique.

Btrfs is the default filesystem for suse and is lined up to replace ext4 as the default in many other distro's as it gets more mature.
Suse used to default to reiserfs; I won't pretend to understand why they make the decisions they do. It's telling that they tend to stand alone. It's also telling that you seem to keep saying but ignoring the implications of what I consider to be the key part: "they will use this when it gets more mature".

Really, if you want to use the thing, good for you. But to go on as though anyone not using it is making a mistake descends into fanboism. You can't "win" an argument for the stability of a piece of software by insisting that it works for you and that all of the problems that it had before (that are in the undefined list of safe features) have been fixed.