Browse Prior Art Database

Improving Random Retrieval Performance for an AIX Optical Library

IP.com Disclosure Number: IPCOM000115480D
Original Publication Date: 1995-May-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 113K

Publishing Venue

IBM

Related People

Dewey, DW: AUTHOR

Abstract

In AIX* and UNIX**, the operating system uses a vnode interface to communicate with the physical file system driver. This interface resolves path names when a file is requested by repeatedly calling the file system for a vnode for each directory in the path of the file. Hence, in a very large file system, if a requested file is nested five subdirectories deep, five disk lookups will occur to locate the directory of the file before retrieving the file directory entry.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 50% of the total text.

Improving Random Retrieval Performance for an AIX Optical Library

      In AIX* and UNIX**, the operating system uses a vnode interface
to communicate with the physical file system driver.  This interface
resolves path names when a file is requested by repeatedly calling
the file system for a vnode for each directory in the path of the
file.  Hence, in a very large file system, if a requested file is
nested five subdirectories deep, five disk lookups will occur to
locate
the directory of the file before retrieving the file directory entry.

      Due to the large capacities of optical media, the IBM* High
Performance Optical File System (HPOFS) maintains a directory
structure that allows the file system to directly lookup a file when
given a full path name, without requiring the lookup of the
directory.  Hence, when given a full pathname, HPOFS has the
capability to fetch the file in the above example with one directory
search instead of six.  However, when implemented in an AIX or UNIX
environment, the file system will not be given the path name and
instead will be forced to do the multiple directory searches.

      Typically, the path name resolution does not cause problems on
fixed disks because the vnodes for the directories become cached.
With the removability and greatly expanded capacity of an optical
library, these nodes will not be cached.  This problem is exasperated
further on write-once or WORM media, where the directory searches are
much more expensive.  Random retrieval operations is the scenario
most affected by this behavior.

This article presents two techniques to address this problem.
  Solution - The first technique is termed path bypass  and involves
a
   naming scheme.  It requires the cooperation of the application or
   user retrieving the files.  The second technique involves using an
on
   disk directory lookaside.  It is transparent to the application or
   user, but is not quite as efficient as the first technique.  Both
   techniques may be used separately or together to improve random
   retrieval.  They are covered here separately.
  Path Bypass - A naming trick that involves picking a character that
   the operating system considers a valid file name character but
that
   the physical file system driver will interpret as a path
separator.
   When the operating system begins it's name resolution, it will see
   the pathname as a single file name and hand the full pathname to
the
   file system.

This is best demonstrated by example:
  Let:
  o  The file to be retrieved be named desired_image
  o  Let this exist on an optical volume with the following path
      internal to the file system on the volume.
      /accts/id/claims/photos
  o  In the library system, when accessed let this volume be mounted
      on mount point: /user/dev/library/drive1

The existing path for the user to access the file would be:
  o  /user/dev/library/drive1/accts/...