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
pgpbebVNDZyEH.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
