Re: btrfsck does not fix

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

Chris Murphy posted on Tue, 14 Jan 2014 00:49:13 -0700 as excerpted:

> On Jan 13, 2014, at 11:03 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Chris Murphy posted on Mon, 13 Jan 2014 17:40:33 -0700 as excerpted:
>> 
>>> btrfs-image -c 9-t 4 /dev/sdX /mnt/<pathtoanothervolume+filename>
>>> 
>>> You can keep it handy in case a dev asks for it or you can attach it
>>> to a kernel.org bug report.
>> 
>> How big are they?  manpage says it's metadata only (data is zeroed),
>> so I'd guess one could expect it to be about metadata size as reported
>> by btrfs fi df?
> 
> # btrfs fi df /mnt/isos
> Metadata, DUP: total=1.00GiB, used=289.53MiB
> 
> 193M -rw-r--r--. 1 root root 193M Jan 14 00:44 sdb.img
> 
> Guess that's too big to attach to a bugzilla bug.

~ 290 MiB metadata, ~ 190 MiB btrfs-image.  So roughly 2/3 the size of 
metadata.  Metadata minus file tails (which are actually data, thus 
should be zeroed)?

Thanks.

I wonder if it compresses?

But yeah, without checking bugzie filesize caps, that eyeballs as a bit 
big.  It could be kept to be private-mailed on request, and/or stuck on a 
pastebin somewhere, however.

As long as the reporter isn't stuck on mobile with a gig-a-month data cap 
or dialup or some such...

-- 
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