[kwlug-disc] BTRFS Slides

B.S. bs27975 at yahoo.ca
Sun Apr 19 12:24:58 EDT 2015


On 04/15/2015 12:14 PM, Khalid Baheyeldin wrote:
> Thanks Chris
>
> An interesting and informative presentation.
>
> Looking forward to part two.
>
> Initially, I felt that I can/should convert everything from ext* to
> btrfs. But as the presentation progressed, I felt that there are many
> caveats.

There aren't, really. Aside from the MySQL / vm one, the only one I 
would strongly recommend is to keep a separate boot partition, and that 
it be ext# (take your pick), NOT btrfs.

And with that caveat, sorry John - I think you're wrong. btrfs is for 
everyone, and just as fire and forget as ext, gaining robustness in the 
process.

> For example, one still needs LVM for swap. I avoided LVM in the past
> (not that it is bad, just another part I don't need), and don't want
> to introduce it just to get btrfs going.

This is perhaps part of the confusion. LVM doesn't come into the 
conversation. Just think of btrfs as a (more robust) ext replacement, 
and get on with your day. Nothing changes for what you would do or have 
always done for swap - separate partition of whatever size.)

RAID, LVM, etc., still ride over top of btrfs (just as it does for ext), 
and if you're dealing with such issues, not much changes. If you're not 
dealing with such issues, no need to just because of btrfs.

- for me, btrfs lets me avoid LVM entirely. As you note, giving me one 
less thing I have to have expertise in. Neither of which obviate the 
need to understand mdadm, raid, and so on.


> There is also the lack of support for higher levels of RAID, though
> RAID-1 works well.

See my btrfs replaces ext, and no more (for your own sanity), comment. 
RAID is in essence a super-filesystem beastie, and probably best treated 
as such. IMO.

> And there is fragmentation, and recommendation against btrfs for
> MySQL.

Right, but that's no different than for any other resource intensive 
beastie. You're going to customize and tweak for the requirements of 
that specific application, regardless. That btrfs may not be part of 
that equation doesn't mean you should ignore it everywhere else. e.g. 
All other partitions of an installation - except boot and swap.

> One thing you can add to the future part two is : if I am now on
> ext*, how do you convert to btrfs? Is there a migration tool to do
> that? Or you have to tar/cpio everything then copy things over? If I
> start with a full backup of the current system, what is it that I
> need to do after a restore (change file system types in
> /mount-point/etc/fstab, or there is more to it that that). How do I
> restore a system and over a btrfs-RAID configuration?

Yes, as Chris said, but I personally would recommend you not worry about 
btrfs on current installs (unless you're already LVM, zfs, raid, or 
whatever, and have cause to consider changes - if it ain't broke ... 
something else will shortly that you need to focus on). I certainly 
would want btrfs on any future installs. Avoid the need for conversions, 
and have the basis already in place to take advantage of features when 
you're ready for them.


> On Tue, Apr 14, 2015 at 12:22 AM, Chris Irwin <chris at chrisirwin.ca>
> wrote:
>
>> Hopefully everybody got some knowledge on BTRFS today. I didn't get
>> a chance to cover some topics like snapshots, gotchas, and more
>> importantly, the troubles I had (mostly self-inflicted) and how I
>> recovered from them. Maybe the latter is better left for a blog
>> post.
>>
>> Anyway, I've posted the slides (as-used) on my blog[1]. Also, I
>> believe they will be added to kwlug.org.
>>
>> 1. https://chrisirwin.ca/posts/btrfs-presentation/
>>
>> If anybody wants to try out BTRFS, I don't want to discourage you,
>> HOWEVER, I can't stress the importance of backups enough. BTRFS can
>> be treated like a "normal" filesystem, but you can experiment and
>> enable enough extra features that will quickly leave you in a bit
>> of pain.
>>
>> If there are any other questions, please post them to the list.
>> There were a lot in the meeting, and probably some we didn't get to
>> for time.
>>
>> -- Chris Irwin
>>
>> email:   chris at chrisirwin.ca xmpp:   chris at chrisirwin.ca web:
>> https://chrisirwin.ca
>>
>>
>> _______________________________________________ kwlug-disc mailing
>> list kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
>
>
>
> _______________________________________________ kwlug-disc mailing
> list kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>





More information about the kwlug-disc mailing list