Re: btrfs RAID with enterprise SATA or SAS drives

[Martin Steigerwald <Martin@xxxxxxxxxxxx>]

Am Freitag, 11. Mai 2012 schrieb Duncan:
> Daniel Pocock posted on Wed, 09 May 2012 22:01:49 +0000 as excerpted:
> > There is various information about
> > - enterprise-class drives (either SAS or just enterprise SATA)
> > - the SCSI/SAS protocols themselves vs SATA having more advanced
> > features (e.g. for dealing with error conditions)
> > than the average block device
> 
> This isn't a direct answer to that, but expressing a bit of concern
> over  the implications of your question, that you're planning on using
> btrfs in an enterprise class installation.
> 
> While various Enterprise Linux distributions do now officially
> "support"  btrfs, it's worth checking out exactly what that means in
> practice.
> 
> Meanwhile, in mainline Linux kernel terms, btrfs remains very much an 
> experimental filesystem, as expressed by the kernel config option that 
> turns btrfs on.  It's still under very intensive development, with an 
> error-fixing btrfsck only recently available and still coming with its 
> own "may make the problems worse instead of fixing them" warning.  
> Testers willing to risk the chance of data loss implied by that 
> "experimental filesystem" label should be running the latest stable 
> kernel at the oldest, and preferably the rcs by rc5 or so, as new
> kernels  continue to fix problems in older btrfs code as well as
> introduce new features and if you're running an older kernel, that
> means you're running a kernel with known problems that are fixed in
> the latest kernel.
> 
> Experimental also has implications in terms of backups.  A good
> sysadmin  always has backups, but normally, the working copy can be
> considered the primary copy, and there's backups of that.  On an
> experimental filesystem under as intense continued development as
> btrfs, by contrast, it's best to consider your btrfs copy an extra
> "throwaway" copy only intended for testing.  You still have your
> primary copy, along with all the usual backups, on something less
> experimental, since you never know when/where/ how your btrfs testing
> will screw up its copy.

Duncan, did you actually test BTRFS? Theory can´t replace real life 
experience.

>From all of my personal BTRFS installations not one has gone corrupt - and 
I have at least four, while more of them are in use at my employer. Except 
maybe a scratch data BRTFS RAID 0 over lots of SATA disks. But maybe it 
would have been fixable by btrfs-zero-log which I didn´t know of back then. 
Another one needed a btrfs-zero-log, but that was quite some time ago.

Some of the installations are in use for more than a year AFAIR.

While I would still be reluctant with deploying BTRFS for a customer for 
critical data and I think Oracle´s and SUSE´s move to support it officially 
is a bit daring, I don´t think BTRFS is in a "throwaway copy" state 
anymore.

As usual regular backups are important…

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html