On persistency in newer live-boot
i've looked at the persistency stuff in newer live-boot and i propose a
few changes to naming and such. here we go..
1. partition and filesytem labels
currently, the following labels are used:
full-ov, for full persistent overlays
custom-ov, for custom overlays
live-sn, for full system snapshots
home-sn, for /home snapshots
for consistency, in parameters, variables etc. in live-*, we always sort
from left to right, means, on the left side there's always the most
generic parts and the least generic parts, the specifics, are on the
right side. therefore, using ov-custom, ov-full, etc. would be better.
for consistency, a label name should be the same regardless if it's a
label of a partition or filesystem, or a filename (with filenames being
the exception as they could also have an extension, see later).
regarding lengths, the least common demoninator wins, which is 11
characters[0] (for FAT/NTFS volume labels).
however, with 11 characters, we can't really do much nice things, and i
don't like to 'waste' the opportunity on sane systems to name things
properly just because some legacy operating systems cannot cope.
therefore, i suggest to use:
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)
on (basically all non-ms) systems where we have no 11 characters
limitation, with the following fallbacks (in the unrealistic hope that
at some point we can drop this):
ov-full, for full persistent overlays
ov-custom, for custom overlays
sn-full, for full system snapshots
sn-custom, for custom snapshots (to be implemented)
and keeping home-sn and live-sn for live-boot 3.x for backwards
compatiblity with 2.x (and removing it in 4.x).
2. filenames
assuming we'd use the suggestion from above:
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)
we would not need a <=11 characters fallback there, as the live system
is the only system reading the files, and we can assume at least VFAT
capabiltiies on other systems that try to read the files (we do the same
with filesystem.squashfs too).
eventhough, for consistency, it would be nice if the partition/fs labels
and the filenames would be identical, i wonder if it wouldn't be nicer
to prepend the filenames with a 'live-' praefix (if stored
my impression is that if i as a user get e.g. a usb stick with a live
system and persistency information on it and then put it into an already
bootet system, seeing a e.g. '/overlay-full' named file is not really
usefull for me to know that i possibly shouldn't delete it.
if it would be named '/live-overlay-full' i could at least guess that it
has something to do with the live system.
3. file location
currently, persistency information is only supported being in the top
directory of a filesystem, e.g. as '/overlay-full'.
wouldn't it be better to (either instead or in addition) to support using:
/live/filesystem.overlay-full
(and possibly 'renaming' /live/filesystem.squashfs to
/live/filesystem.root.squashfs or something like that).
4. live.persist naming
i think live.persist is awesome, but the name is a bit unfortunate.
first, we're not using abbrebviations where it's not necessary, so
live.persistent would be better.
second, we quite consistently use live-$foo, not live.$foo, so
live-persistent would be even better.
5. live.persist options
again, live.persist is really awesome, but i suggest to change the
'linkfiles' option to simply 'link' (shorter is better, the 'files' part
doesn't really gain anything).
oh, and quick question, there's something i didn't really understand:
why is that in the example of linkfiles in the manpage of live.persist,
the /home/user2/.ssh directory is created and its content symlinked,
rather than the directory as a whole being symlinked? is it because
otherwise the permissions would be to liberal (in the case of .ssh,
where you want the directory to be 0700 and the persistency possibly
could be on a FAT fs not supporting permissions)?
Sorry for the long mail and thanks a lot for all your work you've put
into the new persistency features. This truely brings the best and
better persistency implementation of any distribution to debian.
Regards,
Daniel
[0] since 'custom-ov' is already more than 8 characters, i presume that
we do not care about 8.3 compatibility in filenames.
ftr, eventhough FAT can use up to 11 characters as filename if no
extension is used, most legacy crap doesn't deal with it properly
which is why by convention rather than specification, filenames on
FAT have traditionally been restricted to 8 characters only, plus
an optional 3 characters extension.
however, even when not adhere to 8.3/FAT compatibility and presuming
that at least VFAT would be ok, since we'd like to use the same
string consistently, 11 characters it is because volume labels for
FAT and NTFS do not support more than that.
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
Reply to: