rsync generates "Invalid argument (22)" when transferring certain files

[Daniel Robert]

We have a HP-UX server that periodically updates a Linux server which acts like a virtual tape server. We transfer everything (except databases) and when it comes to _certain_ files, the following error occurs:
rsync: mknod "/rsync/Apr28/dev/root" failed: Invalid argument (22)
Here is a list of some of the files that cause the errors:
/dev/root
/dev/rroot
/dev/ptym/clone
/dev/rmt/stape_config

The error seems to occur on Block and Character special files. I searched the Internet and was able to find that error, but it was a bug in rsync where when it was transferring sockets, a function was called with too few parameters and caused this error. This may be a similar problem, but they are not occurring on sockets.

The rsync version on the HP-UX 11i is 3.0.6 (I even tried 3.0.7 from our test server and got the same thing) and 3.0.4 on the Linux box.

I can exclude these files, but I think this is a bug and may need fixing and I also don't want to have to maintain the exclusion list every time one of these files cause a problem. The way our synchronization works is that it does it silently and only reports when there are errors. In this situation, it always reports errors.

I am aware that HP does not maintain rsync, but I was hoping if anyone has come across this and what the solution was (patch?).

[Vivek_Pendse]

Hi,

Can you paste the exact syntax, which you have used while copying.

Thanks,
Vivek

[Daniel Robert]

rsync -avz -stats --progress --delete-excluded --itemize-changes --numeric-ids -e/usr/bin/ssh --hard-links --link-dest=/rsync/Apr27 --exclude-from=/usr/rsync/config/backup.exc / backup:/rsync/Apr28

the backup.exc file contains directories which contain database files.

[Matti_Kurkela]

Linux follows the traditional Unix practice of having the device node minor and major numbers be (unsigned) 8-bit values, while HP-UX has extended the minor number to 3 bytes (0xNNNNNN).

Because of this, it will be impossible to reproduce at least some HP-UX device nodes in Linux at the filesystem level.

The rsync utility may be able to reproduce the devices with minor numbers between 0..255 (0x000000..0x0000ff). But larger values won't fit into Linux/x86 dev_t data type definition, so Linux mknod() system call cannot accept them.

(On 64-bit hardware architectures like Alpha and Itanium, Linux seems to use a bigger dev_t. But one of the selling points of x86_64 is the seamless compatibility with 32-bit x86 code, so the x86_64 apparently has the same restriction as its 32-bit precedessor.)

In general, copying device nodes from one OS to another is somewhat risky: as each OS interprets the minor & major numbers in its own way, a device node that is a harmless /dev/urandom with permissions 666 on its native architecture may be something completely different (and not so harmless) on another architecture. The name of the device node is just a human-comfort string with no meaning for the kernel: the minor & major numbers determine what the device node actually does.

If you want to keep using your scheme, you should use something like tar or pax to package the entire /dev directory hierarchy and backup the resulting file. Any changes in HP-UX /dev are usually accompanied by corresponding hardware configuration changes, so just restoring an old /dev backup without paying attention to hardware configuration might be unwise.

MK

[Daniel Robert]

Thanks Matti, that makes total sense and explains why most block and character files were transfered properly.

The suggestion to tar the /dev directory then rsync the tar is a _great_ idea and I will implement that.

Thanks again for the prompt response.