Controlling network migration traffic

When migration is configured to copy files to a network storage device, rather than to optical disc or tape, it can be preferred to limit the amount of bandwidth that OSVault uses. This writeup explains how to throttle network usage by migration.
For example, if you are migrating data from a remote office to a central site, and that office has a 7MBit/second (A)DSL link, then you uplink speed would probably be around 800Kbits/second. Running a migration from that office to a central site without some throttling might make response time unacceptable for email and web browsing at that office.
To throttle a migration, there is a configuration parameter, mig_delay, stored in /etc/sysconfig/osvault/mig_delay that sets an amount of time to pause in data transfers. The pause is executed after every block of data, where the default size of a block of data is 1MByte. The vault in mig_delay in in microseconds, so putting a vault of 1,000,000 (1 million) in mig_delay would cause migration to pause for 1 second after every 1MByte (default) of data transferred.
In recent releases of migration, you can set the default data block size with the -i option to migration. So, to set migration to send 64KBytes of data, then pause for one second, you would run migration with the -i 65536 option and set /etc/sysconfig/osvault/mig_delay to 1000000.

About archives and memory resources

In some ways, archive systems are uniquely different than run of the mill NAS storage. A case in point is some observations from a recent customer installation. The customer wanted to store about 1 billion (that's 1024 million) records on Blu-Ray optical disc. The average file size was about 5Kbytes (thats right, about 5120 bytes). So, if you do simple math, you think you can store about 10 million files on a single 50GByte Blu-Ray optical disc. But you would be wrong, because you also need to store the file names on that disc and that overhead (along with other file system overhead) means you store less than 7 million files on the disk. That's quite a bit of overhead.

Now, this is an extreme example, but it shows that planning is required for many installations.

Also, some other observations are interesting. In generating the ISO9660 file system (level 4, with iso8859 character set), the system uses over 8Gbytes of system memory during that file system generation (just before the optical disc is actually burned). OSVault uses the mkisofs program, called by growisofs, to create an ISO9660 file system.

Running a directory operation on a large archive with 1.6million files in a single directory will cause the "ls" program to use 1Gbyte of memory to store the file names alphabetically.

Blu-Ray drive firmware levels

I have been running into problems with older firmware on Blu-Ray drives installed in both DISC/NSM and ASACA libraries. The problems manifest themselves in the inability of the drive to write to media from Verbatim and SONY corporation, primarily BD-RE media, and the inability to write to Panasonic BD-R media. This is firmware that is installed on Panasonic SW-5582 model Blu-ray drives. These are drives with parallel ATA interfaces, connected to SCSI thru IODATA cards.

The following firmware levels are known to work with all media we have tested so far:
BKF1 - (ASACA libraries) works with all tested media (TDK, Verbatim, Panasonic, both BD-RE and BD-R)
BKE8 -(DISC libraries) works with all tested media (TDK, Verbatim, Panasonic, both BD-RE and BD-R)

The following firmware levels have produced problems with various types of Blu-Ray media:
BZA6 - only does Panasonic BD-RE (installed at some ASACA sites)
BDB2 - Seen on some DISC and on some ASACA libraries

XFS/DMAPI Kernel RPM

Well I finally got an RPM build with LINUX 2.6.24-rc3. Now upgrades to the kernel in OSVault can be done much more easily (and safely). Still a lot of testing to run on it. The new kernel also includes a change for the DM_REMOVE_EVENT (deleting a file) that removes the migration database entry of files that are already migrated, then deleted. This keeps the database smaller and is generally better practice. IBM also put this same modification into their DMAPI kernel for the GPFS software.

The mod for the inodes goes in vfs_vnodeops.c like the following:
file_vp = XFS_ITOV(ip);

if (DM_EVENT_ENABLED(dp, DM_EVENT_REMOVE)) {
error = XFS_SEND_NAMESP(mp, DM_EVENT_REMOVE, dir_vp,
DM_RIGHT_NULL, file_vp, DM_RIGHT_NULL,
name, NULL, dm_di_mode, 0, 0);
if (error)
return error;
}

This passes the inode to the dmapid program so that it doesn't have to thrash around trying to find out which file was deleted.