[Dev] [RFC] Tizen system rollback

Aliaksei Katovich aliaksei.katovich at gmail.com
Tue Dec 3 06:58:06 GMT 2013


hi;

> It was <2013-12-02 pon 14:36>, when Aliaksei Katovich wrote:
> >> It was <2013-12-02 pon 12:35>, when Aliaksei Katovich wrote:
> >> > hi Łukasz;
> >>>
> >>>> It was <2013-11-29 pią 16:07>, when Aliaksei Katovich wrote:
> >>>>> hi all;
> >>>>>
> >>>>> 	I would like to bring to your attention Tizen system rollback feature.
> >>>>> 	The idea is to provide possibility to roll back Tizen based system to
> >>>>> 	one of several known working configurations. Most obvious use-cases are:
> >>>>>
> >>>>> 	* system update or upgrade failed;
> >>>>> 	* there are regressions introduced by system update;
> >>>>> 	* User does not like features added by system update;
> >>>>> 	* User wants to restore device to first time configuration;
> >>>>> 	* User wants to restore device to factory defaults.
> >>>>>
> >>>>> 	Proposed architecture is based on device-mapper thin-provisioning
> >>>>> 	capabilities. Please find more details in attached document.
> >>>>>
> >>>>> 	Before starting actual implementation of this feature I would like to
> >>>>> 	hear your opinion about presented architecture and the idea in general.
> >>>> 
> >>>> I am not sure if btrfs' "file-system specific" (p. 6) is a falw. Tight
> >>>
> >>> Maybe it is not, but what to do with single-device-many-filesystems
> >>> setup?
> >> 
> >> What do you mean?
> >
> > 	I mean that you never know what kind of preferences other vendors
> > 	might have, e.g. something as crazy as this can pretty much exist:
> >
> > 	platform -> ext4
> > 	data -> btrfs
> > 	ums -> vfat;
> 
> If you use vfat then you probably do it for a reason that excludes
> device-mapper and rolback anyway. ext4 and btrfs see below.
>
> >>> I am trying to be as generic as possible with rollbacks that's why
> >>> block device level was so attractive to start with. Especially if we
> >>> think of Tizen as of being not just mobile platform.
> >> 
> >> As much as I like generic solutions, in situations like this I ask
> >> myself: is there any reason (probably outside of the socpe of my
> >> solution) not to use a "specific" solution instead of a "generic" one?
> >
> > I asked this question myself too and the answer was "yes, there is
> > reason: Tizen is Open Source platform and will be used by different
> > vendors with different file system selections so it would be easier
> > instead of maintaining N rollback implementations just offer generic
> > one".
> >
> > There always be pros and cons however.
> >
> >> Is there anything in btrfs (probably its "experimentality", its
> >> performance) that should prevent us from adopting it on all Tizen
> >> devices.
> >
> > We cannot enforce filesystem choice on other Tizen users.
> 
> I consider it to be dabatable. At least for certain features.  The
> device-mapper also incurs a performance/resource hit, so someone may

	Agreed, but it remains to be seen how big impact is.

> decide not implement rollback because of it. This is always an arbitrary
> decision. "You want rollback - you need btrfs" isn't qualitively any
> different than "you want rollback - you need dm".

	On the contrary:

	"you want less flexibility - you need btrfs" vs. "you want more
	flexibility - you need dm" makes me pondering the idea of using
	device-mapper's thin-provisioning in normal, rollback free setups.
	But, as you mentioned earlier it depends on overhead dm adds.

> To be clear, I don't want to be btrfs advocate, yet. I would like,
> however, to avoid solving everyone's problems.

	I see some irony here: looking at number of features btrfs offers
	one can conclude that it tries to do exactly what you'd like to
	avoid.

	However, I am not exempting btrfs from list of alternatives yet.
	It just placed to be second one to consider if device-mapper does
	not fly well.

> >>>> integration of snapshots with file-system code *may* (it is yet to
> >>>> be measured) bring better performance. It would also allow for
> >>>> snapshots for /boot (p. 11).
> >>>
> >>> How? Teach bootloader to deal with snapshots?
> >> 
> >> Teach it btrfs. As far as I know btrfs snapshots are simply
> >> alternative root directories (or subvolumes? Is there anyone wiser
> >> than me to help?).  All you have to do is to tell the boot-loader
> >> which one to "mount".
> >
> > Well, there are some patches for u-boot that introduce btrload
> > command. But think of other, alternative bootloaders that can be used
> > in products: they all should be maintained as well.
> 
> Worst case scenario is to provide boot-loader with a list (of lists?) of
> blocks kernel(s) occupies. LILO works this way.

--
Aliaksei

> 
> -- 
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics



> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev



More information about the Dev mailing list