From: OmegaPhil <OmegaPhil@startmail.com>
To: Duncan <1i5t5.duncan@cox.net>,
linux-btrfs@vger.kernel.org, Hugo Mills <hugo@carfax.org.uk>
Subject: Re: Unable to allocate for space usage in particular btrfs volume
Date: Thu, 05 Nov 2015 10:44:51 +0000 [thread overview]
Message-ID: <563B3323.8080609@startmail.com> (raw)
In-Reply-To: <pan$b856e$b1f161a7$4a31aba1$83a27ad@cox.net>
[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]
On 05/11/15 04:18, Duncan wrote:
> OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 +0000 as excerpted:
>
>> The volume doesn't change hugely over time, so it really ought not to
>> have broken so quickly - a quick rundown of the storage usage:
>>
>> 36% general (small files, some smallish videos)
>> 24% music 23% pr0n 17% VMs
>>
>> But in terms of 'large files changing', it could be the VM disks perhaps
>> -
>> I'll move them out, balance, and then back in again, hopefully that'd be
>> a meaningful test.
>
> VM image files (and large database files, for the same reason) are a bit
> of a problem on btrfs, and indeed, any COW-based filesystem, since the
> random rewrite pattern matching that use-case is pretty much the absolute
> worst-case match for a COW-based filesystem there is.
>
> And that would be the worst-case in terms of the unsplit extents issue
> Hugo was talking about as well. So they may well be the problem, indeed.
>
> Since you're not doing snapshotting (which conflicts with this option,
> with an imperfect workaround), setting nocow on those files may well
> eliminate the problem, but be aware if you aren't already that (1) nocow
> does turn off checksumming as well, in ordered to avoid a race that could
> easily lead to data corruption, and (2) you can't just activate nocow on
> the existing file and expect it to work, the procedure is a bit more
> complicated than that, since nocow is only guaranteed to work if it's set
> at file creation. Detailed instructions for #2 skipped as they've been
> posted many times, but if you are interested and haven't seen them, ask.
Thankyou Hugo, Duncan - moving VMs out, then:
=====================================================
sudo chattr +C '/mnt/storage-1/Virtual Machines'
sudo btrfs balance start -mconvert=dup /mnt/storage-1
sudo btrfs fi defrag -rv /mnt/storage-1
=====================================================
And after moving VMs back, du reports 884GB used,
=====================================================
$ sudo btrfs fi usage /mnt/storage-1
Overall:
Device size: 953.87GiB
Device allocated: 924.07GiB
Device unallocated: 29.80GiB
Device missing: 0.00B
Used: 886.11GiB
Free (estimated): 65.72GiB (min: 50.82GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Data,single: Size:918.01GiB, Used:882.09GiB
/dev/sdb 918.01GiB
Metadata,DUP: Size:3.00GiB, Used:2.01GiB
/dev/sdb 6.00GiB
System,DUP: Size:32.00MiB, Used:128.00KiB
/dev/sdb 64.00MiB
Unallocated:
/dev/sdb 29.80GiB
=====================================================
So a couple of gig still unaccountable but irrelevant. Thanks, problem
solved! Although hopefully checksumming will be allowed on nocow files
in the future as thats currently 17% of all data unprotected and will
get worse...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-11-05 10:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 21:10 Unable to allocate for space usage in particular btrfs volume OmegaPhil
2015-11-04 21:30 ` Hugo Mills
2015-11-04 21:53 ` OmegaPhil
2015-11-05 4:18 ` Duncan
2015-11-05 10:44 ` OmegaPhil [this message]
2015-11-05 11:49 ` Hugo Mills
2015-11-06 20:15 ` Calvin Walton
2015-11-06 20:35 ` Austin S Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563B3323.8080609@startmail.com \
--to=omegaphil@startmail.com \
--cc=1i5t5.duncan@cox.net \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.