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.

a

a

Generating Video Thumbnails during Migration

OK, so we want the next released version of OSVault to generate video thumbnails during migration from hard drive to optical/tape media. Here's how the prototype implementation works:
1. During migration, the file type is determined using the "file" command. This has been extended to recognize various video formats.
2. If the file being migrated is a video file that we support, then during migration (not just as a separate task), each block copied out is run thru the ffmpeg program. ffmpeg generates video thumbnails with the command
ffmpeg -y -i video.avi -f singlejpeg -ss 10 -vframes 1 -s 150×100 -an thumbnail.jpg
3. The output thumbnail is placed in /var/www/html for the file browser to find. WHen you use the file browser, the thumbnail is displayed if it exists.

Reading direct from Optical Media

OSVault can be configured to either stage files back to hard disk on access or to read directly from optical media for files not resident on hard disk.

Generally, the OSVault appliance needs to be installed either one way or the other, it won't support both types of file access. Once a system is configured as a staging (also called DMAPI) system, it is difficult to change that configuration. Also, once a system is configured for direct reads from optical disk, it is difficult to convert it to stage files.

Direct reads from media are accomplished via symbolic links that are on the hard disk and point to the optical disk file. The migration.c source code has a DEFINE called PURGEIT that, if defined, makes the migration program able to migrate files and replace them with symbolic links. When using direct reads/symbolic links, you do not use the "purge" program. The "purge" program is only used with staging configurations.

Generally, reading directly from optical media or staging files works well with Windows shares, but NFS shares require files to be staged back to disk. If you wish to read directly from optical disk and use and NFS share, you will have to NFS mount both the /cache share and the /archive share.

I mixed up the media in the library! HELP!

If you removed media from the optical library and placed it back in the library and aren't sure if you put it in the right place, you can remedy this easily.

First, you need to have the library physically check each slot to see if media is there. Most optical libraries have the ability to do this from some menu. We also did a program called "initelem" that will cause a library to check each slot for media.

After running "initelem", you can then verify volume labels of media in each slot by running "inventory". "inventory" will load every piece of media into a drive and check to see if it is formatted and what its label is. Then "inventory" will update the media database (archive.media in MySQL) with the location and name of each piece of media.

Time wise, running a full "initelem" followed by "inventory" can take a while. An ASACA 750 slot library with three drives will take about 45 minutes to run "initelem" and then about 1 minute per loaded media per drive for "inventory", or 4 hours for 750 pieces of media.