linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs goes readonly + No space left on 4.3
Date: Mon, 9 May 2016 18:19:46 +0000 (UTC)	[thread overview]
Message-ID: <pan$606ae$7c2ddacd$8669ab01$40a7c124@cox.net> (raw)
In-Reply-To: 573089AD.6090108@profihost.ag

Stefan Priebe - Profihost AG posted on Mon, 09 May 2016 14:59:25 +0200 as
excerpted:

> Am 03.05.2016 um 00:05 schrieb Omar Sandoval:
>> On Fri, Apr 29, 2016 at 10:48:15PM +0200, Stefan Priebe wrote:
>>> just want to drop a note that all those ENOSPC msg are gone with v4.5
>>> and space_cache=v2. Any plans to make space_cache=v2 default?
>>>
>> Yup, we want to make space_cache=v2 the default at some point. I'm
>> running it on my own machines and testing it here at Facebook and
>> haven't run into any issues yet. Besides stability, I also want to make
>> sure there aren't any performance regressions versus the old free space
>> cache that we haven't thought about yet.
>> 
>> Thanks for trying it out :)
> 
> Can i patch v2 as a default for me? I just looked at the code but didn't
> find an easy way to make v2 the default.

Based on previous posts, space_cache=v2 will rewrite the cache to tree 
form, and it'll stay that way (thus your default) until you specifically 
use the clear-cache option.

IOW, the code detects existing v1 or v2 and continues to use it until a 
clear-cache mount and no v2 set on the mount after, to switch back to v1, 
or a space_cache=v2 to switch to it.

IOW, the space_cache option doesn't need set more than once (and for v1, 
it doesn't actually need set at all, except perhaps after a clear_cache, 
I've never specifically set space_cache here, but it's always listed in 
the mount output and /proc/self/mounts).  After that it carries on the 
way it was.

Or did you mean that you're creating enough new btrfs that using 
space_cache=v2 even once is difficult, and you'd like to patch it to use 
v2 from the get-go?  Presumably that can indeed be patched in, but not 
being a dev, even if I could figure out a patch that worked for it, 
there's a fair chance it would be more a hack than proper code.  (As an 
admin I have a patch that switches the normal relatime default to noatime, 
so I don't have to have it in all my fstab entries, etc, and it works, 
but it's clearly a hack compared to what a proper dev would code.)

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


      reply	other threads:[~2016-05-09 18:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12  7:00 btrfs goes readonly + No space left on 4.3 Stefan Priebe
2016-04-29 20:48 ` Stefan Priebe
2016-05-02 22:05   ` Omar Sandoval
2016-05-03  4:06     ` Paul Jones
2016-05-03 18:03       ` Omar Sandoval
2016-05-09 12:59     ` Stefan Priebe - Profihost AG
2016-05-09 18:19       ` Duncan [this message]

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='pan$606ae$7c2ddacd$8669ab01$40a7c124@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).