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: Fri, 02 Mar 2012 06:50:41 -0500 [thread overview]
Message-ID: <jiqc6i$e2$1@dough.gmane.org> (raw)
In-Reply-To: <20120226110044.GA18898@carfax.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
On 12-02-26 06:00 AM, Hugo Mills wrote:
>
> The option that nobody's mentioned yet is to use mixed mode. This
> is the -M or --mixed option when you create the filesystem. It's
> designed specifically for small filesystems, and removes the
> data/metadata split for more efficient packing.
Cool.
> As mentioned before, you probably need to upgrade to 3.2 or 3.3-rc5
> anyway. There were quite a few fixes in the ENOSPC/allocation area
> since then.
I've upgraded to the Ubuntu Precise kernel which looks to be 3.2.6 with
btrfs-tools 0.19+20100601-3ubuntu3 so that would look like a btrfs-progs
snapshot from 2010-06-01 and (unsurprisingly) I don't see the -M option
in mkfs.btrfs.
So I went digging and I just wanted to verify what I think I am seeing.
Looking at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=67377734fd24c32cbdfeb697c2e2bd7fed519e75
it would appear that the mixed data+metadata code landed in the kernel
back in Sep, of 2010, is that correct?
And looking at
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=commit;h=b8802ae3fa0c70d4cfc3287ed07479925973b0ac
the userspace support for this landed in Dec. of 2010, is that right?
If my archeology is correct, then I only need to update my btrfs-tools,
yes? Is 2010-06-01 really the last time the tools were considered
stable or are Ubuntu just being conservative and/or lazy about updating?
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-03-02 11:50 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
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 [this message]
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='jiqc6i$e2$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.