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