From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: linux-btrfs@vger.kernel.org
Subject: Re: filesystem full when it's not? out of inodes? huh?
Date: Sat, 25 Feb 2012 22:57:17 -0500 [thread overview]
Message-ID: <jicait$grq$1@dough.gmane.org> (raw)
In-Reply-To: <4F499AE4.80908@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
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. :-/
> 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".
> 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-02-26 3:57 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 [this message]
2012-02-26 4:05 ` Fahrzin Hemmati
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='jicait$grq$1@dough.gmane.org' \
--to=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.