[Discuss] BTRFS

[david3d at gmail.com (David Miller)]

Wait it's Precise that is in beta right now...sorry for the
confusion...need more coffee.
--
David



On Wed, Apr 4, 2012 at 10:00 AM, David Miller <david3d at gmail.com> wrote:

> 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
>