On Tue, Jun 24, 2014 at 11:28 AM, <meino.cra...@gmx.de> wrote: > ...I am sure, whether I want btrfs. On the net I found > for example this: > http://www.phoronix.com/scan.php?page=news_item&px=MTY1MDU > > with sentences like: > "The Btrfs file-system changes for the Linux 3.15 kernel mostly deal > with bug fixes and performance fixes while some corruption fixes are > also expected to come." > > ...sounds a little different to "stable" I think...
I have mixed feelings regarding btrfs. For a disk that is going to be mostly offline, low-activity, long-term storage btrfs has some plusses and minuses, especially since you intend to mirror it (manually or otherwise). The only real minus is that btrfs is still fairly experimental. You could run into problems. However, what you're doing is a very simple use case and the write loads are certainly going to be quite low. Most of the scenarios that cause issues with btrfs are unlikely to come up. Btrfs has a few advantages. I'd say the biggest one is that it checksums everything and can detect silent corruption. For a disk that is just going to sit around for a long time offline that is a big plus - any other filesystem option isn't going to detect any corruption to your archive other than unreadable clusters (or disks). You could get around this by only storing data in a format that already can detect corruption, and then writing scripts to check everything, but you'll be manually copying data across your mirror if you find issues, and that will be really tricky if you're using something like mdadm since there is no easy way to pick which copy it gives you. Btrfs can also mirror your data which guarantees that all of it is replicated. Sure, rsync can do this also, but if for whatever reason something gets changed without updating mtime/ctime/size it won't spot it unless you have it set to hash everything (which is VERY slow so nobody does this). Mdadm would be a better choice, but as I pointed out it can't detect silent corruption, and is hard to recover if you discover it yourself. With btrfs everything is always mirrored (if you set that up) and a simple scrub command periodically will test to make sure everything is fine and restore anything that isn't. I have some old hard drives that I'm using for storage and I use btrfs on them. However, ultimately it isn't anything I can't afford to lose either. There is nothing wrong with ext4+rsync and maybe an occasional recursive diff. You just need to do a bit more with scripting/etc and make sure you stay on top of it, and watch out for gotchas like having the wrong disk mounted/etc. That will be less efficient than mdadm or btrfs since rsync has no idea what has changed without walking the whole tree, but it probably isn't a big deal and minus the automation is probably the most bulletproof option. Just keep in mind it is only bulletproof if you don't miss anything when you set it up - this is relying on you to manage the mirroring/etc and if you drop the ball then data will be at risk. So, I won't enthusiastically recommend btrfs, but it may be worth consideration... Rich
