All of lore.kernel.org
 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 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.