Hey, > On 31 Oct 2014, at 9:58 am, Peter Ross <[email protected]> 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 _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
