This document discusses using Btrfs and Snapper to enable full system rollbacks in Linux. It describes how snapshots are automatically created to capture the state of the system before changes. Using Snapper, administrators can rollback the entire system to a previous snapshot to undo changes or revert to a known good state. The document provides examples of rolling back packages, kernels and system configuration changes while ensuring system integrity and compliance.
While probably the most prominent, Docker is not the only tool for building and managing containers. Originally meant to be a "chroot on steroids" to help debug systemd, systemd-nspawn provides a fairly uncomplicated approach to work with containers. Being part of systemd, it is available on most recent distributions out-of-the-box and requires no additional dependencies.
This deck will introduce a few concepts involved in containers and will guide you through the steps of building a container from scratch. The payload will be a simple service, which will be automatically activated by systemd when the first request arrives.
While probably the most prominent, Docker is not the only tool for building and managing containers. Originally meant to be a "chroot on steroids" to help debug systemd, systemd-nspawn provides a fairly uncomplicated approach to work with containers. Being part of systemd, it is available on most recent distributions out-of-the-box and requires no additional dependencies.
This deck will introduce a few concepts involved in containers and will guide you through the steps of building a container from scratch. The payload will be a simple service, which will be automatically activated by systemd when the first request arrives.
Most Linux distributions now feature systemd at their core. This presentation shows how to leverage it for your own services -- all the way from the most basic, two-line service configuration to advanced resource and security options.
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedAnne Nicolas
Ftrace’s most powerful feature is the function tracer (and function graph tracer which is built from it). But to have this enabled on production systems, it had to have its overhead be negligible when disabled. As the function tracer uses gcc’s profiling mechanism, which adds a call to “mcount” (or more recently fentry, don’t worry if you don’t know what this is, it will all be explained) at the start of almost all functions, it had to do something about the overhead that causes. The solution was to turn those calls into “nops” (an instruction that the CPU simply ignores). But this was no easy feat. It took a lot to come up with a solution (and also turning a few network cards into bricks). This talk will explain the history of how ftrace came about implementing the function tracer, and brought with it the possibility of static branches and soon static calls!
Steven Rostedt
Make Your Containers Faster: Linux Container Performance ToolsKernel TLV
If you look under the hood, Linux containers are just processes with some isolation features and resource quotas sprinkled on top. In this talk, we will apply modern Linux performance tools to container analysis: get high-level resource utilization on running containers with docker stats, htop, and nsenter; dig into high-CPU issues with perf; detect slow filesystem latency with BPF-based tools; and generate flame graphs of interesting event call stacks.
Sasha Goldshtein is the CTO of Sela Group, a Microsoft MVP and Regional Director, Pluralsight and O'Reilly author, and international consultant and trainer. Sasha is the author of two books and multiple online courses, and a prolific blogger. He is also an active open source contributor to projects focused on system diagnostics, performance monitoring, and tracing -- across multiple operating systems and runtimes. Sasha authored and delivered training courses on Linux performance optimization, event tracing, production debugging, mobile application development, and modern C++. Between his consulting engagements, Sasha speaks at international conferences world-wide.
You can find more details on the meetup page - https://www.meetup.com/Tel-Aviv-Yafo-Linux-Kernel-Meetup/events/245319189/
Agenda:
Have you ever wondered what happens when the kernel fires up? What is going on under the hood before init process is executed?
This talk will go into great depths explaining the entire process. From linker tricks and init sections to mounting and locating the init process to execute.
Speaker:
Boaz Taitler, experienced kernel developer.
This talk explores what has gone in so far in the Linux kernel (version 3.0 and 3.1) and which Linux distributions are deliverinbg Xen again. The otalk explores outstanding challenges and the pieces that are missing and what we can do, and what we cannot do working with Linux.
EuroBSDcon 2017 System Performance Analysis MethodologiesBrendan Gregg
keynote by Brendan Gregg. "Traditional performance monitoring makes do with vendor-supplied metrics, often involving interpretation and inference, and with numerous blind spots. Much in the field of systems performance is still living in the past: documentation, procedures, and analysis GUIs built upon the same old metrics. Modern BSD has advanced tracers and PMC tools, providing virtually endless metrics to aid performance analysis. It's time we really used them, but the problem becomes which metrics to use, and how to navigate them quickly to locate the root cause of problems.
There's a new way to approach performance analysis that can guide you through the metrics. Instead of starting with traditional metrics and figuring out their use, you start with the questions you want answered then look for metrics to answer them. Methodologies can provide these questions, as well as a starting point for analysis and guidance for locating the root cause. They also pose questions that the existing metrics may not yet answer, which may be critical in solving the toughest problems. System methodologies include the USE method, workload characterization, drill-down analysis, off-CPU analysis, chain graphs, and more.
This talk will discuss various system performance issues, and the methodologies, tools, and processes used to solve them. Many methodologies will be discussed, from the production proven to the cutting edge, along with recommendations for their implementation on BSD systems. In general, you will learn to think differently about analyzing your systems, and make better use of the modern tools that BSD provides."
Kernel Recipes 2015 - Porting Linux to a new processor architectureAnne Nicolas
Getting the Linux kernel running on a new processor architecture is a difficult process. Worse still, there is not much documentation available describing the porting process.
After spending countless hours becoming almost fluent in many of the supported architectures, I discovered that a well-defined skeleton shared by the majority of ports exists. Such a skeleton can logically be split into two parts that intersect a great deal.
The first part is the boot code, meaning the architecture-specific code that is executed from the moment the kernel takes over from the bootloader until init is finally executed. The second part concerns the architecture-specific code that is regularly executed once the booting phase has been completed and the kernel is running normally. This second part includes starting new threads, dealing with hardware interrupts or software exceptions, copying data from/to user applications, serving system calls, and so on.
In this talk I will provide an overview of the procedure, or at least one possible procedure, that can be followed when porting the Linux kernel to a new processor architecture.
Joël Porquet – Joël was a post-doc at Pierre and Marie Curie University (UPMC) where he ported Linux to TSAR, an academic processor. He is now looking for new adventures.
The latest releases of today’s popular Linux distributions include all the tools needed to do interesting things with Linux containers.
For the Makefile MicroVPS project, I set out to build a minimal virtual private server-like environment in a Linux container from scratch.
These are my requirements for the MicroVPS:
Minimal init sequence
Most of what happens in a rc.sysinit file is not needed (or wanted) in a container. However, to work like a virtual private server, the MicroVPS will need some kind of init system. The absolute minimum would be enough to start the network and at least one service.
Native network namespace
The MicroVPS will have a dedicated network namespace. It should be easy to configure.
Native package management
The package set installed in the container image will be managed using native tools like deb or rpm.
Automated build
An automated repeatable build process is a must.
Fast iteration cycle
The building and testing cycle must be fast enough not to drive me insane.
Easy management
It should be easy to distribute, monitor, and run a MicroVPS container.
In this tutorial, I will show how to use the tools included with Linux to build a virtual private server in a Linux container from scratch, using GNU Make to automate the build process.
Most Linux distributions now feature systemd at their core. This presentation shows how to leverage it for your own services -- all the way from the most basic, two-line service configuration to advanced resource and security options.
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedAnne Nicolas
Ftrace’s most powerful feature is the function tracer (and function graph tracer which is built from it). But to have this enabled on production systems, it had to have its overhead be negligible when disabled. As the function tracer uses gcc’s profiling mechanism, which adds a call to “mcount” (or more recently fentry, don’t worry if you don’t know what this is, it will all be explained) at the start of almost all functions, it had to do something about the overhead that causes. The solution was to turn those calls into “nops” (an instruction that the CPU simply ignores). But this was no easy feat. It took a lot to come up with a solution (and also turning a few network cards into bricks). This talk will explain the history of how ftrace came about implementing the function tracer, and brought with it the possibility of static branches and soon static calls!
Steven Rostedt
Make Your Containers Faster: Linux Container Performance ToolsKernel TLV
If you look under the hood, Linux containers are just processes with some isolation features and resource quotas sprinkled on top. In this talk, we will apply modern Linux performance tools to container analysis: get high-level resource utilization on running containers with docker stats, htop, and nsenter; dig into high-CPU issues with perf; detect slow filesystem latency with BPF-based tools; and generate flame graphs of interesting event call stacks.
Sasha Goldshtein is the CTO of Sela Group, a Microsoft MVP and Regional Director, Pluralsight and O'Reilly author, and international consultant and trainer. Sasha is the author of two books and multiple online courses, and a prolific blogger. He is also an active open source contributor to projects focused on system diagnostics, performance monitoring, and tracing -- across multiple operating systems and runtimes. Sasha authored and delivered training courses on Linux performance optimization, event tracing, production debugging, mobile application development, and modern C++. Between his consulting engagements, Sasha speaks at international conferences world-wide.
You can find more details on the meetup page - https://www.meetup.com/Tel-Aviv-Yafo-Linux-Kernel-Meetup/events/245319189/
Agenda:
Have you ever wondered what happens when the kernel fires up? What is going on under the hood before init process is executed?
This talk will go into great depths explaining the entire process. From linker tricks and init sections to mounting and locating the init process to execute.
Speaker:
Boaz Taitler, experienced kernel developer.
This talk explores what has gone in so far in the Linux kernel (version 3.0 and 3.1) and which Linux distributions are deliverinbg Xen again. The otalk explores outstanding challenges and the pieces that are missing and what we can do, and what we cannot do working with Linux.
EuroBSDcon 2017 System Performance Analysis MethodologiesBrendan Gregg
keynote by Brendan Gregg. "Traditional performance monitoring makes do with vendor-supplied metrics, often involving interpretation and inference, and with numerous blind spots. Much in the field of systems performance is still living in the past: documentation, procedures, and analysis GUIs built upon the same old metrics. Modern BSD has advanced tracers and PMC tools, providing virtually endless metrics to aid performance analysis. It's time we really used them, but the problem becomes which metrics to use, and how to navigate them quickly to locate the root cause of problems.
There's a new way to approach performance analysis that can guide you through the metrics. Instead of starting with traditional metrics and figuring out their use, you start with the questions you want answered then look for metrics to answer them. Methodologies can provide these questions, as well as a starting point for analysis and guidance for locating the root cause. They also pose questions that the existing metrics may not yet answer, which may be critical in solving the toughest problems. System methodologies include the USE method, workload characterization, drill-down analysis, off-CPU analysis, chain graphs, and more.
This talk will discuss various system performance issues, and the methodologies, tools, and processes used to solve them. Many methodologies will be discussed, from the production proven to the cutting edge, along with recommendations for their implementation on BSD systems. In general, you will learn to think differently about analyzing your systems, and make better use of the modern tools that BSD provides."
Kernel Recipes 2015 - Porting Linux to a new processor architectureAnne Nicolas
Getting the Linux kernel running on a new processor architecture is a difficult process. Worse still, there is not much documentation available describing the porting process.
After spending countless hours becoming almost fluent in many of the supported architectures, I discovered that a well-defined skeleton shared by the majority of ports exists. Such a skeleton can logically be split into two parts that intersect a great deal.
The first part is the boot code, meaning the architecture-specific code that is executed from the moment the kernel takes over from the bootloader until init is finally executed. The second part concerns the architecture-specific code that is regularly executed once the booting phase has been completed and the kernel is running normally. This second part includes starting new threads, dealing with hardware interrupts or software exceptions, copying data from/to user applications, serving system calls, and so on.
In this talk I will provide an overview of the procedure, or at least one possible procedure, that can be followed when porting the Linux kernel to a new processor architecture.
Joël Porquet – Joël was a post-doc at Pierre and Marie Curie University (UPMC) where he ported Linux to TSAR, an academic processor. He is now looking for new adventures.
The latest releases of today’s popular Linux distributions include all the tools needed to do interesting things with Linux containers.
For the Makefile MicroVPS project, I set out to build a minimal virtual private server-like environment in a Linux container from scratch.
These are my requirements for the MicroVPS:
Minimal init sequence
Most of what happens in a rc.sysinit file is not needed (or wanted) in a container. However, to work like a virtual private server, the MicroVPS will need some kind of init system. The absolute minimum would be enough to start the network and at least one service.
Native network namespace
The MicroVPS will have a dedicated network namespace. It should be easy to configure.
Native package management
The package set installed in the container image will be managed using native tools like deb or rpm.
Automated build
An automated repeatable build process is a must.
Fast iteration cycle
The building and testing cycle must be fast enough not to drive me insane.
Easy management
It should be easy to distribute, monitor, and run a MicroVPS container.
In this tutorial, I will show how to use the tools included with Linux to build a virtual private server in a Linux container from scratch, using GNU Make to automate the build process.
Thousands of running services on hundreds of machines ask the admins to pay attention. At all times, on all channels, with all available software packages that openSUSE has to offer.
Lars does not only keep an eye on all devices inside SUSE R&D, he is also maintaining some of the biggest packages in the server:monitoring repository like Nagios, Icinga, Shinken, check_mk, mod_gearman, Naemon, PNP4Nagios or the monitoring-plugins (and others).
The integration of some of those packages into a complex, secure and high available monitoring setup together with some tips and tricks and insights into the SUSE R&D infrastructure will be demonstrated.
The guide for Python Control Developers, Control Systems sciencists or engineers. Python is a very flexible language for software engineers, simulation engineers, sciencists, control engineers. An Open Source solutions for sciencists and information engineers. This library can be installed by PIP in the Python environment.
This presentation is about a methodology which allows patching of a running Linux kernel, its technical details, limitations as well as kpatch tools.
The talk was delivered by Ruslan Bilovol (Associate Manager, Consultant, GlobalLogic) at GlobalLogic Embedded Career Day #2 on February 10, 2018.
More about GlobalLogic Embedded Career Day #2: https://www.globallogic.com/ua/events/globallogic-kyiv-embedded-career-day-2-materials
Training Slides: 203 - Backup & RecoveryContinuent
Watch this 36min training to learn about planning for backups, what some of the methods and tools are, how to restore backups and more.
TOPICS COVERED
- How to develop a backup plan
- Methods and tools for taking a backup
- Verifying the backup contains the last binary position, and the importance of this
- Restore backups into the cluster
- Provision a replica from an existing datasource
This talk is a followup to Deploying systemd at scale that was presented at systemd.conf 2016, and covers the aftermath of the migration of our fleet to CentOS 7. Now that systemd is available everywhere, we found more and more services that started adopting it for their deployment, leveraging its features and occasionally exposing interesting behaviors. At the same time, we've been able to hone our process for integrating and rolling out new versions of systemd on the fleet, and started building tooling to manage and monitor it at scale.
OpenNebulaConf 2016 - Storage Hands-on Workshop by Javier Fontán, OpenNebulaOpenNebula Project
In this 90-minute hands-on workshop, some of the key contributors to OpenNebula will walk attendees through the configuration and integration aspects of the storage subsystem in OpenNebula. The session will also include lightning talks by community members describing aspects related to Storage with OpenNebula:
Deployment scenarios
Integration
Tuning & debugging
Best practices
Kernel Recipes 2015 - Kernel dump analysisAnne Nicolas
Kernel dump analysis
Cloud this, cloud that…It’s making everything easier, especially for web hosted services. But what about the servers that are not supposed to crash ? For applications making the assumption the OS won’t do any fault or go down, what can you write in your post-mortem once the server froze and has been restarted ? How to track down the bug that lead to service unavailability ?
In this talk, we’ll see how to setup kdump and how to panic a server to generate a coredump. Once you have the vmcore file, how to track the issue with “crash” tool to find why your OS went down. Last but not least : with “crash” you can also modify your live kernel, the same way you would do with gdb.
Adrien Mahieux – System administrator obsessed with performance and uptime, tracking down microseconds from hardware to software since 2011. The application must be seen as a whole to provide efficiently the requested service. This includes searching for bottlenecks and tradeoffs, design issues or hardware optimization.
Training Slides: Basics 102: Introduction to Tungsten ClusteringContinuent
This 30 minutes training session provides an introduction to how Tungsten Clustering for MySQL / MariaDB / Percona Server works, its basic principles, understanding Tungsten Clustering topologies, failover, rolling maintenance and related tools.
AGENDA
- Review the key benefits offered by Tungsten Clustering
- Examine the Tungsten Clustering architecture
- Tungsten Cluster Topologies for MySQL High Availability and Disaster Recovery
- Composite vs Multi-Site/Multi-Master
- Review automatic and manual failover
- Explore the concepts of a rolling maintenance procedure
- Study key resources to monitor and manage the cluster
Linux Server Deep Dives (DrupalCon Amsterdam)Amin Astaneh
Over the past few years the Linux kernel has gained features that allow us to learn more about what's really happening on our servers and the applications that run on them.
This talk will explore how these new features, particularly perf_events and ebpf, enable us to answer questions about what a Drupal site is doing in real time beyond what the standard logs, server performance tools, and even strace will reveal. Attendees will be provided a brief introduction to example uses of these tools to diagnose performance problems.
This talk is intended for attendees that are familiar with Linux, the command line, and have used host observability tools in the past (top, netstat, etc).
3. 3
RAS
System
Rollback
High Availability Live Kernel
Patching
Increase Uptime
4. 4
RAS
High Availability Live Kernel
Patching
Increase Uptime
System
Rollback
5. 5
System Rollback
Reduce Operational Downtime
Goal
Go back to well-known system state
Peace of mind for
• System administrative tasks
• Package and patch installation
• System upgrades
8. 8
Demonstration #1
Using Snapshots with YaST2 snapper
# Description Tools
1 Track and visualize YaST
activities with snapper
Start YaST2
Create a new user (yast users)
Start YaST snapper
View the changes
2 Undo some of the changes Start YaST snapper
Select the snapshot pair created
by the “yast users” module
3 Install a new package by either
using YaST2 and visualize the
result using YaST2 snapper
YaST2
9. 9
Snapper Functionality
• Manage snapshots
‒ Automatically create snapshots
‒ Display differences between snapshots
‒ Roll-back
• Integration into system / systems management stack
‒ ZYpp, YUM, (apt?)
‒ LinuxPAM
• User Interfaces
‒ CLI
‒ DBUS
‒ Graphical (YaST)
‒ GUI integration (in development / GSoC)
10. 10
Introducing “Snapper” – CLI example
Snapper headers:
– Type : [ Pre | Post | Single ]
– # : Nr of snapshot
– Pre # : if type is “Post” the matching Pre nr.
– Date : timestamp
– Cleanup : cleanup algorithm for this snapshot
– Description : A fitting description of the snapshot (free
text)
– Userdata : key=value pairs to record all sorts of useful
information about the snapshot in an easily
parsable format
11. 11
Demonstration#3
Snapper Command Line
# Description Tools
1 List the currently available snapshots “snapper list ...”
2 Show differensce in the snapshot
pair created by “yast users”
“snapper status ...”
3 Show the difference only in
/etc/shadow in the snapshot pair
created by “yast users”
“snapper diff ...”
4 Undo a change remove unnecessary files in the user's home dir;
then execute “snapper undochange ...”
5 Create your own snapshot and
modify its description
“snapper create … -d <description>”
“snapper modify … <num>”
6 Add key-value pair to existing
snapshot
“snapper modify … --userdata … <num>”
7 Create your own snapshot pair “snapper create –print-number --type pre ...”
“snapper create --type post --pre-number <n1>...”
8 Change description and user data “snapper modify … <num>”
9 Rollback the full system “snapper rollback … <num> | current”
12. 12
Special Use case: Snapper and ITIL
# @Begin of implementation Change:
snapper create
--type pre
--description "ChgMgt Work order: Upgrade syslog
configuration to forward log entries to central log
server"
--userdata
"WorkOrder=201201253030000012-1,
State=InProgress,Agent=jdoe@example.com"
# @End of implementation Change:
snapper create
--type post --pre-number 240
--description "Done: ChgMgt Work order: Upgrade syslog
configuration to forward log entries to central log
server"
--userdata "WorkOrder=201201253030000012-1,
State=Closed, Agent=jdoe@example.com"
14. 14
File based Rollback
How it works
• The system uses the same instance of a subvolume:
“working instance”
• single files are copied from the snapshot to the “working
instance” – using CoW
Benefits
• Subvolumes are treated as read-only
• Subvolumes can be used for Backup
• Supports Pick and Choose
Disadvantages
• rollback not “atomic”
→ Implemented in Snapper as “undochange”
15. 15
Rollback per Subvolume
How it works
• Instead of the original subvolume, the snapshot is mounted
with the options “subvol=<name>”
‒ Remember: snapshots are subvolumes
• “btrfs subvolume set-default ...” for permanent assignments
Benefits
• “atomic” operation
• Very fast
Disadvantages
• Additional complexity
‒ Require explicit mounting of subvolumes
• No “rollback” per single file → “Full System Rollback”
→ Implemented in Snapper as “rollback”
16. 16
Snapshot/Rollback – Overview
Past & Present Present & Future
• “snapper undochange”
• Selective Rollback for
‒ Package updates
‒ Administrative changes
• No rollback of
‒ Kernel / initrd
‒ Bootloader
‒ System data, e.g. /var/log
• “snapper rollback”
• Full Rollback for
‒ Package updates
‒ Administrative changes
‒ Kernel / initrd (initramfs)
• No rollback of
‒ Bootloader
‒ Customer data: “/home”, if
on own partition (default)
‒ System data, e.g. /var/log
High Demand
17. 17
Snapshotting “/” – Challenges
• Kernel and initrd / initramfs = “/boot”
‒ Grub2 booting from a snapshot = subvolume
‒ Mark snapshots with /boot relevance as such
• System integrity and Compliance
‒ Don't allow to roll back certain log-files etc.
‒ Solution: subvolumes instead of directories for
/tmp
/opt
/srv
/var/spool
/var/log
/var/run
/var/tmp
...
18. 18
Btrfs integration with ...
• Installer
‒ Btrfs as root fs
‒ Recommendation for subvolume layout
‒ Check size of root partition
‒ Automated snapper configuration
• Partitioner
‒ Create Btrfs
‒ Create subvolumes
• Bootloader
‒ Find existing subvolumes (snapshots)
‒ Read existing subvolumes and boot from
20. 20
Full System Rollback – Use Cases
• “I have changed something, the system is still
working, but now some functionality is missing /
performance is bad / ...”
→ reset the system, reboot, enjoy!
→ “Reboot later mode”
• “Something changed, and the system is not booting
anymore” (worst case scenario)
→ need immediate reboot
→ “Reboot now mode”
21. 21
Snapshot / Rollback
Reboot Later Mode
• Administrator is in a current read-write filesystem,
but wants to rollback
• “snapper list” to view and select a snapshot
• Call
“snapper rollback <number>”
this will
● Create a new read-only snapshot of the currently running system
● Create a new read-write snapshot of the snapshot <number>,
lineary after the just recently created read-only snapshot
● “setdefault” to the new read-write snapshot
and reboot
22. 22
Snapshot / Rollback
Reboot Now Mode
• Boot into an existing read-only snapshot
• The system should work, as all variable data are on
writable subvolumes anyways.
• To continue to work in this snapshot, the admin
should call
“snapper rollback”
– this will
● Create a new read-only snapshot of the old read-write one, linearly
after the last existing one
● Create a new read-write snapshot of the snapshot you are currently
in in read-only mode, lineary after the just recently created read-only
snapshot
● “setdefault” to the new read-write snapshot
and reboot
24. 24
Snapshot / Rollback
User view on Snapshot History (1)
ro ro ro ro curr.
rw
25. 25
Snapshot / Rollback
User view on Snapshot History (2)
ro ro ro ro
curr.
rw ro
1
ro-Clone
26. 26
Snapshot / Rollback
User view on Snapshot History (3)
btrfs subvol
set-default
2 3
old
rw ro
ro ro ro new
ro rw
1
ro-Clone
rw-Clone = Rollback
27. 27
Snapshot / Rollback
User view on Snapshot History (4)
New Snapshots
ro ro ro 3 new
ro 4 rw old
rw ro 5 4
Diffs are possible
ro 6
28. 28
Snapshot / Rollback
User view on Snapshot History (5)
Condensed view What happens,
if we rollback again?
ro 3 ro 4 ro 5 ro 6
rw
Caveat: this does not reflect 1:1 what happens technically.
29. 29
Demonstration#4
Full System Rollback
# Description Tools
1 List the currently available snapshots “snapper list”
2 Install a new kernel “zypper in ...”
3 List the currently available snapshots “snapper list”
4 Show the current kernel version and reboot “uname -a ; reboot”
5 List the currently available snapshots “snapper list”
6 Rollback to the former version and reboot “snapper rollback <num> ; reboot”
7 List the currently available snapshots “snapper list”
8 Show the current kernel version “uname -a”
32. 32
System Rollback
Reduce Operational Downtime
Goal
Go back to well-known system state
Peace of mind for
• System administrative tasks
• Package and patch installation
• System upgrades
33. Thank you.
33
Go ahead, try btrfs and snapper
today!
Your questions!?
36. 36
Demonstration#2
btrfs subvols and snapshots
# Description Tools
1 List the currently available
subvolumes
“btrfs subvol ...”
2 List the currently available
subvolumes – display details about
the “parents” of the subvolumes
“btrfs subvol … -p ...”
3 Create your own subvolume
“/mydata”
“btrfs subvol ...”
37. 37
Demonstration#5
Migrating from ext3 to btrfs
# Description Tools
1 Create a logical volume or partition or loop
device. Name it “toconvert” or the like.
2 Create an ext3 filesystem on this “toconvert” and
mount it to “/toconvert”
“mkfs.ext3 -b 4096 ...”
“mkdir”, “mount”
3 Create some directories and files on “/toconvert”.
Optional: create md5 checksums
“mkdir”, “vi”
Optional: “md5sum”
4 Perform the conversion and mount the filesystem
again
“umount /toconvert”
“btrfs-convert ...
“mount ...”
5 Control, if your data are all there and check the
optional md5sums
“find”, “md5sum”, ...
6 Understand, how btrfs saves the old ext3
filesystem metadata.
“/toconvert/ext2_saved/image”
“mount -o loop ...”
38. 38
Demonstration#6
Using snapper for /home/$USER
Requirements
• /home/$USER is a btrfs subvolume
• “snapper” with DBUS interface (SLES 11 SP3,
openSUSE 12.3, ...)
• Create a snapper configuration for the user allowing
him/her to do snapshots
Additional Option
• Automated snapshotting on login/logout
• Requires small changes to the configuration of Linux
PAM (Pluggable Configuration Modules)
40. Unpublished Work of SUSE. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary and trade secret information of SUSE.
Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of
their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated,
abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE.
Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a
product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making
purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document,
and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The
development, release, and timing of features or functionality described for SUSE products remains at the sole
discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at
any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in
this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All
third-party trademarks are the property of their respective owners.