Lukas Pirl posted on Fri, 30 Oct 2015 10:43:41 +1300 as excerpted:
> If there is one subvolume that contains all other (read only) snapshots
> and there is insufficient storage to copy them all separately:
> Is there an elegant way to preserve those when moving the data across
> disks?
AFAIK, no
Lukas Pirl posted on Fri, 30 Oct 2015 10:43:41 +1300 as excerpted:
> Is e.g. "balance" also influenced by the userspace tools or does
> the kernel the actual work?
btrfs balance is done "online", that is, on the (writable-)mounted
filesystem, and the kernel does the real work. It's the tools
On Fri, Oct 30, 2015 at 10:58:47AM +, Duncan wrote:
> Lukas Pirl posted on Fri, 30 Oct 2015 10:43:41 +1300 as excerpted:
>
> > If there is one subvolume that contains all other (read only) snapshots
> > and there is insufficient storage to copy them all separately:
> > Is there an elegant way
On 2015-10-30 06:58, Duncan wrote:
Lukas Pirl posted on Fri, 30 Oct 2015 10:43:41 +1300 as excerpted:
If there is one subvolume that contains all other (read only) snapshots
and there is insufficient storage to copy them all separately:
Is there an elegant way to preserve those when moving the
TL;DR: thanks but recovery still preferred over recreation.
Hello Duncan and thanks for your reply!
On 10/26/2015 09:31 PM, Duncan wrote:
FWIW... Older btrfs userspace such as your v3.17 is "OK" for normal
runtime use, assuming you don't need any newer features, as in normal
runtime, it's the
Lukas Pirl posted on Mon, 26 Oct 2015 19:19:50 +1300 as excerpted:
> TL;DR: RAID1 does not recover, I guess the interesting part in the stack
> trace is: [elided, I'm not a dev so it's little help to me]
>
> I'd appreciate some help for repairing a corrupted RAID1.
>
> Setup:
> * Linux
TL;DR: RAID1 does not recover, I guess the interesting part in the stack
trace is:
Call Trace:
[] __del_reloc_root+0x30/0x100 [btrfs]
[] free_reloc_roots+0x25/0x40 [btrfs]
[] merge_reloc_roots+0x18e/0x240 [btrfs]
[] btrfs_recover_relocation+0x374/0x420 [btrfs]
[]
