FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-12-2010, 09:15 AM
Alexander Kahl
 
Default Adventurous yet Safety-Minded

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/11/2010 11:54 PM, Kevin Kofler wrote:
> Alexander Kahl wrote:
>> Please define "massive" if you're keeping exactly what's needed to keep
>> everything running and prune anything else by using a sophisticated,
>> tunable garbage collection mechanism.
>
> The whole point of the exercise was to do a lot of updates. But the more
> updates we do, the more disk space the old versions you're keeping around
> are going to eat up.
Again, this is where garbage collection kicks in. For any kind of
rollback system save from "guessing" the old state you'll need some kind
of recording. Nix' mechanism eats much fewer resources than e.g.
complete filesystem snapshots.

>>> and also not compliant with the FHS (Filesystem Hierarchy Standard).
>> Yep. It's much better, comparable to the GAC (global assembly cache) of
>> the CLR (Mono),
>
> Yuck! Do you seriously call that "better"?
Do you actually know the GAC, i.e. have you ever worked with it?

> Anyway, the FHS is not really negotiable.
Luckily the whole LSB is negotiable, else we'd still be sticking to this
horrible, ancient SysV init system.

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuaFE0ACgkQVTRddCFHw12VdwCgn558Jy9kMs c00dAiw6eEwvgR
N10An2joJ2y0u3cKLPjeQDx/pUjZl0vm
=pWur
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 08:14 PM
Jon Masters
 
Default Adventurous yet Safety-Minded

On Wed, 2010-03-10 at 18:22 +0530, Rahul Sundaram wrote:
> On 03/10/2010 05:36 PM, Steven I Usdansky wrote:
> > Instead of worrying about the occasional brokenness caused by an update to a stable release, how about focusing on a mechanism to easily recover from it? As long as the update hasn't corrupted any critical files, my non-optimal solution is to head over to koji, grab the last version of the broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.
> >
>
> One feature which can help
>
> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

That might be very useful for OLPC users, etc. But (and I mean this with
no disrespect to anyone else) I am not going to want to use it seriously
when it means rolling back everything that changed since installing
updates (sure, if the update is a kernel update and you literally
rebooted the second the update happened, doing nothing else - but most
updates don't bite me until I try to use some app later). I might use
something like this on a specific device, or in a specific context
(netbook with most storage online, embedded device, etc.) but not on a
server or desktop system running Fedora, even with copious additional
filesystems for /home, /whatever. I know the snapshots preserve data,
but I also know that fiddling around to see what files you need to move
around after a rollback makes this fiddly enough to not want to do it.

A better solution would be to be able to rollback individual files or
groups of files to earlier versions, like package management (or like
really treating your filesystem as some kind of git branch), but at a
different level. I'm not a btrfs expert but since it is copy on write,
one would assume that this is also technically possible - rolling back
specific files to earlier revisions if those are available, and having a
means to tag specific older versions of files other than being in a
subvol so that they will not be reclaimed and are kept on the disk. And
I would love to hear some more about whether this is possible/doable.

So anyway, I don't consider whole disk rollback a serious, and generic
solution for handling botched Fedora updates.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 09:04 PM
Chris Ball
 
Default Adventurous yet Safety-Minded

Hi,

>> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

> That might be very useful for OLPC users, etc.

(Just to be clear, my interest in writing up this feature proposal was
unrelated to my work for OLPC; the proposal is purely aimed at Fedora,
and we don't have any plans to switch to Btrfs on OLPC.)

> But (and I mean this with no disrespect to anyone else) I am not
> going to want to use it seriously when it means rolling back
> everything that changed since installing updates (sure, if the
> update is a kernel update and you literally rebooted the second
> the update happened, doing nothing else - but most updates don't
> bite me until I try to use some app later).

That's fine -- don't use it. It will offer a solution to people whose
system is hosed enough that they're willing to put up with having to
manually pick up user files that changed since the update containing
the broken packages happened, and offering a solution for that
disasterous case is better than not offering one. It makes it so
that more people can use Rawhide than would otherwise be able to.

> A better solution would be to be able to rollback individual files
> or groups of files to earlier versions

Yes, a separate piece of work would involve porting the work that Sun
did adding "Time Slider" support to Nautilus over from ZFS to Btrfs.
This allows exploring snapshots using Nautilus, and easily restoring
groups of files that way:

http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs

Btrfs snapshots work extremely similarly to ZFS snapshots (each
snapshot as a separate mount), so this work isn't very complicated,
and would be valuable: someone should do it. It's just not what
I'm interested in working on first.

- Chris.
--
Chris Ball <cjb@laptop.org>
One Laptop Per Child
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 09:18 PM
Jon Masters
 
Default Adventurous yet Safety-Minded

On Fri, 2010-03-12 at 17:04 -0500, Chris Ball wrote:

> > But (and I mean this with no disrespect to anyone else) I am not
> > going to want to use it seriously when it means rolling back
> > everything that changed since installing updates (sure, if the
> > update is a kernel update and you literally rebooted the second
> > the update happened, doing nothing else - but most updates don't
> > bite me until I try to use some app later).
>
> That's fine -- don't use it. It will offer a solution to people whose
> system is hosed enough that they're willing to put up with having to
> manually pick up user files that changed since the update containing
> the broken packages happened, and offering a solution for that
> disasterous case is better than not offering one. It makes it so
> that more people can use Rawhide than would otherwise be able to.

Absolutely. I'm not against any of this, I'm just against the suggestion
that was made that it is a solution for botched updates in general (i.e.
in released, e.g. on my future F13 stable system). It *is* a great
solution for the "OMG, I'm so hosed" like other OS's I could mention
already have, and especially if /home is on a different LV.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 08:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org