/dev entries

The latest bottleneck is in ascertaining the name of the disk to use for backup in /dev. The LABEL= and UUID= names don't appear to work from rc.server, and the /dev/disk? names are famously variable. For example, if someone plugged in, say, a USB drive and then plugged in the Firewire backup drive, then later removed the USB drive. Even with a predictable assignment sequence, the disk number would change.

Just as a footnote, this is something that has always driven me crazy, in UNIX, in MS-DOS, and everywhere. Why can't there be a constant mapping between a slot and a drive?

Anyway, there is a program called pdisk(1) that may work. It prints the partition table from an attached drive whether it is mounted or not, and so it will probably work from rc.server. The table it prints out is like this:


Partition map (with 512 byte blocks) on '/dev/disk1'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_Free 262144 @ 64 (128.0M)
3: Apple_HFS Untitled 104857600 @ 262208 ( 50.0G)
4: Apple_Free 262144 @ 105119808 (128.0M)
5: Apple_HFS Untitled 480690400 @ 105381952 (229.2G)
6: Apple_Free 16 @ 586072352

Device block size=512, Number of Blocks=312581808 (149.1G)
DeviceType=0x0, DeviceId=0x0


Note that while there are various useful clues, the actual volume name doesn't appear to be present. There is an option (-f) that is supposed to cause volume names to be printed, but this has no effect in early testing.

However, the swap-search example program that I found did something interesting with the output from pdisk. They used the command "md5 -q" to create a usable checksum from all of the output of pdisk except the first line (that gives the /dev name). This allows an easy way to recognize whether the appropriate disk is present and where it is in the device tree. The command they used was swaphash=`pdisk /dev/disk${swapdisk} -dump 2>/dev/null | grep -v '/dev/disk' | md5 -q`

So one way to do this would be for the scheduled script to look for the devices by their mount names /Volumes/Clone and /Volumes/Snapshots, use mount to find the current name and partition numbers, use pdisk to compute the hash, which would be stored somewhere volatile but which would not yet be cleaned up in rc.server (?) or maybe just in /etc. Then when the system is booted, a simply loop would be run to find it, it would be mounted, and the backup would proceed.

Incidently, finding a directory like /tmp or /var/??? that gets cleaned up after rc.server is finished would be a great way to pass information to the maintenance script(s), since there's no other way that the info would be there, unless it was placed there just before booting. Note that the script can't really remove it, since the boot drive is still read-only. In fact, this implies that /tmp can be used for this purpose. To be tested...

Well, I'll be testing this all out tomorrow so will report either in a comment here or in another entry.

Here is an example of finding all disks' hashes:

for x in /dev/disk[0-9] ; do /bin/echo $x `/usr/sbin/pdisk $x -dump 2>/dev/null | /usr/bin/grep -v "/dev/disk" | /sbin/md5 -q` ; done