Hi, is there anything that speaks against putting a cyrus mail spool onto a btrfs subvolume?
On 09/07/2017 01:57 PM, hw wrote:> > Hi, > > is there anything that speaks against putting a cyrus mail spool onto a > btrfs subvolume? >I might be the lone voice on this, but I refuse to use btrfs for anything, much less a mail spool. I used it in production on DB and Web servers and fought corruption issues and scrubs hanging the system more times than I can count.? (This was within the last 24 months.)? I was told by certain mailing lists, that btrfs isn't considered production level.? So, I scrapped the lot, went to xfs and haven't had a problem since. I'm not sure why you'd want your mail spool on a filesystem and seems to hate being hammered with reads/writes.? Personally, on all my mail spools, I use XFS or EXT4.? OUr servers here handle 600million messages a month without trouble on those filesystems. Just my $0.02. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney at neonova.net www.neonova.net
Mark Haney wrote:> On 09/07/2017 01:57 PM, hw wrote: >> >> Hi, >> >> is there anything that speaks against putting a cyrus mail spool onto a >> btrfs subvolume? >> > I might be the lone voice on this, but I refuse to use btrfs for anything, much less a mail spool. I used it in production on DB and Web servers and fought corruption issues and scrubs hanging the system more times than I can count. (This was within the last 24 months.) I was told by certain mailing lists, that btrfs isn't considered production level. So, I scrapped the lot, went to xfs and haven't had a problem since. > > I'm not sure why you'd want your mail spool on a filesystem and seems to hate being hammered with reads/writes. Personally, on all my mail spools, I use XFS or EXT4. OUr servers here handle 600million messages a month without trouble on those filesystems. > > Just my $0.02.Btrfs appears rather useful because the disks are SSDs, because it allows me to create subvolumes and because it handles SSDs nicely. Unfortunately, the SSDs are not suited for hardware RAID. The only alternative I know is xfs or ext4 on mdadm and no subvolumes, and md RAID has severe performance penalties which I?m not willing to afford. Part of the data I plan to store on these SSDs greatly benefits from the low latency, making things about 20--30 times faster for an important application. So what should I do?
I think it depends on who you ask. Facebook and Netflix are using it extensively in production: https://www.linux.com/news/learn/intro-to-linux/how-facebook-uses-linux-and-btrfs-interview-chris-mason Though they have the in-house kernel engineering resources to troubleshoot problems. When I see quotes like this [1] on the product's WIKI: "The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes." I'm reluctant to store anything of value on it. Have you considered using ZoL? I've been using it for quite some time and haven't lost data. - Ryan http://prefetch.net [1] https://btrfs.wiki.kernel.org/index.php/RAID56 On Thu, Sep 7, 2017 at 2:12 PM, Mark Haney <mark.haney at neonova.net> wrote:> On 09/07/2017 01:57 PM, hw wrote: >> >> >> Hi, >> >> is there anything that speaks against putting a cyrus mail spool onto a >> btrfs subvolume? >> > I might be the lone voice on this, but I refuse to use btrfs for anything, > much less a mail spool. I used it in production on DB and Web servers and > fought corruption issues and scrubs hanging the system more times than I can > count. (This was within the last 24 months.) I was told by certain mailing > lists, that btrfs isn't considered production level. So, I scrapped the > lot, went to xfs and haven't had a problem since. > > I'm not sure why you'd want your mail spool on a filesystem and seems to > hate being hammered with reads/writes. Personally, on all my mail spools, I > use XFS or EXT4. OUr servers here handle 600million messages a month > without trouble on those filesystems. > > Just my $0.02. > -- > > Mark Haney > Network Engineer at NeoNova > 919-460-3330 option 1 > mark.haney at neonova.net > www.neonova.net > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos
On 09/07/2017 12:57 PM, hw wrote:> > Hi, > > is there anything that speaks against putting a cyrus mail spool onto a > btrfs subvolume?This is what Red Hat says about btrfs: The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux. The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20170908/f90545f6/attachment.sig>
Johnny Hughes wrote:> On 09/07/2017 12:57 PM, hw wrote: >> >> Hi, >> >> is there anything that speaks against putting a cyrus mail spool onto a >> btrfs subvolume? > > This is what Red Hat says about btrfs: > > The Btrfs file system has been in Technology Preview state since the > initial release of Red Hat Enterprise Linux 6. Red Hat will not be > moving Btrfs to a fully supported feature and it will be removed in a > future major release of Red Hat Enterprise Linux. > > The Btrfs file system did receive numerous updates from the upstream in > Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat > Enterprise Linux 7 series. However, this is the last planned update to > this feature.That surely speaks against it. However, it?s hard to believe. They must be expecting btrfs never to become useable.