[Discuss] BTRFS

David Miller david3d at gmail.com
Wed Apr 4 10:00:24 EDT 2012


On Wed, Apr 4, 2012 at 9:17 AM, Edward Ned Harvey <blu at nedharvey.com> wrote:

> Anybody using btrfs in production?  I know it says all over it, "not ready
> for production" and so forth.  But it's like dangling a big piece of candy
> in front of a child with a sticker that says "Do not eat."   ;-)
>
>
>
> I've had a somewhat bad experience, I'd like to share, and see if others
> experienced anything similar.
>
>
>
> We built a Time Machine server on Ubuntu Oneiric, using btrfs in the
> backend.  Snapshots are nice.  But the server was flaky...  I'd say approx
> once a week, I'd have to reboot the thing, because for no discernable
> reason, performance would grind to a halt, and some processes were
> unkillable, and stuff like that.  I suspected btrfs, but didn't have any
> really solid indicator.  So, as a guess... Stab in the dark...  I
> reformatted the storage ext4.  Ever since, it's been smooth sailing.  That
> was about 2-3 months ago.
>
>
>
> You might conclude that btrfs was to blame.  It's a strong possibility, but
> no guarantee.  There was one other change I made, which could also be
> influencing things.  I wrote a "shutdown -r now" cron script to run on
> Sundays.  To be fair...  I did this while we were still running btrfs, and
> it didn't seem to improve stability.  I still found that my logs indicated
> the same problems we were having before that script was created...
>  However,
> by introducing that script, the symptoms went away.  Meaning...  I only
> work
> on Mondays and Wednesdays.  So if backups are failing on Monday, users will
> complain to me.  By rebooting every Sunday, the backups are always working
> on Monday, and the users never complain.  But like I said...  By checking
> logs, that doesn't mean the problem went away, just that it went away
> enough
> for people to stop complaining.
>
>
>
> Since reformatting ext4, as far as I can tell, there are no more problems.
> So IMHO, it's a strong indicator the problem was btrfs, but it's not a 100%
> indicator.
>
>
>
> Naturally, you might expect me to remove the Sunday reboot hack.  But I'm
> not eager to do that just yet.  Given that things are working now.
>

It seems hardly fair to blame this on a file system when you're
running Ubuntu Oneiric which itself is just now in beta.  I'm not to saying
that btrfs is not to blame in this case but I don't see how you can make a
sweeping statement about the state of a file system based on an alpha or
beta release of a distribution.

I've been running btrfs on my /home file system on my laptop, also on
Ubuntu Oneiric.  I haven't seen any issues that I would blame on btrfs.
 However I'm also subscribed to the btrfs mailing list and the file system
definitely still has it's issues and rough edges and anyone who claims that
it's ready for production has their head in the sand.  I'm really surprised
that there are distro's that are willing to make it either the default or a
supported file system at this point.  Most of those distro's are using the
fact that the file system now has a fsck tool as a reason to call it ready.

One of the biggest issues that I've seen on the btrfs list is that there
seems to be situations where df reports that there is a bunch of free space
on the file system but trying to write to it returns an out of space error.
 If I recall correctly this is more likely to happen if you're using the
compression option.  But in general the file system still has issues either
reporting correct usage or there are other bugs that are causing out of
space issues well before the device is full.

So if anyone is considering running it in production I suggest that you
subscribe to the mailing list for a month or two and see if you still think
it's ready.  It is getting there and I think in another year it may be a
good option.  But I personally would avoid using it on anything critical
until then.
--
David



More information about the Discuss mailing list