Re: 40TB volume taking over 16 hours to mount, any ideas?

[Duncan <1i5t5.duncan@cox.net>]

Timofey Titovets posted on Sun, 10 Aug 2014 11:50:39 +0300 as excerpted:

> Jose, I add my 50 cents,
> i know, what you want backup data from raid through network and what you
> have only 11 TB data from 40 TB fs As i now, you can safety resize btrfs
> fs, without btrfs fi resize, something like that:
> $ btrfs fi df /
> Data, single: total=81.00GiB, used=60.33GiB
> System, DUP: total=32.00MiB, used=16.00KiB
> Metadata, DUP: total=1.50GiB, used=507.48MiB
> GlobalReserve, single: total=176.00MiB, used=0.00B
> 
> - I can cut partitions to 81+1.5+~256 = 83g and + 1G for safety = 84G.
> And my data not lost and btrfs still working after this.
> After, you can use free space on the disk, to create new fs and backup
> data to him without problems,
> Developers, please сorrect me if I'm wrong.

You're correct, but two points, plus another less related one:

1) Most critical for the OP, he has to get the filesystem mounted and 
working first, and that's proving troublesome (tho with the patches I 
mentioned it might be doable).

2) While in theory you /could/ cut your filesystem even a bit further 
than that after a balance to trim down data usage (trimming it to ~61 GB 
allocated data area from the 81 GB current), given that btrfs can 
allocate chunks but requires a balance to deallocate, and data and 
metadata chunks can only be allocated from unallocated, not switched from 
one to the other directly, it's good to keep a reasonable safety margin 
of unallocated space.

The 1 GiB of unallocated space you propose since you didn't mention a 
balance is cutting it rather close, particularly since data chunks are 
normally 1 GiB.  On a filesystem around that size I'd recommend keeping 
10 GiB or so free at least, so maybe 95 GiB minimum in the example, or 
about 75 GiB minimum if you did a data-balance first, cutting data chunk 
allocation to 61 GiB and total allocated to ~63 GiB.

On a bit over 10 TiB of usage, however, I'd suggest keeping perhaps half 
a TiB spare/unallocated, so on 11 TiB data usage and perhaps half a TiB 
of metadata usage, resizing the filesystem no smaller than say 12 TiB, 
but 15 TiB would be somewhat more comfortable.

3) But that's a lot of data in a single filesystem basket.  Balancing or 
btrfs checking simply takes a LONG time at that size, let alone backup 
and restore of the entire thing.  So I'd suggest breaking it up into 
perhaps TiB sized independent filesystems, as well, if possible.  If say 
only half of them need mounted at a time, and half of those can be read-
only mounted, then that's "only" 2-3 TiB of data to balance/check/restore 
if something goes wrong, the rest with any luck should be unaffected as 
it wasn't mounted or was read-only mounted, and 2-3 TiB will take a lot 
less time to process than 10+ TiB, for sure.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman