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