linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Fw: Re[2]: Migration to BTRFS
@ 2019-04-29 16:18 Hendrik Friedel
  0 siblings, 0 replies; only message in thread
From: Hendrik Friedel @ 2019-04-29 16:18 UTC (permalink / raw)
  To: Austin S. Hemmelgarn, Andrei Borzenkov, linux-btrfs

Hello,
>>With "single" data profile you won't lose filesystem, but you will
>>irretrievably lose any data on the missing drive. Also "single" profile
>>does not support auto-healing (repairing of bad copy from good copy). If
>>this is acceptable to you, then yes, both variants will do what you want.
>Actually, it's a bit worse than this potentially.  You may lose individual files if you lose one disk with the proposed setup, but you may also lose _parts_ of individual files, especially if you have lots of large (>1-5GB in size) files.
You mean if parts of the files are on the failed drive, or what do you 
have in mind?

>   And on top of this, finding what data went missing will essentially require trying to read every byte of every file in the volume.
Why is that and how would it be done (scrub, I suppose?)
I am wondering, why the design of 'single' is that way? It seems to me, 
that this is unneccessarily increasing the failure probability. My 
thinking: If I have two separate file-systems, I have a FP of Z, with Z 
the probability of one drive to fail. If I one btrfs-system in single 
profile, I have a FP of Z^N, wheras it could -with a different design- 
still be Z, no?
>>As of today there is no provision for automatic mounting of incomplete
>>multi-device btrfs in degraded mode. Actually, with systemd it is flat
>>impossible to mount incomplete btrfs because standard framework only
>>proceeds to mount it after all devices have been seen.
Do you talk about the mount during boot or about mounting in general?

 > If I where you, with your use case I would consider using mhddfs
 > https://romanrm.net/mhddfs which is filesystem agnostic layer on top of 2x [-m
 > DUP, -d SINGLE] BTRFS drives. Last time I tested mhddfs (about 5+ years ago) it
 > was dead slow, but that might not be very important to you. For what it does it
 > works great!

In fact, that is what I am using today. But when using snapshots, this 
would become a bit messy (having to do the snapshot on each device 
separately, but identically.

 > remember that backup is not a backup unless it has a extra backup

I do have two backups (one offsite) of all data that is irreplacable and 
one of data that is nice to have (TV-Recordings).


Greetings,
Hendrik


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-04-29 16:18 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-29 16:18 Fw: Re[2]: Migration to BTRFS Hendrik Friedel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).