linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

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