On Sun, Mar 08, 2015 at 03:50:50AM +0100, Adam Borowski wrote: > 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. My memory tells me it was "plenty of small files" back then, but that could be wrong and I didn't tried it myself. I am just assuming that unsafe-io (or not) was considered as apt devs tend to have at least a bit of knowledge of how dpkg works. ;) Some years passed since then, so I would be more interested in someone actually trying it again than speculations about ifs/whys of the past. > > 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 :) You were saying how to edit the grub line, what I was saying is that if we do apt-btrfs-snapshots, we should go all the way and just provide options to boot into earlier snapshots. > 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". And? I am not sure what you are getting at given that your cron scheme is exactly the same in this regard. In fact its worse given that it bundles up all the changes of the day. After ~6 years of apt development and unstable I have to respectfully disagree with you. The breakage people are usually scared of the most is apt exiting non-zero, be it maintainerscript failure, file overwrite or our recent scarer: the omnipresent trigger loops of doom (the sequel is in the making for post-jessie release last time I heard). RPM world hasn't most of these features and hence is also able to provide filesystem-independent transactions/rollback. If we can team up with filesystem(s) to get most of it, it is good enough in my book… > 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? Well, Z20 was meant to refer to GNOME3, KDE4, <you name it> without assigning specific blame as they are not the only things which have their problems if you downgrade (they actually are nicer in this regard because so many people do it, but that doesn't mean its 100% stable). There is a reason debian packages do not support downgrades - and its not that we haven't found a filesystem with rollbacks yet. It tends to work anyhow, but in the cases it doesn't, the explosion is spectacular… The savegame joke wasn't a joke: On disk formats change all the time and they aren't always backward compatible nor are the programs always forward compatible. I mean, you know perfectly well why you are not separating /etc out in this scheme, but you really assume that the same config files in ~ are somehow magically protected from causing shenanigans? And ~ isn't just /etc but also e.g. /var/lib. As said, it tends to work anyhow, so if as a user you really have to, you can try, but I am not as sure as you seem to be that (over)selling this as an (additional) feature is a good idea. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature