On Tue, 14 Feb 2012, Andrew McGlashan wrote:
Hi,
On 14/02/2012 12:55 PM, Peter Ross wrote:
I do not have enough private data to fill a hard disk these days so it could be an option for him too.
Or slice the disks in two partitions of equal size and use them as a mirror.
With BTRFS, you can mirror content or not depending on your requirement. You can even choose to mirror some files/dirs and not others. And to make it even more versatile, you can apply different RAID versions throughout as well.
The problem for me with BTRFS is that it is too new and if you want the latest and greatest, then you always need the latest and greatest kernel -- something that doesn't sit well with me when I want systems that are as stable as possible.
It's not ready yet. I installed 3.2 (can't get terribly much more modern by installing debian kernel packages), made a several hundred gig btrfs filesystem and chucked half of several hundred gig onto it. 3 oops with btrfs traces later, I decided I'd remake the FS as ext4.
I'm sure that BTRFS time will come, but it will likely be a while for me. I like ZFS, but the licensing issues worry me, as does the "Oracle ownership" situation.
Is btrfs much better in that regard, other than having a licence that is compatible with our kernel? (ZFS already was capital F-Free if you happened to run a compatible kernel. And is developed and owned by the same people). I also worry about the really bad fragmentation of files. Sounds like a fundamental problem if you want to have writes that are friendly to SSD, you're going to have reads that are very much unfriendly to spinning rust.
It certainly seems like BTRFS is something very much to look forward to and probably shouldn't be used for any kind of critical data or systems for some time -- although Oracle has committed to using production BTRFS in OL very soon.
Gee, given the filesystem pain we already have on our rhel and oel boxen, I'm sure I'd excite my colleagues by suggesting we stick with the New Shiny! defaults! -- Tim Connors