On Mon, 2013-12-02 at 16:21 +0100, Łukasz Stelmach wrote: > It was <2013-12-02 pon 14:11>, when Artem Bityutskiy wrote: > > On Mon, 2013-12-02 at 13:17 +0100, Łukasz Stelmach wrote: > >> >> 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". > > > > I wonder, what is the boot-loader(s) we discuss? > > We talk about "a boot-loader" ;-)
OK. Then I do not really understand the context. I thought /boot and btrfs discussion would only happen when the boot-loader is more or less defined. > > Type 2 bootloaders have own disadvantages. E.g., the FS driver teds to > > quickly get out-of-date there. There is more complexity when we consider > > corrupted FS handling. > > In case of boot-loaders this isn't that bad because you need a read-only > support and on-disk format does not change that often. This is not completely true, but let me deter from getting into this. The discussion is already happening in too many directions. One hint, though: trinity discovered many bugs in R/O mount path of stable production file-systems. > > It would be cool if the Aliaksei's architecture could be generalized so > > that it would allow for btrfs as a special case... > > This would be cool indeed. I'd really like Aliaksei to make some kind of conclusion of the discussion, and also expand on the btrfs case a little in the design document. -- Best Regards, Artem Bityutskiy _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
