> 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;
> > 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.
> >> 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.
--
Aliaksei
>
> --
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
