(the Fedora development distribution) after things melted down
spectacularly back in July. Since then, problems have been scarce but all
that stability on the desktop
has proved to be seriously boring. Additionally, running a stable
distribution can make it harder to test leading-edge project releases. So
your editor has been looking to return to a development distribution on the
desktop as soon as time allows and things look safe enough. Rawhide's
worst problems are far behind it for now; it might just be safe to go back
into the water, though the beginning of the
Fedora 13 development cycle could add some excitement. As an added
incentive, the Fedora
developers now are considering mixing in Btrfs snapshots as an optional feature; use of
an experimental filesystem might not seem like the way to improve
stability, but Btrfs could, in fact, make life easier for Rawhide testers.
It is worth noting at the outset that Fedora is not, yet, considering using
Btrfs in Rawhide by default. What has been proposed,
instead, is the implementation of a "system rollback" feature for Rawhide
users who are crazy enough to install on Btrfs despite its young and
immature state. If this feature works out, it could remove much of the
risk of tracking Rawhide and begin the exploration of a new capability
which could prove highly useful for Linux users in general in the future.
One of the many features provided by Btrfs is copy-on-write snapshots. At
any time, it is possible to freeze an image of the state of the
filesystem. Snapshots are cheap - at creation time, their cost is almost
zero. As changes are made to the filesystem, copies will be made of
modified blocks while the snapshot remains unchanged. One can certainly
fill a filesystem through use of the snapshot facility - and filling Btrfs
filesystems remains a bit of a hazardous thing to do - but Btrfs will share
data between snapshots for as long as possible.
The value of snapshots to system administrators is fairly obvious: a
snapshot can be taken immediately prior to an operating system upgrade.
Should that upgrade turn out to be less of a step forward than had been
hoped, the filesystem can simply be reverted back to its pre-upgrade
state. The days of digging around for older versions of a broken packages
- perhaps with the assistance of a rescue disk - should be long gone.
That said, there are a number of details which need to be worked out before
snapshots can be made ready even for Rawhide users, much less the wider
user community. Perhaps the biggest problem is that Btrfs snapshots cover
the entire filesystem, so reverting to an older state will lose all
changes made to the filesystem in the meantime. If a system update fails
to boot, dumping the update seems like a straightforward choice - there
will be no other changes to lose. But going back to a snapshot after the
system has been running for a while could lose a fair amount of work, log
data, etc. along
with the unwelcome changes. One can always cherry-pick changed files after
reverting to the snapshot, but that would be a tedious and error-prone
There are a lot of user interface details to take care of as well. Tools
need to be created to allow administrators to look at existing snapshots,
mount them for examination, clean them up, and so on. Btrfs will probably have
to be extended with a concept of a user-selectable "default" snapshot for
each filesystem. Grub needs some work for boot-time snapshot selection.
There is also talk of eventually adding snapshot-browsing support to
Nautilus as well.
Snapshots will clearly be a useful feature for Linux in the future. Back
in your editor's system administration days, backup tapes were occasionally
used to recover from disk disasters, but much more frequently used to help
users recover from "fat-finger" incidents. Snapshots are not true backups,
but they should certainly be useful as a quick error-recovery mechanism.
Your editor is looking forward to the day when his system always supports a
series of snapshots allowing the recent state of the filesystem to be
A snapshot is a heavyweight tool for dealing with system upgrade problems,
though. In the longer term, it would make sense to have better rollback
support built into the package management system itself. Interestingly,
Yum and RPM have
had some rollback support in the past, but that feature does not seem
to be well supported now. Providing rollback support at this level is a
hard problem, to say the least, but solving that problem would put a
powerful tool into the hands of Linux system administrators.
In the absence of this feature, filesystem-level snapshots will have to do;
certainly they are a major improvement over what we have now. In the short
term, potential users should remain aware that Btrfs is a very young
filesystem, and that snapshots may not be a viable recovery mechanism if the
filesystem itself gets corrupted. In the longer term, though, there will be
a day when we will wonder how we ever used our systems without this
feature. The work being done by the Fedora developers is an important step
in that direction.
to post comments)