Re: OpenSuse with Btrfs (and limitations), Chris Mason describes Btrfs as "stable"
From: "Avi Miller" <avi.miller@gmail.com>
On 30 Oct 2014, at 6:33 pm, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Hi Avi,
On 30/10/2014 12:33 PM, Avi Miller wrote:
FYI, while it's not the default filesystem, you can do the same on Oracle Linux 6 and 7 when using btrfs as the root filesystem and installing yum-plugin-fs-snapshot. btrfs is available in the default Oracle Linux 7 installer as a filesystem option and if you want to install OL6 with a btrfs root, use the UEK-based boot ISO and a network install source.
I believe the point was that it was "stable" subject to some serious omissions for things you would like to do .... particularly with "receive" being "totally disallowed" ...
Yeah, not sure why SUSE chose to disallow those features. Most of those (with the exception of the truly in-development stuff like RAID5/6) are allowed and supported on Oracle Linux. We believe btrfs to be stable even with those features active.
The article also mentions some speed issues especially in relation to databases. I would be interested to know what Oracle says to databases on ZFS on Solaris - and Btrfs on Linux systems (the later not supported by Oracle yet, I believe, the first I am not sure about) I am using ZFS, and compare Btrfs to it (e.g. to use similar technologies on Linux machines). At the moment I stick with FreeBSD where I can (and can choose) because overall it makes some work easier for me while doing the same job in many cases. BTW: Oracle VM (A Xen based virtualization host) surprised me recently. The standard installation configured plain ext(ext3, I think but not sure) filesystems on a standalone server and later warned me about using it as the storage space for the VM disks (unfortunately I forgot exactly what it was, it was about "missing features" on it - and it was not the obvious about local storage which is not shared). (I have replaced it by something more bizarre so I cannot confirm details anymore, sorry) Sometimes I just write to share information;-) It was not meant to be a particular endorsement or the opposite. My gut feeling: Use Btrfs for "bread and butter" work and not if you need 101% reliability. With backups and mirrors and failovers (which may be in place anyway) you may be fine. It would work in my work environment, I reckon. I just do not get my head around why a subvolumes is called subvolume if it is (according to the FAQ) comparable to a file system - you just can have many of them in a pool. So please call it a "filesystem". It is not a volume at all. The pool is! But that may be too late to change. It is just a bit like calling a tube a wheel - but only on my bicycle. My wheel got a puncture. Can you replace it? So for "my bicycle" you have to relearn terminology - or I get a new wheel instead a new tube because you "misunderstood". Regards Peter
Hey,
On 31 Oct 2014, at 9:58 am, Peter Ross <Petros.Listig@fdrive.com.au> wrote:
The article also mentions some speed issues especially in relation to databases.
Yeah, COW filesystems in general are not great for DB performance. Or VM performance. We usually recommend disabling the COW on those files (as the DB/VM product should do some form of transaction control).
I would be interested to know what Oracle says to databases on ZFS on Solaris - and Btrfs on Linux systems (the later not supported by Oracle yet, I believe, the first I am not sure about)
We support RDBMS binaries on btrfs but not database files. We recommend Oracle ASM as the preferred database storage filesystem.
The standard installation configured plain ext(ext3, I think but not sure) filesystems on a standalone server and later warned me about using it as the storage space for the VM disks (unfortunately I forgot exactly what it was, it was about "missing features" on it - and it was not the obvious about local storage which is not shared).
Local storage on Oracle VM is ext3 because it only stores the Dom0 software. The actual VM disk storage is either on OCFS2 (on FC/iSCSI shared storage) or NFS. We require OCFS2 for its clustering capabilities. You can use extra local storage as VM disk storage on Oracle VM 3.3 now too, which is also formatted OCFS2.
My gut feeling: Use Btrfs for "bread and butter" work and not if you need 101% reliability. With backups and mirrors and failovers (which may be in place anyway) you may be fine.
Agreed. Especially tied with yum-plugin-fs-snapshot (or your distro equivalent to snapshot prior to a package/distro upgrade).
I just do not get my head around why a subvolumes is called subvolume if it is (according to the FAQ) comparable to a file system - you just can have many of them in a pool.
Because it's a subvolume. :) It's not a filesystem, because subvolumes appear in their parent volumes, but can also be mounted independently. Cheers, Avi
On Fri, 31 Oct 2014, "Peter Ross" <Petros.Listig@fdrive.com.au> wrote:
The article also mentions some speed issues especially in relation to databases.
COW filesystems use different blocks on disk every time a file is written to. For a file that is randomly written that leads to massive fragmentation which either kills linear read performance or requires online defragmentation (which hurts performance too).
I would be interested to know what Oracle says to databases on ZFS on Solaris - and Btrfs on Linux systems (the later not supported by Oracle yet, I believe, the first I am not sure about)
The same performance issues apply to BTRFS and ZFS. The significant difference is that L2ARC and ZIL can mitigate such problems - and possibly give better performance than a traditional filesystem such as XFS on a plain RAID array.
My gut feeling: Use Btrfs for "bread and butter" work and not if you need 101% reliability. With backups and mirrors and failovers (which may be in place anyway) you may be fine.
If you want good reliability then you need backups and mirrors anyway.
I just do not get my head around why a subvolumes is called subvolume if it is (according to the FAQ) comparable to a file system - you just can have many of them in a pool.
A subvolume is represented inside BTRFS in much the same way a directory. You can't mount one subvol without operating on the rest of the filesystem, so if a filesystem is corrupted such that it can only be mounted RO then that applies to all subvols. On Fri, 31 Oct 2014, Avi Miller <avi.miller@gmail.com> wrote:
Yeah, COW filesystems in general are not great for DB performance. Or VM performance. We usually recommend disabling the COW on those files (as the DB/VM product should do some form of transaction control).
I disagree. I think that it's best to have reliability features at every possible level of the stack. If you can afford the performance hit of running a database on ZFS or BTRFS then you should do it. If you are going for an all-Sun environment then the cases where the incremental cost of using COW on ZFS for a database exceed the potential benefits seem likely to be very rare. The vast majority of database installations don't require hardware that is particularly powerful by today's standards. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (3)
-
Avi Miller -
Peter Ross -
Russell Coker