veyepar: Why you should consider using btrfs ... like Google does.

Author(s):	Marc MERLIN
Location	OGGB 260-098
Date	jan Wed 14	Days Raw Files
Start	11:35	First Raw Start	11:34
Duration	0:45:00	Offset	0:00:44
End	12:20	Last Raw End	12:21
Chapters	00:00
Total cuts_time	46 min.

http://lca2015.linux.org.au/schedule/30044/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf Why_you_should_consider_using_btrfs_real_COW_snapshots_and_file_level_incremental_server_OS_upgrades_like_Google_does.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Btrfs has seen steady development over time, and is arguably the most modern filesystem available in the linux kernel. Now is time for more users to learn about it and consider using it for multiple kinds of workloads and hopefully help with its development.

The presentation will give you everything you know to get up to speed with btfrs, why you should want to trust your data to btrfs, how it offers a lot of what ZFS offers without the licensing problems, as well as best practices for using it.

I will go into: 
- the basics of administration of a btrfs filesystem 
- How btrfs, swraid, dmcrypt, and lvm fit or don't fit together 
- how to work with a single storage pool and create all your partitions from it without having to ever resize them, or require LVM as a slow and somewhat unreliable block layer. 
- how to have virtually as many snapshots as you want and why you really want this 
- how to do very efficient block level backups of changes only and much faster than rsync ever will 
- how those block backups can be used to deploy OS upgrades at the file level like I explained in my talk on how Google maintains its many servers last year.

I'll also share the simple code I wrote based around btrfs to offer netapp style snapshots as well as easy incremental block diff backups.

Comment:

production notes