I have BTRFS filesystem used for backup. I chose BTRFS because it can consolidate old leftover harddisks of various sizes into one big pool, and it can do "snapshot" which is pretty cheap way to do daily, weekly, monthly backups. Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow. What do I do? What do you guys plan to do? -- William Park <opengeometry@yahoo.ca>
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
I have BTRFS filesystem used for backup. I chose BTRFS because it can consolidate old leftover harddisks of various sizes into one big pool, and it can do "snapshot" which is pretty cheap way to do daily, weekly, monthly backups.
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development. Dhaval
What do I do? What do you guys plan to do? -- William Park <opengeometry@yahoo.ca> --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again -- William Park <opengeometry@yahoo.ca>
On Sun, Sep 3, 2017 at 2:13 PM William Park via talk <talk@gtalug.org> wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
Still doesn't say that upstream development has stopped. Dhaval <https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again>
-- William Park <opengeometry@yahoo.ca> --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On 09/03/2017 02:53 PM, Dhaval Giani via talk wrote:
On Sun, Sep 3, 2017 at 2:13 PM William Park via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote: > On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org <mailto:talk@gtalug.org>> > wrote: > > Now, I read (it's an old news, though) that BTRFS is being "deprecated" > > by Redhat, and presumably others will follow. > > Where have you read this news? As far as I know btrfs is actively being > developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
Still doesn't say that upstream development has stopped.
Dhaval
True enough. But with Redhat voting with their feet it will make the uptake of BTRFS much slower if at all. Remember Reiserfs? I was a great filesystem at least for my use. Much more reliable then the equivalent ext systems but non-technology related issues killed it. There may be an open GPL version of ZFS(Open ZFS). There is bcachefs. -- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity || fax: (416)585-9974 alvin@iplink.net ||
On Sun, Sep 3, 2017 at 9:02 PM Alvin Starr via talk <talk@gtalug.org> wrote:
On 09/03/2017 02:53 PM, Dhaval Giani via talk wrote:
On Sun, Sep 3, 2017 at 2:13 PM William Park via talk <talk@gtalug.org> wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
Still doesn't say that upstream development has stopped.
Dhaval
True enough. But with Redhat voting with their feet it will make the uptake of BTRFS much slower if at all.
Redhat was never a major contributor to btrfs. The folks who are on btrfs like it and will continue fund its development. We might see a btrfs v2 similar to ext3 and ext4. But only time will tell. Please let's not equate red hat with upstream kernel development. There are a lot of us who are unrelated to red hat doing it as well. Thanks Dhaval
Remember Reiserfs? I was a great filesystem at least for my use. Much more reliable then the equivalent ext systems but non-technology related issues killed it.
There may be an open GPL version of ZFS(Open ZFS). There is bcachefs.
-- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity || fax: (416)585-9974alvin@iplink.net ||
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On 09/03/2017 09:20 PM, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 9:02 PM Alvin Starr via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:
On 09/03/2017 02:53 PM, Dhaval Giani via talk wrote:
On Sun, Sep 3, 2017 at 2:13 PM William Park via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote: > On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org <mailto:talk@gtalug.org>> > wrote: > > Now, I read (it's an old news, though) that BTRFS is being "deprecated" > > by Redhat, and presumably others will follow. > > Where have you read this news? As far as I know btrfs is actively being > developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
Still doesn't say that upstream development has stopped.
Dhaval
True enough. But with Redhat voting with their feet it will make the uptake of BTRFS much slower if at all.
Redhat was never a major contributor to btrfs. The folks who are on btrfs like it and will continue fund its development. We might see a btrfs v2 similar to ext3 and ext4. But only time will tell. Please let's not equate red hat with upstream kernel development. There are a lot of us who are unrelated to red hat doing it as well.
Thanks Dhaval
I was not trying to equate RH with BTRFS development but pointing out that when a major distribution provider decides to drop a project that they once included its a big hit for the project. -- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity || fax: (416)585-9974 alvin@iplink.net ||
I was not trying to equate RH with BTRFS development but pointing out that when a major distribution provider decides to drop a project that they once included its a big hit for the project.
And as I mentioned, Red Hat was never a major contributor to btrfs. AFAIK, the maintainer of btrfs still contributes and maintains btrfs (and fwiw, he is almost local to us folks from the GTA). The other folks who contribute to btrfs still do. Bugs still get reported and fixed. There may not be too many new features coming, but how many mature filesystems have new features come in? This bit about btrfs being deprecated sounds like FUD to me, when at least no one upstream thinks that's the case. Again, RH not supporting btrfs officially just tells us that they did not get that many customer requests to justify *their* investment in it. Not that it will be deprecated by the upstream community (which is what you should care about). Not that it will be a big hit to the project. Thanks! Dhaval
| From: Dhaval Giani via talk <talk@gtalug.org> | Redhat was never a major contributor to btrfs. The folks who are on btrfs | like it and will continue fund its development. We might see a btrfs v2 | similar to ext3 and ext4. But only time will tell. Please let's not equate | red hat with upstream kernel development. There are a lot of us who are | unrelated to red hat doing it as well. I agree with all that. However... I use RedHat distros. I use RedHat as my quality control. Generally I have to seriously disagree with them to go to the bother of using something that they intentionally don't support. I've only used BTRFS by accident (I installed Fedora and somehow got it). It was not a problem. So I have no actual technical complaint about BTRFS. Here are the strikes against it: - it has taken way too long to be technically mature (at least I've inferred this) - long time-to-develop suggests complexity. Complexity is a really bad thing if you want reliability. - I'm *very* conservative about filesystems. When they go wrong they can cause long-term consequences. - my distros of choice no longer support BTRFS. That's much more negative than "don't yet support". It's a really big deal when RHEL drops something, especially in a point release. - BTRFS looks to have a big fat niche and yet it has failed to fill it. Perhaps it has even blocked others from entering that niche. I'd love BTRFS to be developed and prove the nay-sayers (like me) wrong. It does a bunch of things we could really use.
On Mon, Sep 4, 2017 at 11:49 AM, D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: Dhaval Giani via talk <talk@gtalug.org>
| Redhat was never a major contributor to btrfs. The folks who are on btrfs | like it and will continue fund its development. We might see a btrfs v2 | similar to ext3 and ext4. But only time will tell. Please let's not equate | red hat with upstream kernel development. There are a lot of us who are | unrelated to red hat doing it as well.
I agree with all that. However...
I use RedHat distros. I use RedHat as my quality control. Generally I have to seriously disagree with them to go to the bother of using something that they intentionally don't support.
You use Red Hat as your quality control. Lot of us do not. (Fedora is a different issue), but the red hat kernel is a beast. I have complaints against it, but that is for another forum. However, my point is, it is not necessarily quality control. What gets red hat its customers is it is support contracts, and the fact that it hires mores of the upstream developers.
I've only used BTRFS by accident (I installed Fedora and somehow got it). It was not a problem. So I have no actual technical complaint about BTRFS.
Here are the strikes against it:
- it has taken way too long to be technically mature (at least I've inferred this)
How long do you think it took for it to be technically mature? How long did say, xfs take, or ext4 take in comparison? Also, how much of a radical change was btrfs? btrfs is probably not the answer, and there will be other filesystems that will be better, but it is a pioneering filesystem in linux land. '
- long time-to-develop suggests complexity. Complexity is a really bad thing if you want reliability.
Accepted.
- I'm *very* conservative about filesystems. When they go wrong they can cause long-term consequences.
Almost everyone is, which is why btrfs adoption has not happened. People trust their xfses and like, and don't want to move unless there is a real compelling reason.
- my distros of choice no longer support BTRFS. That's much more negative than "don't yet support". It's a really big deal when RHEL drops something, especially in a point release.
Again, the emphasis being *your*.
- BTRFS looks to have a big fat niche and yet it has failed to fill it. Perhaps it has even blocked others from entering that niche.
I'd love BTRFS to be developed and prove the nay-sayers (like me) wrong. It does a bunch of things we could really use.
And as I have repeatedly said in this thread. Btrfs development is *NOT* stopping. All that is stopping is Red Hat's support in RHEL. While it might be a big deal for some (as you have rightly pointed out), upstream development will continue to happen, fixes will keep coming in, until something new and shiny comes in. But let's not say, "Red Hat no longer supports feature X in the kernel, so it is game over". That is a disservice to a lot of us who do this, and are not employed by Red Hat. The linux kernel is a community effort, let's not give Red Hat all the credit. Thanks! Dhaval
On September 4, 2017 12:19:06 PM EDT, Dhaval Giani via talk <talk@gtalug.org> wrote:
On Mon, Sep 4, 2017 at 11:49 AM, D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: Dhaval Giani via talk <talk@gtalug.org>
| Redhat was never a major contributor to btrfs. The folks who are on btrfs | like it and will continue fund its development. We might see a btrfs v2 | similar to ext3 and ext4. But only time will tell. Please let's not
<snip the middle>
employed by Red Hat. The linux kernel is a community effort, let's not give Red Hat all the credit.
Let us however give credit where it is due. There is a reason, that in popular Linux distributions, there are rpm based systems and then there are are other repository based management systems. Of course if you are diehard, you may always build from source. Early innovation and early adoption pave the way, at the time. Its a big world and there is plenty room for upstart innovation as well. Some of these upstarts are born of vanity and some are born of necessity. The free market works that way. Take cars for instance. A person really only needs one or two types of personal four wheeled gas powered conveyances, yet look at the market. Hundreds of makes and models each with their own selling points, all of which are mostly based on convenience and choice, but there is hardly any difference in utility between them all. Consumers choice is what a free market is all about. Except for the carburetor which got 100mpg, we all know what happened to that one ... Cheers,
Thanks! Dhaval --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell Sent by K-9 Mail
On Sun, 3 Sep 2017, Alvin Starr via talk wrote:
True enough. But with Redhat voting with their feet it will make the uptake of BTRFS much slower if at all. Remember Reiserfs? I was a great filesystem at least for my use. Much more reliable then the equivalent ext systems but non-technology related issues killed it.
I see what you did there ;)
There may be an open GPL version of ZFS(Open ZFS). There is bcachefs.
They may stick with XFS? There is always NILFS too. It's been a long time since the introduction of ZFS. COW/log structured (LS) filesystems still haven't really taken off. There heve been a lot of filesystem innovations that never flew. I'm starting to wonder if/when COW/LS will really get popular. The MS-Windows fuilesystem ReOS is COW apparently which may drive adoption of COW/LS filesystems even outside of MS-Windows. Cheers, Rob
On 2017-09-03 09:02 PM, Alvin Starr via talk wrote:
Remember Reiserfs? … Much more reliable then the equivalent ext systems but non-technology related issues killed it.
Very much technology related, it seems to me. It's hard to manage patch requests when your lead architect is serving 15 to life in San Quentin for murder. Stewart
On 09/03/2017 09:40 PM, Stewart C. Russell via talk wrote:
On 2017-09-03 09:02 PM, Alvin Starr via talk wrote:
Remember Reiserfs? … Much more reliable then the equivalent ext systems but non-technology related issues killed it. Very much technology related, it seems to me. It's hard to manage patch requests when your lead architect is serving 15 to life in San Quentin for murder.
True enough but the project could have been picked up by others. I think that if it was zyzzy-fs then it would likely had carried on. Lots of projects extend beyond the original authors interest and in some sad cases life. -- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity || fax: (416)585-9974 alvin@iplink.net ||
On 2017-09-03 09:56 PM, Alvin Starr via talk wrote:
True enough but the project could have been picked up by others.
Something as complex as a FS needs corporate support, and no company wishes to be associated with a convicted murderer. Reiser was also famously difficult to get along with (a sample of one of his rants is here: https://lkml.org/lkml/2006/7/21/109), which certainly didn't help his code's uptake. Stewart
On 09/03/2017 10:18 PM, Stewart C. Russell via talk wrote:
On 2017-09-03 09:56 PM, Alvin Starr via talk wrote:
True enough but the project could have been picked up by others. Something as complex as a FS needs corporate support, and no company wishes to be associated with a convicted murderer. Reiser was also famously difficult to get along with (a sample of one of his rants is here: https://lkml.org/lkml/2006/7/21/109), which certainly didn't help his code's uptake.
To my original point these are not technical issues but are just as effective in killing a project. -- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity || fax: (416)585-9974 alvin@iplink.net ||
On Sun, Sep 03, 2017 at 10:18:19PM -0400, Stewart C. Russell via talk wrote:
Something as complex as a FS needs corporate support, and no company wishes to be associated with a convicted murderer. Reiser was also famously difficult to get along with (a sample of one of his rants is here: https://lkml.org/lkml/2006/7/21/109), which certainly didn't help his code's uptake.
The severe (and silent) data loss cases I encountered with reiserfs made me stop using it. I always wondered what was wrong with SuSE for continuing to use it by default for so long. -- Len Sorensen
On Sun, Sep 3, 2017 at 9:18 PM, Stewart C. Russell via talk <talk@gtalug.org
wrote:
On 2017-09-03 09:56 PM, Alvin Starr via talk wrote:
True enough but the project could have been picked up by others.
Something as complex as a FS needs corporate support, and no company wishes to be associated with a convicted murderer. Reiser was also famously difficult to get along with (a sample of one of his rants is here: https://lkml.org/lkml/2006/7/21/109), which certainly didn't help his code's uptake.
Greetings I spent about an hour reading through emails around and after the one listed. If that's a rant I wonder what you call the ????? that Linus Torvald (hope I have that written right!) does? Dee
On Mon, 4 Sep 2017 07:09:08 -0500 o1bigtenor via talk <talk@gtalug.org> wrote:
wrote: On 2017-09-03 09:56 PM, Alvin Starr via talk wrote:
True enough but the project could have been picked up by others. Something as complex as a FS needs corporate support, and no company wishes to be associated with a convicted murderer. Reiser was also famously difficult to get along with (a sample of one of his rants is here: https://lkml.org/lkml/2006/7/21/109), which certainly didn't help his code's uptake. I spent about an hour reading through emails around and after the one
On Sun, Sep 3, 2017 at 9:18 PM, Stewart C. Russell via talk <talk@gtalug.org listed. If that's a rant I wonder what you call the ????? that Linus Torvald (hope I have that written right!) does?
hehehe, yeah... the quoted example was so not a rant.. imnsho some of the my top favorite best rants (and there is a list of top 100 rants somewhere) has to include Linus saying: "one more time: you caused the problem, you need to fix it. None of this 'I can do whatever I want, others have to clean up after me' crap." and some by Alan during the ipchains era and the gnu dude. I do not even think any rant of hr ever made it into the top 1000 rants :) 2c Andre
On Sun, Sep 03, 2017 at 09:02:24PM -0400, Alvin Starr via talk wrote:
True enough. But with Redhat voting with their feet it will make the uptake of BTRFS much slower if at all.
I am not sure btrfs is quite ready for production use yet, so not sure why redhat ever supported doing so in the first place.
Remember Reiserfs? I was a great filesystem at least for my use. Much more reliable then the equivalent ext systems but non-technology related issues killed it.
Actually reiserfs was terrible and very much not reliable. It wouldn't tell you when it had silently destroyed your file, so it looked OK for a long time until you noticed. Oh and the disaster of having a disk image of a reiserfs filesytem in your filesystem if you tried to run the repair tool was fun.
There may be an open GPL version of ZFS(Open ZFS). There is bcachefs.
-- Len Sorensen
On 03/09/17 02:12 PM, William Park via talk wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
This really should be read as 'if you call us to exercise your support contract, this piece isn't covered'. You'll get the same response for openldap(*), as they want you to use their IDM product. It doesn't make openldap any less in quality or utility. * Based on recent real-world experience. -- Scott Sullivan
On 4 September 2017 at 20:03, Scott Sullivan via talk <talk@gtalug.org> wrote:
On 03/09/17 02:12 PM, William Park via talk wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
This really should be read as 'if you call us to exercise your support contract, this piece isn't covered'.
You'll get the same response for openldap(*), as they want you to use their IDM product. It doesn't make openldap any less in quality or utility.
* Based on recent real-world experience. -- Scott Sullivan
Some years ago (I'd guess 2005-ish, so it has been a while), I recall Red Hat support declining to respond to issues relating to OpenSSL because we had (I forget the exact term) 'unsupported software' in that we were using the JFS kernel modules and RPM packages that, despite being included, were apparently "not supported." They were fairly keen not to respond to *anything* because we had JFS (that they chose to include, but not support). That seemed really weaselly to me at the time. It would be one thing had we had a custom compiled kernel with our own wacky stuff, but everything *was* stock; the JFS builds were *provided by Red Hat*. Ever since, I have not been highly enthralled by the merits of "Red Hat support." It *is* troublesome to me that many people (and I have seen that mentioned on this thread) consider "supported by Red Hat" to be somehow essential to "usable on Linux." It puts Red Hat on a pedestal which is harmful in multiple ways. - It gives them power that they shouldn't have; - It enacts "facts" like those that were the point of the original question... Is BTRFS any good? Should you use it? Or is it needful to migrate to something else? The answers that seem to arrive have the shape "Well, RHAT doesn't want to support it, so everyone should consider it obsolete and unsupportable." - I seem to recall RHAT developing ext4; unless things have further changed, that ought to mean that the only thing they are keen to support is ext4. XFS, NILFS2, BTRFS, JFS, everything else, need not apply. That's all pretty harmful to my mind. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On 09/05/2017 09:42 AM, Christopher Browne via talk wrote:
On 03/09/17 02:12 PM, William Park via talk wrote:
On Sun, Sep 03, 2017 at 05:52:12PM +0000, Dhaval Giani wrote:
On Sun, Sep 3, 2017 at 1:41 PM William Park via talk <talk@gtalug.org> wrote:
Now, I read (it's an old news, though) that BTRFS is being "deprecated" by Redhat, and presumably others will follow.
Where have you read this news? As far as I know btrfs is actively being developed and no one is stopping development.
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again
This really should be read as 'if you call us to exercise your support contract, this piece isn't covered'.
You'll get the same response for openldap(*), as they want you to use their IDM product. It doesn't make openldap any less in quality or utility.
* Based on recent real-world experience. -- Scott Sullivan Some years ago (I'd guess 2005-ish, so it has been a while), I recall Red Hat support declining to respond to issues relating to OpenSSL because we had (I forget the exact term) 'unsupported software' in
On 4 September 2017 at 20:03, Scott Sullivan via talk <talk@gtalug.org> wrote: that we were using the JFS kernel modules and RPM packages that, despite being included, were apparently "not supported."
They were fairly keen not to respond to *anything* because we had JFS (that they chose to include, but not support). That seemed really weaselly to me at the time. It would be one thing had we had a custom compiled kernel with our own wacky stuff, but everything *was* stock; the JFS builds were *provided by Red Hat*.
Ever since, I have not been highly enthralled by the merits of "Red Hat support." That is kind of weaselly but in line with just about every other enterprise support organization out there. First update to the latest software(images of the tape player in the IT Croud). Oh your using something we don't support .... Sorry... Ever deal wit Microsoft support? Cisco support? Oracle support? ....... It *is* troublesome to me that many people (and I have seen that mentioned on this thread) consider "supported by Red Hat" to be somehow essential to "usable on Linux." It puts Red Hat on a pedestal which is harmful in multiple ways. For me now I use redhat mostly because I am familiar with the setup and its a comfortable environment. But I moved from Debian to RH years ago because I was spending all my time patching kernels and rebuilding systems. Redhat had quick security fixes and they were easy to install. This is something like 15 years ago and the landscape has changed dramatically since then.
The thing about RH is that its an easy sell corporately. You can point to a company that "supports" the OS and check off that box in the "due diligence" form. The same thing is true of SUSE. Debian and Ubuntu don't seem to have the same support offerings but I could be wrong on that point.
- It gives them power that they shouldn't have;
- It enacts "facts" like those that were the point of the original question... Is BTRFS any good? Should you use it? Or is it needful to migrate to something else? The answers that seem to arrive have the shape "Well, RHAT doesn't want to support it, so everyone should consider it obsolete and unsupportable." That is not even close to a real characterization of the conversation. The point has been that losing a major distribution, and RH is a major distribution, just takes away from the momentum that a project may have. Take a look at Xen and its uptake outside Citrix once RH moved to KVM.
- I seem to recall RHAT developing ext4; unless things have further changed, that ought to mean that the only thing they are keen to support is ext4. XFS, NILFS2, BTRFS, JFS, everything else, need not apply.
That's all pretty harmful to my mind.
From my perspective BTRFS needs to handle tiered storage before its really useful and that appears to be a long way off. Most of the other features of BTRFS are just as well supported by other Linux storage management tools. -- Alvin Starr || land: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
Hi Alvin
That is not even close to a real characterization of the conversation. The point has been that losing a major distribution, and RH is a major distribution, just takes away from the momentum that a project may have. Take a look at Xen and its uptake outside Citrix once RH moved to KVM.
As I have mentioned countless times in this thread. Red Hat is not a major contributor to btrfs (and hasn't been for a while). If you want a big adoptee of btrfs, look at facebook. Please understand, by constantly going back to Red Hat, you are ensuring Open Source and the Linux Kernel get looked as a single company project. From what I can see on lwn, red hat hasn't even been a majority contributor to the kernel for a while. So, please stop spreading this bit that just because red hat has pulled support away from a project, it will die. The project will go away only when there are superior options. Thanks! Dhaval
Alvin Starr via talk wrote:
On 09/05/2017 09:42 AM, Christopher Browne via talk wrote:
... They were fairly keen not to respond to *anything* because we had JFS (that they chose to include, but not support). That seemed really weaselly to me at the time. It would be one thing had we had a custom compiled kernel with our own wacky stuff, but everything *was* stock; the JFS builds were *provided by Red Hat*.
Ever since, I have not been highly enthralled by the merits of "Red Hat support." That is kind of weaselly but in line with just about every other enterprise support organization out there. First update to the latest software(images of the tape player in the IT Croud). Oh your using something we don't support .... Sorry...
Linux supports more different filesystems than any other OS in history, but for the most part a filesystem's a filesystem; you toss in your files and have high expectations of finding them again later. And in the general Linux world you get to pick one, and see how well it works and whether its developers are on top of any bugs. However, when you get to Red Hat's paid support model, having to train support staff on the different tools to make and fix N different filesystems and the bits of wisdom that pertain to each will drive its costs up, and they can save a fair bit by pushing RH systems into a very limited subset of filesystems with solid track records and only having to support those. It's also possible they see ZFS-on-Linux as more powerful, or saw some unexploded Oracle intellectual-property issues under Btrfs and wanted to quietly back away.
But I moved from Debian to RH years ago because I was spending all my time patching kernels and rebuilding systems. Redhat had quick security fixes and they were easy to install. This is something like 15 years ago and the landscape has changed dramatically since then.
The thing about RH is that its an easy sell corporately. You can point to a company that "supports" the OS and check off that box in the "due diligence" form.
And if you're in the "Enterprise" model of wanting to buy an off-the-shelf system and support and not maintain any in-house clue then RH will happily take your money and dance that dance with you.
Debian and Ubuntu don't seem to have the same support offerings but I could be wrong on that point.
Debian at least is a volunteer organization and you can't wave the corporate Amex at them. They're generally quite reasonable at issuing fixes to CVE issues and their stuff Just Works but if you want to be spoon-fed you have to pick up the spoon in your own hand, as it were.
- It enacts "facts" like those that were the point of the original question... Is BTRFS any good? Should you use it? Or is it needful to migrate to something else? The answers that seem to arrive have the shape "Well, RHAT doesn't want to support it, so everyone should consider it obsolete and unsupportable."
I hope nobody is looking at redoing their root filesystems in any sort of stampede to a different filesystem. The choice of filesystem usually runs for the lifetime of an install, and when Btrfs became ready for prime-time I used it in a few non-core systems I was setting up, and it's been happily working. Certainly I'd not now try to swim upstream by using it on an RH/CentOS installation, but Debian and Gentoo are still happy with it. But the vast majority of Linux systems I've built have had ext2/3/4. (Mind you, a few Reiserfs systems a late co-worker set up _did_ get repaved proactively after one or two shat themselves. But that's the only FS that I've seen being actively bad.) I should add that the most solid thing I've used was ZFS, but that was on another OS; I haven't had occasion to look hard at ZoL yet. -- Anthony de Boer
On Tue, Sep 5, 2017 at 6:33 PM, Anthony de Boer via talk <talk@gtalug.org> wrote:
(Mind you, a few Reiserfs systems a late co-worker set up _did_ get repaved proactively after one or two shat themselves. But that's the only FS that I've seen being actively bad.)
You got me there. It's pure luck that my keyboard isn't now a coffee-spattered ruin. That's the best and most concise description I've heard for what a filesystem does when it... goes. Cheers, Mike
On 5 September 2017 at 18:33, Anthony de Boer via talk <talk@gtalug.org> wrote:
(Mind you, a few Reiserfs systems a late co-worker set up _did_ get repaved proactively after one or two shat themselves. But that's the only FS that I've seen being actively bad.)
I should add that the most solid thing I've used was ZFS, but that was on another OS; I haven't had occasion to look hard at ZoL yet.
I never had any failures with Reiserfs, but was careful to choose things I could afford to lose ;-) Until the tale headed down the homicidal path, the disagreements didn't seem to be all that vital. There were a number of entertaining choices in Reiserfs, notably off-the-wall being the choice not to have inodes. There was enough odd that it shouldn't have come as any surprise that the "regular kernel community" didn't head out like lemmings, off to leap cliffs, to adopt every aspect instantaneously. The fact that the project was trying out different things with a view to seeing what *could* be changed seemed mighty useful. There were good collegial debates at the time. I recall some fun bits trying to figure out how you'd attach extended attributes in a useful way (hint: it's not particularly easy, because people are accustomed to using tar to capture filesystems, and you'd need to change tar somewhat substantially to be EA-aware). None of it seemed to be nasty the way that things got surrounding, oh, say, Net-vs-Open-BSD, or the qmail-vs-zmail debates, where there were some strong-willed personalities that couldn't coexist on the same project. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Christopher Browne wrote:
... I recall some fun bits trying to figure out how you'd attach extended attributes in a useful way (hint: it's not particularly easy, because people are accustomed to using tar to capture filesystems, and you'd need to change tar somewhat substantially to be EA-aware).
One big screwup was that there are multiple add-ons like attributes and ACLs and last I looked each had their own syscalls to get/set that stuff. Ideally there'd be a single syscall to get a whole blob of that stuff for backup purposes, that you could push back in to restore all of those bits. As it is, each tool (tar, rsync, cpio, ...) has to make its own decision whether to implement each Brilliant New Idea and how to go about it and wedge it in in some hopefully-backward-compatible way. -- Anthony de Boer
Greetings To GTALUG, ----- Original Message ----- From: "Anthony de Boer via talk" <talk@gtalug.org> To: "Alvin Starr via talk" <talk@gtalug.org> Sent: Tuesday, September 05, 2017 6:33 PM Subject: Re: [GTALUG] From BTRFS to what?
Alvin Starr via talk wrote:
On 09/05/2017 09:42 AM, Christopher Browne via talk wrote:
...
<snip>
Debian and Ubuntu don't seem to have the same support offerings but I could be wrong on that point.
Debian at least is a volunteer organization and you can't wave the corporate Amex at them. They're generally quite reasonable at issuing fixes to CVE issues and their stuff Just Works but if you want to be spoon-fed you have to pick up the spoon in your own hand, as it were.
As a Windows XP "orphan" on an ancient Dell desktop, who is now escaping from the Microsoft Boa Constrictor, by switching to debian Linux on a new custom-built PC (parts specified but not yet built), So it's good to have my choice of debian confirmed as a good one. <snip>
I hope nobody is looking at redoing their root filesystems in any sort of stampede to a different filesystem. The choice of filesystem usually runs for the lifetime of an install, and when Btrfs became ready for prime-time I used it in a few non-core systems I was setting up, and it's been happily working. Certainly I'd not now try to swim upstream by using it on an RH/CentOS installation, but Debian and Gentoo are still happy with it. But the vast majority of Linux systems I've built have had ext2/3/4.
Rignt on about ext2/3/4. After much research, my design for the linux disk drive partitioning for the desktop PC uses a blend of all three: ext2, ext3, ext4. <snip> * * * * * * Regarding more esoteric filesystems along hte lines of: btrfs and zfs. In another project -- a website -- I plan to start up the website using debian Linus ext4 under a cloud-hosted QEMU / KVM vistual server. But I also have experimented with a very interesting BSD-flavoured *nix called DragonFlyBSD (DFLY), again running on a cloud-hosted QEMU / KVM vistual server. My research indicates that DFLY has two major attractions: 1. DFLY seems to be a very high-performance os (particularly its network stack). But this is based on comments by other DFLY users, not on my personal experience. 2. DFLY offers its own advanced filesystem HAMMER1 (to distinguish the current production-ready HAMMER from the new HAMMER2 currently under development). HAMMER1 offers may features of advanced file systems (e.g. snapshot). DFLY (and HAMMER!) seems to have an enthusiastic (but very small) user base. One interesting quirk about DFLY: Although DFLY is primarily aimed at the physical server hardware market, there are sometimes calls for help on the email discussion forum, from courageous DFLY tire-kickers who are installing DFLY on personal computers / workstations (especially laptop / notebook computerrs). Seemingly becaue DFLY is so very resource efficient it can use otherwise obsolete underpowered hardware. The big struggles these DFLY notebook users have, seem to be with getting video and other peripherals working. * * * * * * In reference to advanced filesystems, I am wondering about HAMMER1 in the context of Linux: 1. Occasionally, there is mention on the DFLY email forum, of the idea of porting HAMMER to Linux, but but obviously this would be a huge undertaking and not necessarily one with a happy ending. 2. Would there be some way to use a (dedicated server / virtual server) DFLY + HAMMER1 setup as a network-addressable filesystem for Linux? Get the operational and reliability benefits of DFLY+HAMMER but run them in their purely native mode. Steve
-- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On 2017-09-06 10:22 AM, Steve Petrie, P.Eng. via talk wrote:
Rignt on about ext2/3/4. After much research, my design for the linux disk drive partitioning for the desktop PC uses a blend of all three: ext2, ext3, ext4.
There's really no advantage in using anything *but* ext4 out of these: ext2 and ext3 are essentially older, less-journally versions of the same idea. There might be a niche that could favour one of the older ext* FSs, but I haven't found it. And here's me old enough to remember the extfs/xiafs war, too. Not that age adds anything here but an increasing inability to read small print.
DFLY (and HAMMER!) seems to have an enthusiastic (but very small) user base.
Sounds just like BSD, then. /drops mic …
participants (15)
-
ac -
Alvin Starr -
Anthony de Boer -
Christopher Browne -
D. Hugh Redelmeier -
Dhaval Giani -
lsorense＠csclub.uwaterloo.ca -
Mike -
o1bigtenor -
Robert Brockway -
Russell -
Scott Sullivan -
Steve Petrie, P.Eng. -
Stewart C. Russell -
William Park