dump and duid

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

dump and duid

Jan Stary
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?

        Jan

Reply | Threaded
Open this post in threaded view
|

Re: dump and duid

Clint Pachl
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.

Reply | Threaded
Open this post in threaded view
|

Re: dump and duid

Philip Guenther-2
In reply to this post by Jan Stary
On Fri, Feb 27, 2015 at 5:09 AM, Jan Stary <[hidden email]> wrote:

> 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:
...
> 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?

It sounds like you should start using the -U option on dump starting
with your next level zero for each disk.

I wonder if it could be made the default by first searching for an
entry with DUID and lower dump level, and falling back to a device
name entry if no matching DUID entry was found or if they were just
for higher dump levels. Once you do a level zero for a DUID it'll
never look for a device entry again, but during the transition I think
that strategy would find the same device entries that it would
otherwise have found.


Philip Guenther