Gene Heskett wrote at 14:50 -0500 on Jan  1, 2008:
 > I just got bit by the volatile device major number getting moved
 > again, and one of the kernel developers is asking me how FreeBSD
 > users cope with this since FreeBSD's device majors are all dynamic.

Well, it's not really the major device, but the minor:

crw-r-----  1 root  operator    0,  90 Dec 22 06:34 /dev/da0s1
crw-r-----  1 root  operator    0,  92 Dec 22 06:34 /dev/da0s1a
crw-r-----  1 root  operator    0,  93 Dec 22 06:34 /dev/da0s1b
crw-r-----  1 root  operator    0,  94 Dec 22 06:34 /dev/da0s1c
crw-r-----  1 root  operator    0,  95 Dec 22 06:34 /dev/da0s1e
crw-r-----  1 root  operator    0,  96 Dec 22 06:34 /dev/da0s1f
crw-r-----  1 root  operator    0,  97 Dec 22 06:34 /dev/da0s1g
crw-r-----  1 root  operator    0,  98 Dec 22 06:34 /dev/da0s1h

But gtar uses a combination of major/minor, so this issue does, as you
say, affect FreeBSD (post 4.x).


 > So if there are any FreeBSD users running amanda here, please
 > respond and describe how you folks handle changing hardware that
 > putz's with your devices major numbers.

Generally unless you're changing hardware around, the numbers don't
change.  But if you do, you'll have the same issue that you do with
other OS's that have dynamic dev #s - it's not FreeBSD-specific, as
such.

You will either dump lots of spurious "changed" files next time you do
a time.  Or you have to fix the gnutar incremental files.  There was a
thread on -hackers recently about this.  I suggested an option,
--ignore-devno-change, that could be added to gnu tar to help with
this.  But as far as I know, no one has actually tried to implement.
Dustin has written a "fixit" script for the snapshot files that is
included in recent gtar distributions.