[Dev] [RFC] Tizen system rollback

Łukasz Stelmach l.stelmach at samsung.com
Mon Dec 2 15:16:20 GMT 2013

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
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".

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

>>>> 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.

Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131202/20ecd619/attachment-0001.sig>

More information about the Dev mailing list