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