All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fahrzin Hemmati <fahhem2@gmail.com>
To: "Brian J. Murrell" <brian@interlinx.bc.ca>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: filesystem full when it's not?  out of inodes?  huh?
Date: Sat, 25 Feb 2012 20:05:13 -0800	[thread overview]
Message-ID: <4F49AF79.4020706@gmail.com> (raw)
In-Reply-To: <jicait$grq$1@dough.gmane.org>

On 2/25/2012 7:57 PM, Brian J. Murrell wrote:
> On 12-02-25 09:37 PM, Fahrzin Hemmati wrote:
>> Nope, still in heavy development, though you should upgrade to 3.2.
> I recall being told I should upgrade to 2.6.36 (or was it .37 or .38) at
> one time.  Seems like one should always upgrade.  :-/
It's a new, in-development filesystem. Until they say "It's stable, have 
fun", you should upgrade. If you follow any other filesystem before 
they've marked it stable and you'll get the same responses.
>> Also, the devs mentioned in several places it's not friendly to small
>> drives, and I'm pretty sure 5GB is considered tiny.
> But it won't ever get taken serious if it can't be used on "regular"
> filesystems.  I shouldn't have to allocate an 80G filesystem for 3G of
> data just so that the filesystem isn't "tiny".
All filesystems have their own pros and cons; btrfs, at least while 
in-development doesn't support small filesystems. Again, nobody's 
responded to the contrary, but there may be a way to changing the 
default allocation size to less than 1GB, making your use case viable. I 
recommend Google.
>> I don't think you need to separate /usr out to it's own disk. You could
>> instead create a single drive with multiple subvolumes for /, /var,
>> /usr, etc.
> The point is to separate filesystems which can easily fill with
> application data growth from filesystems that can have more fatal
> effects by being filled.
>
> That said, I don't think having /var as a subvolume in the same pool as
> / and /usr achieves that usage isolation, does it?  Isn't /var still
> allowed to consume all of the space that it, / and /usr share with them
> all being subvolumes in the same pool?
>
>> When you have Ubuntu use btrfs for /, it creates @ and @home
>> for / and /home, respectively,
> Yes, I had noticed that.  I also didn't immediately see anything that
> prevents /home from filling / as I describe above.
>
> Cheers,
> b.
>

No, at least not yet, nor am I aware of any plans for subvolume quotas, 
though I could be wrong. If you wish to use a small space for your /usr, 
you can either wait for btrfs to support your use-case (or find out how 
to change allocation size), or use another filesystem that already does.

--Farz

  reply	other threads:[~2012-02-26  4:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-26  1:55 filesystem full when it's not? out of inodes? huh? Brian J. Murrell
2012-02-26  2:10 ` Fahrzin Hemmati
2012-02-26  2:16   ` Brian J. Murrell
2012-02-26  2:37     ` Fahrzin Hemmati
2012-02-26  3:57       ` Brian J. Murrell
2012-02-26  4:05         ` Fahrzin Hemmati [this message]
2012-03-09 22:02           ` Johannes Hirte
2012-02-26  8:52       ` Duncan
2012-02-26  9:10         ` Helmut Hullen
2012-02-26  9:41           ` Duncan
2012-03-03 10:25         ` Chris Samuel
2012-02-26  5:45   ` Brian J. Murrell
2012-02-26  5:50     ` Fahrzin Hemmati
2012-02-26  6:14     ` Brian J. Murrell
2012-02-26  7:19       ` Jérôme Poulin
2012-02-26 19:43         ` Brian J. Murrell
2012-02-26 11:00   ` Hugo Mills
2012-03-02 11:50     ` Brian J. Murrell
2012-03-02 12:23       ` Fajar A. Nugraha
2012-02-26 19:37 ` Daniel Lee
2012-02-26 19:48   ` Brian J. Murrell
2012-02-26 19:52     ` Daniel Lee
2012-02-26 20:05       ` Brian J. Murrell
2012-02-26 20:25         ` Daniel Lee

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=4F49AF79.4020706@gmail.com \
    --to=fahhem2@gmail.com \
    --cc=brian@interlinx.bc.ca \
    --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.