Re: bin/52432: /etc/dumpdates format egregious

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/52432; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/52432: /etc/dumpdates format egregious
Date: Fri, 28 Jul 2017 02:27:06 +0700

     Date:        Thu, 27 Jul 2017 10:07:38 +0300
     From:        Christos Zoulas <christos%zoulas.com@localhost>
     Message-ID:  <DB18CE59-8745-4418-9DB6-8058AFE75A29%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.)
 
 kre