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

Hi user

Admin Login:

Name: Why you should consider using btrfs ... like Google does.
--client lca --show lca_2015 --room OGGB_260098 9379 --force
Prev: 12 CoreOS: an introduction
Next: 12 KVM on IBM POWER8 servers

show more...

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

final audio

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:	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. markdown
Comment:	production notes

recording sheet

recording sheet

recording sheet

recording sheet

2015-01-14/11_34_16.dv Apply: 11:34:16 - 11:35:01 ( 00:00:45 ) S: 11:34:16 - E: 11:35:01 D: 00:00:45 show more...

vlc ~/Videos/veyepar/lca/lca_2015/dv/OGGB_260098/2015-01-14/11_34_16.dv :start-time=00.0 --audio-desync=0

	Raw File	Cut List
	11:34:16		seconds: 0.0 Wall: 11:34:16
Duration	00:00:45
	11:35:01		seconds: 0.0 Wall: 11:34:16
Comments:
mp4 mp4.m3u	dv.m3u	Split: Sequence:: delete

audio viz

2015-01-14/11_35_01.dv Apply: 11:35:01 - 12:21:52 ( 00:46:51 ) S: 11:35:01 - E: 12:21:52 D: 00:46:51 show more...

vlc ~/Videos/veyepar/lca/lca_2015/dv/OGGB_260098/2015-01-14/11_35_01.dv :start-time=00.0 --audio-desync=0

	Raw File	Cut List
	11:35:01		seconds: 0.0 Wall: 11:35:01
Duration	00:46:51
	12:21:52		seconds: 0.0 Wall: 11:35:01
Comments:
mp4 mp4.m3u	dv.m3u	Split: Sequence:: delete

audio viz

Rf filename:	root is .../show/dv/location/, example: 2013-03-13/13:13:30.dv
Sequence:
get this:	check and save to add this

2015-01-14/11_34_16.dv
audio viz

audio viz

2015-01-14/11_35_01.dv
audio viz

audio viz

Veyepar Video Eyeball Processor and Review