[Dev] [RFC] Tizen system rollback
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
>> 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
> 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
> 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.
Samsung R&D Institute Poland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: not available
More information about the Dev