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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
