[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/52432: /etc/dumpdates format egregious
Date: Thu, 27 Jul 2017 10:07:38 +0300
From: Christos Zoulas <christos%zoulas.com@localhost>
| That sounds like a nice and useful project.
Yes, I think so - what is holding it up at the minute (aside from designing
a new format for dump's data - which I would defer right now, just to avoid
the "use XML", "no use json", "no use plist", "it must be ASN1", just use
plain text... discussions - after all we can iterate that a few times, there
is not that much data to record) is that we need some kind of permanent file
system identification in *every* filesystem dump (and clones, like dump_lfs)
is capable of dumping. Neither the mount point, nor the device name
(incl the device dev_t) is suitable. It needs to reside inside the filesystem
so raw copies get the same value. Some kind of GUID is probably needed,
but it needs to be able to be retro-fitted backwards to the older filesystems
(obviously, without breaking them).
What's needed to make that happen I have not looked into yet. Once a type
and place to store it is identified (the place need not be the same for
different filesystems) then newfs (and equivs) and perhaps even dump itself,
or a new short-life utility just for the purpose, can supply the value,
for filesystems that dont already have something suitable.
| I thought that other programs in pkgsrc might consult dumpdates,
If there's anything that uses it for dump W type purposes, we can easily
keep an (essentially useless) /etc/dumpdates for that purpose, and it can
be kept as accurate (or inaccurate if you prefer) as it is now.
If there is anything there (aside from a ported dump(8)) which tries
modifying the format, or even using it to work out what would need to be
dumped, then it deserves breaking (it already is, really.)
Main Index |
Thread Index |