All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.