Btrfs RAID 5/6 Support Is "Mostly OK" With Linux 4.12

[gbcox]

RAID 5/6 is not declared stable and the wiki also states that (a few lines below the RAID5/6 still shows "unstable"), so people using it know the risks.
It's a way to say that it should be in far better shape, although something might still be missing. Really, it's a feature in fucking development, what's wrong with giving heads up every once in a while?

People on mailing list were complaining about not getting updates in the wiki, this is an answer to that.

Yeah, it's also been a year and BcacheFS is still not fixed and who knows when it will be deemed "production ready". At this rate, btrfs will be completed before BcacheFS.

If it's declared "not stable" then it isn't "mostly ok". As far as BcacheFS still "not fixed"... it's in development. The author has never stated that it is "mostly ok". BTRFS has been in development for at least 8 years. As far as XFS is concerned, that is the default for Redhat enterprise and CentOS. I don't know of any IT managers that allow BTRFS on their production systems. They don't trust it. If you think it's ok... more power to you.

[caligula]

If it's declared "not stable" then it isn't "mostly ok". As far as BcacheFS still "not fixed"... it's in development. The author has never stated that it is "mostly ok". BTRFS has been in development for at least 8 years. As far as XFS is concerned, that is the default for Redhat enterprise and CentOS. I don't know of any IT managers that allow BTRFS on their production systems. They don't trust it. If you think it's ok... more power to you.

They or someone here has already explained what does and does not work. Go study the wiki, MLs, previous Phoronix articles about btrfs and decide whether things like the write hole problem are large enough obstacles for your adoption. Or, if you have time and money, buy some disks, disconnect or break them to see how the redundancy works atm. It's not really that hard. Breaking one 500GB disk costs you < $30.

[gbcox]

They or someone here has already explained what does and does not work. Go study the wiki, MLs, previous Phoronix articles about btrfs and decide whether things like the write hole problem are large enough obstacles for your adoption. Or, if you have time and money, buy some disks, disconnect or break them to see how the redundancy works atm. It's not really that hard. Breaking one 500GB disk costs you < $30.

I have no desire to waste any more time on BTRFS. Been there, done that. As I said above, I know of no one who uses this on production systems. Most people just don't trust it. If you want to use it, have at it. My point was when dealing with filesystems, "mostly ok" is a bizzare term to use. It either works or it doesn't. That's like getting on a plane whose engines are "mostly ok".

[starshipeleven]

If it's declared "not stable" then it isn't "mostly ok".

The "mostly OK" is the RAID5/6 scrub (userspace tool) and auto-fix from kernel. RAID5/6 itself is still marked as unstable. How much times do I need to repeat that there are 2 goddamn fields here and one is "mostly OK" and the other is still marked as "unstable"?
These are two different features.

I know that you can't read the wiki because it's tainted, but please at least listen to people.

As far as BcacheFS still "not fixed"... it's in development. The author has never stated that it is "mostly ok". BTRFS has been in development for at least 8 years.

And it is in a far more usable state than bcachefs, if I may add. Yeah I know you are butthurt that that guy couldn't get close to 8 years of btrfs development in mere years.

As far as XFS is concerned, that is the default for Redhat enterprise and CentOS.

FYI since you seem to be retarded, I'm going to repeat again, people needing btrfs features are on ZFS.

People that don't care use XFS, ext4 (default on Debian which is in production in many places), FAT or NTFS or whatever, and will keep using that even afterwards.

[starshipeleven]

I have no desire to waste any more time on BTRFS. Been there, done that. As I said above, I know of no one who uses this on production systems. Most people just don't trust it. If you want to use it, have at it. My point was when dealing with filesystems, "mostly ok" is a bizzare term to use. It either works or it doesn't. That's like getting on a plane whose engines are "mostly ok".

What if I told you that this information is useful for people testing it and providing feedback, and people just looking from outside?

"mostly OK" means "not ready for production but we are close".

Really, you're just butthurt that BcacheFS isn't even "mostly OK" in basic features.

[gbcox]

What if I told you that this information is useful for people testing it and providing feedback, and people just looking from outside?

"mostly OK" means "not ready for production but we are close".

Really, you're just butthurt that BcacheFS isn't even "mostly OK" in basic features.

No, I'm not butthurt at all. I do believe that BcacheFS has a better chance living up to the promise that BTRFS failed to deliver, and in a shorter period of time. At this point, it really can't be much worse. What I'm concerned about is that some people may see "Mostly OK" and think that means "OK". I get it that some people like BTRFS and want it to succeed, etc. - and that's fine. However, what has happened in the past is that people get mislead by the hype and think its ready. It's not. The facts are however, it's been in development for over 8 years, many people have gotten burnt by it, and it hasn't lived up to the hype. I ran BTRFS Raid 6 for many years, right when it became available and never lost any data - and I waited and waited and waited and waited for it to become production ready. That never happened, instead they had the parity issue last year. Right before the message was it was "Mostly OK", then it was a black box warning. That all has lead me to the conclusion that Overstreet was correct saying BTRFS has fundamental design issues that have been baked into the file format. In other words, the BTRFS team has to live with a bad design and make the most of it. The fact that it is 8 years later and we're still talking about "mostly OK" supports that point of view. It didn't take Sun 8 years to get ZFS stable and they never when through a stage where people lost data.

[caligula]

No, I'm not butthurt at all.

So what are you? Illiterate?

Many people have already moved on to XFS.

They obviously don't need the features - or they think they don't need.

That all has lead me to the conclusion that Overstreet was correct saying BTRFS has fundamental design issues that have been baked into the file format. In other words, the BTRFS team has to live with a bad design and make the most of it. The fact that it is 8 years later and we're still talking about "mostly OK" supports that point of view. It didn't take Sun 8 years to get ZFS stable and they never when through a stage where people lost data.

From what I've gathered, companies like Facebook don't run Btrfs in RAID5/6, they use RAID1 or 10 instead. So, obviously they're not spending any effort on things that financially make no sense. Get it? It's too bad for us who'd like to have RAID5, LZ4, and whatnot, but sometimes things take time. Since we're talking filesystems, go and read about reiser4 and unionfs for a while.

[gbcox]

So what are you? Illiterate?


They obviously don't need the features - or they think they don't need.



From what I've gathered, companies like Facebook don't run Btrfs in RAID5/6, they use RAID1 or 10 instead. So, obviously they're not spending any effort on things that financially make no sense. Get it? It's too bad for us who'd like to have RAID5, LZ4, and whatnot, but sometimes things take time. Since we're talking filesystems, go and read about reiser4 and unionfs for a while.

ROFL.... when people resort to insults, it means they don't have any facts to support their POV. If you like it, that's fine. No reason to get emotional about it. As far as features are concerned, they can add or remove to their hearts content.

[starshipeleven]

No, I'm not butthurt at all. I do believe that BcacheFS has a better chance living up to the promise that BTRFS failed to deliver, and in a shorter period of time.

And base this on exactly 0 evidence.

At this point, it really can't be much worse.

Never say these words, they usually attract Chtulhu.

What I'm concerned about is that some people may see "Mostly OK" and think that means "OK".

If people can't fucking read and understand a single wiki page with all features then they deserve what they get. btrfs won't be the first nor the last that blows up in their hands.

I ran BTRFS Raid 6 for many years, right when it became available and never lost any data - and I waited and waited and waited and waited for it to become production ready. That never happened, instead they had the parity issue last year. Right before the message was it was "Mostly OK", then it was a black box warning.

That "unstable" warning in red near the btrfs RAID5/6 field a few lines below might still catch enough attention.
Really we are talking about a wiki of a filesystem aimed squarely at veteran linux users.

I ran BTRFS Raid 6 for many years, right when it became available and never lost any data - and I waited and waited and waited and waited for it to become production ready. That never happened, instead they had the parity issue last year.

So you ran a filesystem clearly marked as unstable, without a file checker and without scrubbing? And then complain that you just found out it had these fundamental issues last year? I really hope you aren't in charge of anything at your job.

That all has lead me to the conclusion that Overstreet was correct saying BTRFS has fundamental design issues that have been baked into the file format. In other words, the BTRFS team has to live with a bad design and make the most of it.

So, you jumped from a hype train to the next, with basically nothing to prove his claims apart from the fact that you think development is too slow.

The fact that it is 8 years later and we're still talking about "mostly OK" supports that point of view. It didn't take Sun 8 years to get ZFS stable and they never when through a stage where people lost data.

Sun didn't have to deal with a design supposed to support as much features as btrfs, so they could avoid many annoyances. Really, there would be no point in making something that is not significantly better than ZFS, so the development time being longer shouldn't be so strange.

[caligula]

ROFL.... when people resort to insults, it means they don't have any facts to support their POV. If you like it, that's fine. No reason to get emotional about it.

So what facts should we spoon feed to you now?

As far as features are concerned, they can add or remove to their hearts content.

Yes, adding features to Btrfs is easy, but not into XFS. XFS is almost 25 year old, stable filesystem with a rather stable on-disk format. They can't just rip that apart. Turning it into Btrfs style COW filesystem with RAID5 is an enormous change. You just don't do that.