"Project Springfield" Is Red Hat's Effort To Improve Linux File-Systems / Storage

[mppix]

That's a frontend for the same kernel's software RAID subsystem just as mdadm is. It's just a different userspace tool.

This is incredibly misleading. For the record
Yes, LVM replaced its own RAID 1 code with mdadm (likely the best implementation of software raid out there), known as lvmraid
However, mdadm+lvm and lvmraid are very different things
- mdadm+lvm builds a lvm stack on top of a mdadm array, i.e. lvm allocates physical volumes that are raid arrays
- lvmraid builds raid for the logical volumes on top of the logical volume group; in this case lvm allocates the physical drives as physical volumes

Lvmraid unifies logical volume management and raid. It is quite powerful, e.g. you decide (and convert) the raid level on a logical volume level not just everything. It is fairly new but works very well. On the other hand, mdadm+lvm is, by far, older and better known.

[polarathene]

Says who? Check out their official documentation. Their own answer is "Maybe"

That page points out stability several times, how are these statements not equivalent to filesystems that you'd consider stable?:

The filesystem disk format is stable

Not only is every effort being made to ensure that it remains stable and fast but to make it more so with each and every commit.

As with all software, newly added features may need a few releases to stabilize.

But sure... "Maybe" applies in the sense it depends on what features you want to use. Does features for other "stable" filesystems that aren't ready all of the sudden making those filesystems no longer stable? No.. just those new features may not be particularly stable or well tested yet.

As for who considers it stable for production use... Facebook(millions of servers using it), openSUSE, Google(ChromeOS).

[gbcox]

That page points out stability several times, how are these statements not equivalent to filesystems that you'd consider stable?:



But sure... "Maybe" applies in the sense it depends on what features you want to use. Does features for other "stable" filesystems that aren't ready all of the sudden making those filesystems no longer stable? No.. just those new features may not be particularly stable or well tested yet.

As for who considers it stable for production use... Facebook(millions of servers using it), openSUSE, Google(ChromeOS).

It's fairly simple. They have a section in their webpage specifically to discuss the suitability issue. I didn't write it... THEY DID. It's simply feckless and no amount making excuses for them is going to change what it says. Show me where F2FS, XFS or EXT4 have statements like that. I've searched... I can't find any. They are trying to have it both ways... implying that their filesystem is stable without actually saying it. It either is or it isn't. Again, I'm not talking about bug free. Software will always have bugs, but after a decade in development they should be confident enough to just clearly say it's stable. Obviously, they lack the courage of their convictions.

[NotMine999]

Leave it to Red Hat to decide that the wheel actually isn't round so it needs to be improved.

Must have been the same logic used to infiltrate "SystemDeath" into Red Hat repositories that ultimately infected almost all Linux distributions.

Yes, the good old Micro$haft method of "Revise. Extend. Extinguish."

[polarathene]

It's fairly simple. They have a section in their webpage specifically to discuss the suitability issue.

They are trying to have it both ways... implying that their filesystem is stable without actually saying it. It either is or it isn't.

If you use the filesystem with it's basic default features, it's stable. The page makes that rather clear. There are other features like RAID 5/6 that aren't stable but available, none of those are going to be used without the user making the effort to stray from defaults, in which case a page like that is useful to know what is safe to use if you're configuring it.

As the filesystem is newer than others, it may also depend how old your kernel is, so you get a nice history to know when certain features became available like zstd transparent compression or RAID-C3/C4, features you won't find common in other filesystems(F2FS got transparent compression, but again you'd need to ensure you have a recent enough kernel, else you'll have issues mounting an existing F2FS with that feature in use).

I don't care about if other filesystems have such pages or not, I don't see it as a bad thing, it's a rather useful resource. How easy is it to look up the status of features like XFS CoW and see it's progress and requirements to start using, if it's stable and ready, etc?

If you want to use BTRFS, it's stable, go enjoy it. If you want to use BTRFS because of some neat features / advantages it has over many other filesystems, make sure that those features are considered stable(some are by themselves, but may have some risk in combination as they're not enabled by default, so there's risks, these do get reported and fixed however such as compression + de-dupe a year or so ago). If you use a newer feature but your LTS distro/kernel didn't backport it, then it's not available, gee I wonder why, maybe that page would be useful to find out why I can't use feature X I heard about on my Ubuntu 18.04 install.

Anyway, lets just agree with what the wiki "Maybe" answer explained as "Different people have different concepts of stability", I see BTRFS as stable, you don't, awesome.

[gbcox]

If you use the filesystem with it's basic default features, it's stable. The page makes that rather clear.
...
Anyway, lets just agree with what the wiki "Maybe" answer explained as "Different people have different concepts of stability", I see BTRFS as stable, you don't, awesome.

The page doesn't make that quite clear. The only place that "stability" of BTRFS is mentioned is the one section I referenced. As I mentioned, they wrote it, and "maybe" isn't an answer - especially after over a decade of development. Regarding your statement of "how easy it is to look up the status of features... if it's stable and ready, etc? " that's my point... no where do they state that a particular function is stable. Check out their status page... the strongest recommendation they will give on a particular feature is: "Should be safe to use".

If you want to sing their praises, have at it... but I'm not writing this stuff... they are. No where does it say what you claim it is saying. It's all written in plain english for the world to see.

[polarathene]

No where does it say what you claim it is saying. It's all written in plain english for the world to see.

These quotes are from the main BTRFS wiki page you had linked earlier:

The filesystem disk format is stable

Not only is every effort being made to ensure that it remains stable and fast but to make it more so with each and every commit.

As with all software, newly added features may need a few releases to stabilize.

As I mentioned, they wrote it, and "maybe" isn't an answer - especially after over a decade of development.

Because "Maybe" depends on your expectation of what stable is and how you intend to use BTRFS. A blanket "Yes it's stable" would be invalid, but "No it's unstable" would be false too, so if it's not an absolute yes or no...it's a maybe, make sense?

You have plenty of big companies that trust BTRFS stability. Anyone who is a storage professional will also advise you to keep backups(3-2-1), regardless of filesystem stability. Make of that what you will.

Check out their status page... the strongest recommendation they will give on a particular feature is: "Should be safe to use".

Is that not "stable" enough for you? Do you want them to say "Won't cause any problems", and then cry that they're liars because of some bug/regression that materializes later? They mark it in bright green and give it an "OK" label. If that's not satisfactory enough for you, don't use the filesystem then.

As for strongest recommendation for stability:

The filesystem disk format is stable. This means it is not expected to change unless there are very strong reasons to do so.

Mentioned at the bottom of the status page, that's important to be reliable/stable, they give you as definite of an answer as "stable" there for you, is that not good enough? They expand with a caveat following that, instead of phrasing it as "Should be stable" which clearly wouldn't fly for you, but perhaps different wording does.

Where are the equivalent resources for EXT4/XFS or whatever you use as your "stable" filesystem, you seem to avoid that question from before for some reason.

[gbcox]

These quotes are from the main BTRFS wiki page you had linked earlier:

Because "Maybe" depends on your expectation of what stable is and how you intend to use BTRFS. A blanket "Yes it's stable" would be invalid, but "No it's unstable" would be false too, so if it's not an absolute yes or no...it's a maybe, make sense?

You have plenty of big companies that trust BTRFS stability. Anyone who is a storage professional will also advise you to keep backups(3-2-1), regardless of filesystem stability. Make of that what you will.

Is that not "stable" enough for you? Do you want them to say "Won't cause any problems", and then cry that they're liars because of some bug/regression that materializes later? They mark it in bright green and give it an "OK" label. If that's not satisfactory enough for you, don't use the filesystem then.

As for strongest recommendation for stability:

Mentioned at the bottom of the status page, that's important to be reliable/stable, they give you as definite of an answer as "stable" there for you, is that not good enough? They expand with a caveat following that, instead of phrasing it as "Should be stable" which clearly wouldn't fly for you, but perhaps different wording does.

Where are the equivalent resources for EXT4/XFS or whatever you use as your "stable" filesystem, you seem to avoid that question from before for some reason.

¯\_(ツ)_/¯ How many times do I have to say it... I didn't write it, they did. If they wanted to say it's now stable, it's a simple thing to do - but as I said before, apparently they don't have the courage of their convictions. Again, you can try to distract all you want, but it won't work. They have a section in their documentation dedicated to answering the stability issue. Going on a treasure hunt and cherry-picking words and phrases to try to make your point is just silly.

[polarathene]

They have a section in their documentation dedicated to answering the stability issue.

Cool, third time... where can I easily find equivalent for XFS to check status of it's CoW work?

What about DAX support for both XFS and EXT4, do either have a page showing me what kernels are required to benefit from DAX and improvements since initial support, what about stability status for DAX? Or hell the XFS and EXT filesystems themselves, where and how are they declared stable?

[gbcox]

Cool, third time... where can I easily find equivalent for XFS to check status of it's CoW work?

What about DAX support for both XFS and EXT4, do either have a page showing me what kernels are required to benefit from DAX and improvements since initial support, what about stability status for DAX? Or hell the XFS and EXT filesystems themselves, where and how are they declared stable?

(◔_◔) When all else fails, try to deflect or change the subject eh? Just go back and read the conversation thread. It's all there.