linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: filesystem full when it's not?  out of inodes?  huh?
Date: Sun, 26 Feb 2012 09:41:06 +0000 (UTC)	[thread overview]
Message-ID: <pan.2012.02.26.09.41.05@cox.net> (raw)
In-Reply-To: C3b00H6y1uB@helmut.hullen.de

Helmut Hullen posted on Sun, 26 Feb 2012 10:10:00 +0100 as excerpted:

> Just take a look at Fedora.
> The maintainers had planned to use btrfs as standard filesystem for
> Fedora 16 (but haven't done so), they had planned to use btrfs for
> Fedora 17, but perhaps hesitate, see
> 
>   https://fedorahosted.org/fesco/ticket/704
> 
> There are some other distributions which also seem to (perhaps) follow
> the "bleading edge".
> 
> And therefore end users believe that using btrfs is safe.
> (I've learned my lesson ...)
> 
> Just for the record: using btrfs (when it runs stable) may reduce many
> other problems on my system. I'm still hoping.

FWIW, until a few weeks ago I had the idea based on the general Linux 
community press that btrfs was safe and basically ready, as well.  
Luckily I research such things as filesystems a bit closer than general 
community press, before I jump, tho.  I ended up at the kernel wiki, and 
read a couple weeks worth of this list before starting to respond to 
posters, mostly quoting the wiki, and posting my own thread, asking some 
questions the wiki didn't deal with.

It turns out that the raid1 features I was most interested in, at this 
point, aren't true raid1 (that is, N-way mirror, with N corresponding to 
the number of disks/SSDs), but rather, two-way-mirror only.  Either 3-way 
or N-way mirror (it was covered as 3-way, but I'm not sure if that's 3+ 
because 2-way is covered already, or 3-way only, limiting it to 2-3-way) 
is on the roadmap to be introduced after (and building on) raid5/6, which 
is on the roadmap for kernel 3.4/3.5, so that'd put 3-way-raid1 at 
3.5/3.6, probably.  So I've not even bothered trying it yet (I've 
installed btrfs-progs and have the kernel option enabled, but haven't 
actually setup any btrfs filesystems) pending that feature introduction.  
But now that I'm here on-list, I'm sticking around to track progress, and 
to help with replies, mostly quoting wiki stuff, the manpages, etc, where 
I can.

So I'm (im)patiently waiting, but it's not too bad, because already in 
the few weeks I've been on-list, I've already seen a decent number of 
fixes including the ones for small-filesystems, so I'm watching the 
filesystem gain stability and eliminate bugs "live", and I know that by 
the time multi-way raid1 is available, the filesystem will only be more 
stable and less buggy than it is now, and that's a good thing! =:^)

-- 
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:[~2012-02-26  9:41 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 [this message]
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=pan.2012.02.26.09.41.05@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).