Re: BTRFS
On Thu, Nov 5, 2015 at 6:52 AM, Benjamin Lefoul <benjamin.lef...@nwise.se> wrote: > Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one prototype of > our system running it (most of our productions are still running older > openSUSE on ext4). > > We are considering switching to Scientific Linux, but the btrfs question > remains. The prototype is doing fine so far, but what we are really > interested in with BTRFS is RAID and compression (not tried yet). > > The new openSUSE release from yesterday (apparently no longer called > "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) as > upstream, while keeping btrfs as default, and I don't know if that means SLES > (a major enterprise distro) also considers BTRFS mature. The "ext*" series of filesystems have been extremely reliable, and stable, and have gained incrementally in capacity in time to support the growing needs. > If you recommend not using BTRFS in Scientific Linux until Red Hat makes a > major release of it, that could mean 3 years of waiting given their release > life cycle. I am no longer sure which way to go… What's the rush? Is there a single compelling performance benefit in your workflow? > Benjamin Lefoul > nWISE AB > > > > > From: David Sommerseth [sl+us...@lists.topphemmelig.net] > Sent: Thursday, November 05, 2015 11:54 AM > To: Benjamin Lefoul; scientific-linux-users@fnal.gov > Subject: Re: BTRFS > > On 05/11/15 09:38, Benjamin Lefoul wrote: >> Hi, >> >> If the btrfs filesystem on SL7 mature enough for a production environment? >> According to Sanders van Vugt it was not even available in RHEL 7.0, but >> will be (is?) in updates… > > I would claim that btrfs is NOT ready for primetime production where > your data is precious. If your intention is to use it on systems where > you have good backups to get acquainted with it, test it in a broader > scale and do bug reporting, then it is probably fine. > > Btrfs have also been a topic on a few conferences I've been on over the > years (like devconf.cz), and file system developers doing btrfs > presentations have often said that btrfs still needs to be treated > carefully. It just takes time to develop and mature an advanced file > system. > > In addition I would also say that once RHEL puts it in a release ready > for production, that's the point where you can begin to have real > confidence in the file system. Currently I believe it is only available > as a technology preview. More on technology preview can be found here: > <https://access.redhat.com/support/offerings/techpreview> > > On the other hand, I am conservative and very careful when it comes to > data integrity. > > > -- > kind regards, > > David Sommerseth
Re: BTRFS
On 05/11/15 12:52, Benjamin Lefoul wrote: > Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one > prototype of our system running it (most of our productions are still > running older openSUSE on ext4). > > We are considering switching to Scientific Linux, but the btrfs > question remains. The prototype is doing fine so far, but what we are > really interested in with BTRFS is RAID and compression (not tried yet). > > The new openSUSE release from yesterday (apparently no longer called > "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) > as upstream, while keeping btrfs as default, and I don't know if that > means SLES (a major enterprise distro) also considers BTRFS mature. > > If you recommend not using BTRFS in Scientific Linux until Red Hat > makes a major release of it, that could mean 3 years of waiting given > their release life cycle. I am no longer sure which way to go… AFAIK, the btrfs support in openSUSE is fairly restricted in the supported feature sets. So the gap between btrfs and what you can do with mdraid + LVM + XFS is fairly small. I didn't find an updated comparison table, but this is from an offical SUSE resource: <https://lwn.net/Articles/576280/> Btrfs does indeed have a lot of great things, and everyone wants it to be ready yesterday. But unfortunately, it just takes time to make it enterprise ready. On the other hand, there are many users of btrfs, even the Jolla phone ships with btrfs. But what makes it harder with btrfs than, say ext4 or xfs, is that it supports so much more than a traditional file system. So you do need to consider which features have been used and configured. Some areas of btrfs is probably very solid and stable, but in the moment you add one more advanced feature - you can just as well happen to enter unstable ground again. I'd probably recommend to dig deeper into the LWN.net archives, there is a lot of good articles and comments there as well on the file system stuff. Otherwise, here is one of the later presentations I could find on file systems from a Red Hat engineer: <https://www.youtube.com/watch?v=83L9d2EyBco> -- kind regards, David Sommerseth > > From: David Sommerseth [sl+us...@lists.topphemmelig.net] > Sent: Thursday, November 05, 2015 11:54 AM > To: Benjamin Lefoul; scientific-linux-users@fnal.gov > Subject: Re: BTRFS > > On 05/11/15 09:38, Benjamin Lefoul wrote: >> Hi, >> >> If the btrfs filesystem on SL7 mature enough for a production environment? >> According to Sanders van Vugt it was not even available in RHEL 7.0, but >> will be (is?) in updates… > > I would claim that btrfs is NOT ready for primetime production where > your data is precious. If your intention is to use it on systems where > you have good backups to get acquainted with it, test it in a broader > scale and do bug reporting, then it is probably fine. > > Btrfs have also been a topic on a few conferences I've been on over the > years (like devconf.cz), and file system developers doing btrfs > presentations have often said that btrfs still needs to be treated > carefully. It just takes time to develop and mature an advanced file > system. > > In addition I would also say that once RHEL puts it in a release ready > for production, that's the point where you can begin to have real > confidence in the file system. Currently I believe it is only available > as a technology preview. More on technology preview can be found here: > <https://access.redhat.com/support/offerings/techpreview> > > On the other hand, I am conservative and very careful when it comes to > data integrity. > > > -- > kind regards, > > David Sommerseth > -- kind regards, David Sommerseth
RE: BTRFS
Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one prototype of our system running it (most of our productions are still running older openSUSE on ext4). We are considering switching to Scientific Linux, but the btrfs question remains. The prototype is doing fine so far, but what we are really interested in with BTRFS is RAID and compression (not tried yet). The new openSUSE release from yesterday (apparently no longer called "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) as upstream, while keeping btrfs as default, and I don't know if that means SLES (a major enterprise distro) also considers BTRFS mature. If you recommend not using BTRFS in Scientific Linux until Red Hat makes a major release of it, that could mean 3 years of waiting given their release life cycle. I am no longer sure which way to go… Benjamin Lefoul nWISE AB From: David Sommerseth [sl+us...@lists.topphemmelig.net] Sent: Thursday, November 05, 2015 11:54 AM To: Benjamin Lefoul; scientific-linux-users@fnal.gov Subject: Re: BTRFS On 05/11/15 09:38, Benjamin Lefoul wrote: > Hi, > > If the btrfs filesystem on SL7 mature enough for a production environment? > According to Sanders van Vugt it was not even available in RHEL 7.0, but will > be (is?) in updates… I would claim that btrfs is NOT ready for primetime production where your data is precious. If your intention is to use it on systems where you have good backups to get acquainted with it, test it in a broader scale and do bug reporting, then it is probably fine. Btrfs have also been a topic on a few conferences I've been on over the years (like devconf.cz), and file system developers doing btrfs presentations have often said that btrfs still needs to be treated carefully. It just takes time to develop and mature an advanced file system. In addition I would also say that once RHEL puts it in a release ready for production, that's the point where you can begin to have real confidence in the file system. Currently I believe it is only available as a technology preview. More on technology preview can be found here: <https://access.redhat.com/support/offerings/techpreview> On the other hand, I am conservative and very careful when it comes to data integrity. -- kind regards, David Sommerseth
Re: BTRFS
On 5 November 2015 at 04:52, Benjamin Lefoul <benjamin.lef...@nwise.se> wrote: > Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one prototype of > our system running it (most of our productions are still running older > openSUSE on ext4). > There are several caveats to that. 1) They only use it by default in certain filesystems and recommend against it on others. 2) When they started the version they enable has a lot of "features" turned off because they are not stable enough. So people were raving about btfrs and then finding out that various things they were hoping btrfs was doing wasn't on. This has changed over time so I don't know the current feature set. > We are considering switching to Scientific Linux, but the btrfs question > remains. The prototype is doing fine so far, but what we are really > interested in with BTRFS is RAID and compression (not tried yet). > > The new openSUSE release from yesterday (apparently no longer called > "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) as > upstream, while keeping btrfs as default, and I don't know if that means SLES > (a major enterprise distro) also considers BTRFS mature. > As far as I know.. they consider it "mature" for an even more limited set of things than OpenSUSE does. > If you recommend not using BTRFS in Scientific Linux until Red Hat makes a > major release of it, that could mean 3 years of waiting given their release > life cycle. I am no longer sure which way to go… > > Benjamin Lefoul > nWISE AB > > > > > From: David Sommerseth [sl+us...@lists.topphemmelig.net] > Sent: Thursday, November 05, 2015 11:54 AM > To: Benjamin Lefoul; scientific-linux-users@fnal.gov > Subject: Re: BTRFS > > On 05/11/15 09:38, Benjamin Lefoul wrote: >> Hi, >> >> If the btrfs filesystem on SL7 mature enough for a production environment? >> According to Sanders van Vugt it was not even available in RHEL 7.0, but >> will be (is?) in updates… > > I would claim that btrfs is NOT ready for primetime production where > your data is precious. If your intention is to use it on systems where > you have good backups to get acquainted with it, test it in a broader > scale and do bug reporting, then it is probably fine. > > Btrfs have also been a topic on a few conferences I've been on over the > years (like devconf.cz), and file system developers doing btrfs > presentations have often said that btrfs still needs to be treated > carefully. It just takes time to develop and mature an advanced file > system. > > In addition I would also say that once RHEL puts it in a release ready > for production, that's the point where you can begin to have real > confidence in the file system. Currently I believe it is only available > as a technology preview. More on technology preview can be found here: > <https://access.redhat.com/support/offerings/techpreview> > > On the other hand, I am conservative and very careful when it comes to > data integrity. > > > -- > kind regards, > > David Sommerseth -- Stephen J Smoogen.
RE: BTRFS
Benjamin, If you have not already considered it I would encourage you to check out ZFS on Linux. ZFS was the predecessor and inspiration to BTRFS and is now very readily available and stable/supported by the Linux community in general via each specific distro that includes it and the ZOL/OpenZFS projects. regards, Chris From: owner-scientific-linux-us...@listserv.fnal.gov [owner-scientific-linux-us...@listserv.fnal.gov] on behalf of Benjamin Lefoul [benjamin.lef...@nwise.se] Sent: Thursday, November 05, 2015 7:40 AM To: scientific-linux-users@fnal.gov Subject: RE: BTRFS Thank you all for your input and links! I does sound like mdadm and LVM are still safer. Transparent data compression will have to wait a few years, but at least the future looks promising. Regards, Benjamin Lefoul nWISE AB From: David Sommerseth [sl+us...@lists.topphemmelig.net] Sent: Thursday, November 05, 2015 1:53 PM To: Benjamin Lefoul Subject: Re: BTRFS On 05/11/15 12:52, Benjamin Lefoul wrote: > Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one > prototype of our system running it (most of our productions are still > running older openSUSE on ext4). > > We are considering switching to Scientific Linux, but the btrfs > question remains. The prototype is doing fine so far, but what we are > really interested in with BTRFS is RAID and compression (not tried yet). > > The new openSUSE release from yesterday (apparently no longer called > "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) > as upstream, while keeping btrfs as default, and I don't know if that > means SLES (a major enterprise distro) also considers BTRFS mature. > > If you recommend not using BTRFS in Scientific Linux until Red Hat > makes a major release of it, that could mean 3 years of waiting given > their release life cycle. I am no longer sure which way to go… AFAIK, the btrfs support in openSUSE is fairly restricted in the supported feature sets. So the gap between btrfs and what you can do with mdraid + LVM + XFS is fairly small. I didn't find an updated comparison table, but this is from an offical SUSE resource: <https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_576280_=CwIF-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=k6oKZI9weMoc8LXiW22fgCr4b3qBxTlgzDRcLcUS7m4=kBlNY8Gn-WAXKYx_OpqjDsSePgzY8F0JE8G3K_1YHtI=TDNJptlfLmQuwm4p4i73cZZYR6HxB3aeiB3DwiH9xkY= > Btrfs does indeed have a lot of great things, and everyone wants it to be ready yesterday. But unfortunately, it just takes time to make it enterprise ready. On the other hand, there are many users of btrfs, even the Jolla phone ships with btrfs. But what makes it harder with btrfs than, say ext4 or xfs, is that it supports so much more than a traditional file system. So you do need to consider which features have been used and configured. Some areas of btrfs is probably very solid and stable, but in the moment you add one more advanced feature - you can just as well happen to enter unstable ground again. I'd probably recommend to dig deeper into the LWN.net archives, there is a lot of good articles and comments there as well on the file system stuff. Otherwise, here is one of the later presentations I could find on file systems from a Red Hat engineer: <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3D83L9d2EyBco=CwIF-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=k6oKZI9weMoc8LXiW22fgCr4b3qBxTlgzDRcLcUS7m4=kBlNY8Gn-WAXKYx_OpqjDsSePgzY8F0JE8G3K_1YHtI=hOGbNuNSSTsiKtz9LzQX-mej9VOls-8nR7Rn2bJbLGk= > -- kind regards, David Sommerseth > > From: David Sommerseth [sl+us...@lists.topphemmelig.net] > Sent: Thursday, November 05, 2015 11:54 AM > To: Benjamin Lefoul; scientific-linux-users@fnal.gov > Subject: Re: BTRFS > > On 05/11/15 09:38, Benjamin Lefoul wrote: >> Hi, >> >> If the btrfs filesystem on SL7 mature enough for a production environment? >> According to Sanders van Vugt it was not even available in RHEL 7.0, but >> will be (is?) in updates… > > I would claim that btrfs is NOT ready for primetime production where > your data is precious. If your intention is to use it on systems where > you have good backups to get acquainted with it, test it in a broader > scale and do bug reporting, then it is probably fine. > > Btrfs have also been a topic on a few conferences I've been on over the > years (like devconf.cz), and file system developers doing btrfs > presentations have often said that btrfs still needs to be treated > carefully. It just takes time to develop and mature an advanced file > system. > > In addition I would also say that once RHEL puts it in a release ready > for production, that's the
RE: BTRFS
Thank you all for your input and links! I does sound like mdadm and LVM are still safer. Transparent data compression will have to wait a few years, but at least the future looks promising. Regards, Benjamin Lefoul nWISE AB From: David Sommerseth [sl+us...@lists.topphemmelig.net] Sent: Thursday, November 05, 2015 1:53 PM To: Benjamin Lefoul Subject: Re: BTRFS On 05/11/15 12:52, Benjamin Lefoul wrote: > Thanks. OpenSUSE 13.2 uses btrfs as default (!!) and we have one > prototype of our system running it (most of our productions are still > running older openSUSE on ext4). > > We are considering switching to Scientific Linux, but the btrfs > question remains. The prototype is doing fine so far, but what we are > really interested in with BTRFS is RAID and compression (not tried yet). > > The new openSUSE release from yesterday (apparently no longer called > "openSUSE" but "Leap") decided to use SLES (SUSE Linux Enterprise Linux) > as upstream, while keeping btrfs as default, and I don't know if that > means SLES (a major enterprise distro) also considers BTRFS mature. > > If you recommend not using BTRFS in Scientific Linux until Red Hat > makes a major release of it, that could mean 3 years of waiting given > their release life cycle. I am no longer sure which way to go… AFAIK, the btrfs support in openSUSE is fairly restricted in the supported feature sets. So the gap between btrfs and what you can do with mdraid + LVM + XFS is fairly small. I didn't find an updated comparison table, but this is from an offical SUSE resource: <https://lwn.net/Articles/576280/> Btrfs does indeed have a lot of great things, and everyone wants it to be ready yesterday. But unfortunately, it just takes time to make it enterprise ready. On the other hand, there are many users of btrfs, even the Jolla phone ships with btrfs. But what makes it harder with btrfs than, say ext4 or xfs, is that it supports so much more than a traditional file system. So you do need to consider which features have been used and configured. Some areas of btrfs is probably very solid and stable, but in the moment you add one more advanced feature - you can just as well happen to enter unstable ground again. I'd probably recommend to dig deeper into the LWN.net archives, there is a lot of good articles and comments there as well on the file system stuff. Otherwise, here is one of the later presentations I could find on file systems from a Red Hat engineer: <https://www.youtube.com/watch?v=83L9d2EyBco> -- kind regards, David Sommerseth > > From: David Sommerseth [sl+us...@lists.topphemmelig.net] > Sent: Thursday, November 05, 2015 11:54 AM > To: Benjamin Lefoul; scientific-linux-users@fnal.gov > Subject: Re: BTRFS > > On 05/11/15 09:38, Benjamin Lefoul wrote: >> Hi, >> >> If the btrfs filesystem on SL7 mature enough for a production environment? >> According to Sanders van Vugt it was not even available in RHEL 7.0, but >> will be (is?) in updates… > > I would claim that btrfs is NOT ready for primetime production where > your data is precious. If your intention is to use it on systems where > you have good backups to get acquainted with it, test it in a broader > scale and do bug reporting, then it is probably fine. > > Btrfs have also been a topic on a few conferences I've been on over the > years (like devconf.cz), and file system developers doing btrfs > presentations have often said that btrfs still needs to be treated > carefully. It just takes time to develop and mature an advanced file > system. > > In addition I would also say that once RHEL puts it in a release ready > for production, that's the point where you can begin to have real > confidence in the file system. Currently I believe it is only available > as a technology preview. More on technology preview can be found here: > <https://access.redhat.com/support/offerings/techpreview> > > On the other hand, I am conservative and very careful when it comes to > data integrity. > > > -- > kind regards, > > David Sommerseth > -- kind regards, David Sommerseth
