Re: CUT rolling release debian BUT a cautionary comment
On Sat, Mar 07, 2015 at 12:38:53PM +0100, David Kalnischkies wrote:
> On Sat, Mar 07, 2015 at 12:56:31AM +0100, Adam Borowski wrote:
> > On Fri, Mar 06, 2015 at 03:26:32PM -0700, Paul E Condon wrote:
> > > you should have at least two computers running Debian, and be able to
> > > spend a few hours or days with one of them non-functional, for the
> > > following reason:
> >
> > Or, use btrfs. Put your / onto a subvolume named sys-current, and have the
> > following cronjob:
> > # btrfs subv snap sys-current backups/sys-`date +%Y-%m-%d`
>
> If I remember correctly btrfs mostly showed its ugly experimental
> state by being very slow which is hard to justify in an environment
> where everyone already complains how slow upgrades are in Debian.
> Hopefully its better now…
The cause is dpkg doing fsync() after each write, to placate a deficiency in
traditional filesystems: there's no way to tell them to make a barrier other
than a full fsync. This is because POSIX provides no API to do so. And
fsync isn't that bad on a simple filesystems, but horrible on ones that
provide additional guarantees.
There was some recentish work (kernel 3.5) that greatly reduced the cost of
fsync, but it's still slower than, say, ext4. Until dpkg gets filesystem
transaction support, you can wrap dpkg calls with eatmydata: the worst that
can happen is that in the case of power loss you'll have to issue a rollback
manually.
> The idea was to add some grub magic as well so that a user can easily
> pick an older snapshot if need be and then sell it big time as our
> transaction safe and backrollable apt.
On btrfs, you don't need grub for that: simply use the proper ioctls to
begin a transaction then commit it. No commit, nothing to rollback :)
However, power loss during a dpkg action is only a tiny fraction of
breakages. That apt reported success doesn't mean the system works -- it
just means this particular piece is in order. Breakages in unstable
typically happen on a different level. Thus, no one but the user knows
a failure happened, and thus there's no way to automatically label the last
snapshot as "good".
An UI would have to present the last few snapshots and provide a way to
rollback to any of them. Also, there are more reasons to rollback than a
breakage: what if the user wanted to check if gnome3 still sucks but doesn't
want to manually undo every change?
> > [2]. Besides separate /home (duh), you'll want to reduce the size of backups
> > by separating out /var/cache, make sure noatime is set, etc.
>
> I don't think /home is such a no-brainer.
[...]
> So in an ideal world /home would not be separate – or at least not if
> you keep /etc on / as well – but your data. Whatever that is…
> 'What do you mean "incompatible savefile"? That was the run of my life!'
> (insert databases, mails, websites and vdr record timers here)
I can't recall a case when I needed to rollback both. The system and
/home are pretty independent. You want to keep old versions for both, but
typical reasons are different. On /home, you pull a single file or
directory instead of rolling back everything.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
Reply to: