04/08/2012 06:26 PM, Daniel Baumann: > On 04/08/2012 01:19 PM, Daniel Baumann wrote: >> overlay-full, for full persistent overlays >> overlay-custom, for custom overlays >> snapshot-full, for full system snapshots >> snapshot-custom, for custom snapshots (to be implemented) > > actually, i've though a bit more about it (sorry for the mess).. > > ..why care about full and custom persistency at all? full persistency is > just a special case of custom persistency, where '/ bind' in > live.persist is used (which currently is invalid in order to not > interfere with full-ov). wouldn't that be simpler/nicer? Implemented in commit f92f379, pushed to debian-next. I actually thought about this early on during my work but decided not to because there was so many special cases to handle. As time passed it seems I have had to deal with most of them for other reasons, so now it was pretty straight-forward to implement this. > the only drawbacks qi can see are: > > * it's kind of ugly to always have a /live.persist in the root of the > overlay partition. that could be workarounded by allowing/requireing > to use /.live.persist instead (which works on fat/ntfs too, not just > on the unix/unix-like fs'es). An alternative solution (which currently works) is for the user to use an option like: source=some_subdir > * in the full persistency case, a simple mkfs -L full-ov would not > be enough, it would be a two step process to also create the config > file. personally, that wouldn't bother me. Well, the same already applies for /home. > if we'd do that, we could, fs label wise, get away with 'overlay' and > 'snapshot', both being below 11 characters, so no fallbacks for legacy > fs'es/os'es would be needed. Perhaps 'live' is good enough as a new label? I leave the naming to you. Cheers!
Description: OpenPGP digital signature