From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: 3.16 Managed to ENOSPC with <80% used
Date: Sat, 27 Sep 2014 02:36:12 +0000 (UTC) [thread overview]
Message-ID: <pan$41b80$e9472660$dc93ed19$748d19cd@cox.net> (raw)
In-Reply-To: CAGfcS_koxt3d4kBv1o+5FnpDj-6+WA6tsPbPkBdehNnWcYnaKA@mail.gmail.com
Rich Freeman posted on Fri, 26 Sep 2014 10:18:37 -0400 as excerpted:
> On Thu, Sep 25, 2014 at 5:21 PM, Holger Hoffstätte
> <holger.hoffstaette@googlemail.com> wrote:
>> That's why I mentioned adding a second device - that will immediately
>> allow cleanup with headroom. An additional 8GB tmpfs volume can works
>> wonders.
>>
>>
> If you add a single 8GB tmpfs to a RAID1 btrfs array, is it safe to
> assume that you'll still always have a redundant copy of everything on a
> disk somewhere during the recovery? Would only a single tmpfs volume
> actually help in this case? I get a bit nervous about doing a cleanup
> that involves moving metadata to tmpfs of all places, since some kind of
> deadlock/etc could result in unrecoverable data loss.
>
> Doing the same thing with an actual hard drive would concern me less.
That has been my concern too, and why I'd be leery about using a loopback
on tmpfs, even for the few minutes (more like seconds since I'm on SSD
and we /are/ talking memory-backed tmpfs) it'd take to free a minimal
number of chunks (say usage=2% or 5% or whatever, the smallest number
that actually frees anything).
With SSD and with backups I'd probably do it, but it's not something I
could recommend, and I'm not sure I'd do it on slower spinning rust, just
because the time is longer.
I'd probably use a thumb drive or the like, instead, and would certainly
recommend that to others, altho if they're comfortable with it and want
to risk it, a loopback file on tmpfs should work fine, provided the power
doesn't go out in the middle or something.
--
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:[~2014-09-27 2:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 20:43 3.16 Managed to ENOSPC with <80% used Dan Merillat
2014-09-24 22:23 ` Holger Hoffstätte
2014-09-25 21:05 ` Dan Merillat
2014-09-25 21:21 ` Holger Hoffstätte
2014-09-26 14:18 ` Rich Freeman
2014-09-27 2:36 ` 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$41b80$e9472660$dc93ed19$748d19cd@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.