This is my third attempt to patch the isofs code.  It is a completely
different patch from the previous two.  I do not think there are any
trade-offs with this patch.

The problem it addresses is that the current iso9660 file system
cannot reach inodes located beyond the 4GB barrier.  This is caused by
using the inode number as the byte offset of the inode data.  Being
32-bits wide, the inode number is unable to reach inode data that does
not reside on the first 4GB of the file system.

This causes real problems with "growisofs"

     http://fy.chalmers.se/~appro/linux/DVD+RW/#isofs4gb

and my pet project "shunt"

     http://www.serice.net/shunt/

This patch switches the isofs code from iget() to iget5_locked() which
allows extra data to be passed into isofs_read_inode() so that inode
data anywhere on the disk can be reached.

The inode number scheme was also changed.  Continuing to use the byte
offset would have resulted in non-unique inodes in many common
situations, but because the inode number no longer plays any role in
reading the meta-data off the disk, I was free to set the inode number
to some unique characteristic of the file.  I have chosen to use the
block offset which is also 32-bits wide.

As a practical matter, these new inode numbers should always be unique
for directories (which to me is the important case).  They will also
be unique for other file types provided you do not have a specially
mastered image that has two files that share the same starting block
(which is allowed by the standard).  Compared to the current scheme,
this should be a substantial reduction in the likelihood of assigning
non-unique inode numbers.

Lastly, the current code uses the default export_operations to handle
accessing the file system through NFS.  The problem with this is that
the default NFS operations assume that iget() works which is no longer
the case because of the necessary switch to iget5_locked().  So, I had
to implement the NFS operations too.

I did not, however, implement the NFS get_parent() method.  So, the
default method which just returns an error is used.  This is not a
reduction in functionality because the current code also uses the
default method.  If someone can explain what I need to do to trigger
this error, I will gladly try to implement the method.

Thanks,
Paul Serice