Jan Stary wrote, On 02/27/15 06:09:
This is current/amd64.
After cleaning my machine I reconnected two of my disks in reverse;
what was sd0 is sd1 now, and vice versa.
I do nightly dumps of the filesystems,
starting with level 0 on early Monday morning,
continuing with incremental 1, 2 etc through the week.
Usually this means that the Monday dump -0 is big,
and the subsequent incrementals are relatively small:
-rw------- 1 hans wheel 299G Feb 23 03:26 dump.biblio.0
-rw------- 1 hans wheel 19.7M Feb 24 01:32 dump.biblio.1
-rw------- 1 hans wheel 1.4G Feb 25 01:32 dump.biblio.2
-rw------- 1 hans wheel 674M Feb 26 01:32 dump.biblio.3
-rw------- 1 hans wheel 240G Feb 27 02:55 dump.biblio.4
-rw------- 1 hans wheel 16.7G Feb 23 01:40 dump.home.0
-rw------- 1 hans wheel 326M Feb 24 01:32 dump.home.1
-rw------- 1 hans wheel 54.5M Feb 25 01:32 dump.home.2
-rw------- 1 hans wheel 59.4M Feb 26 01:32 dump.home.3
-rw------- 1 hans wheel 52.3M Feb 27 01:32 dump.home.4
-rw------- 1 hans wheel 93.9M Feb 23 01:30 dump.root.0
-rw------- 1 hans wheel 100K Feb 24 01:30 dump.root.1
-rw------- 1 hans wheel 80.0K Feb 25 01:30 dump.root.2
-rw------- 1 hans wheel 80.0K Feb 26 01:30 dump.root.3
-rw------- 1 hans wheel 7.4M Feb 27 01:30 dump.root.4
[...]
Now, on the night after I interchanged the disks,
the dump -4 of sd1a (/biblio) is huge again; apparently,
dump -4 is dumping everything again.
Is this simply because /etc/dumpdates deals
with device names, as opposed to duids?
I ran into this quite awhile ago. My tests definitely confirm dump does
not recognize DUIDs. Many utilities have been made DUID aware, but not
dump(8). Dump reads /etc/dumpdates, which only lists device paths.
