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