On Fri, Feb 28, 2014 at 9:32 AM, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 02/28/2014 05:46 AM, Matthias G. Eckermann wrote:
Hello Stefan,
On 2014-02-28 T 10:48 +0100 Stefan Seyfried wrote:
Well, even Matthias probably wants to use a proven file system for backup purposes and not some bleeding edge experimental stuff ;-)
Why am I not surprised ...
My view: The standard filesystem stuff in btrfs plus the CoW functionality is damn stable, and this includes subvolumes, snapshots, and capabilities built upon.
There is other stuff, not yet mature, and Jeff Mahoney sent a nice table on this list last year where he listed the back-then valid status, see: http://lists.opensuse.org/opensuse-factory/2013-09/msg00029.html The out-of-band deduplication is meanwhile upstream, and - as based on CoW - also stable.
You really should give btrfs a try (again?) ! ;-)
Does btrfs work on filesystems larger than 15-TB yet? When I tried it last year it was totally unusable.
BTW, I've also been using rdiff-backup for a long time, if anyone's interested.
Regards, Lew
I don't know if this your problem, but 32-bit linux kernel's don't do block devices over 16 TB yet (and may never). The issue is the page cache simply doesn't support it. I happened to read a thread just yesterday that btrfs doesn't have a failsafe to refuse to try (xfs and ext4 simply refuse), so when a 32-bit kernel running btrfs hits roughly 15 TB it starts having some of the data go over 16TB and that in turn fails, potentially in fatal ways. I'm guessing it is a rollover issue and data intended for 16TB + Y, gets written to Y instead. If so, that can be a pretty fatal problem. Here's the thread from yesterday: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg31856.html Obviously, the fix is simple: add a mount check to refuse to mount if a rollover situation is going to happen. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org