ITEM: CP7731L

DFS: access to JFS (HSM) exported into DFS

 PROBLEM: Customer is exporting a JFS filesystem into DFS space.
The existing JFS filesystem contains millions of files with the
same owner.  This is leftover from a LAN server for AIX setup.
Underlying the JFS filesystem is an HSM setup in order to mount
an optical disk jukebox.

Customer needs to have DCE identities have access to the files.
He has tried creating a DCE user with the same uid that owns the
files, but still cannot get access to them.

*ACTION TAKEN: I setup a test where I exported /fixes from JFS space
into /:/fixes in DFS space.  In this filesystem, there is a file
"junk" which has 600 root:sys for permissions.  I was not able to
access the file /:/fixes/junk as root (DCE: hosts/wks32/self).

However, I changed the /fixes/junk file to owner 106:sys and then
tried to access it as root (DCE: donovan {uid 106}) and it worked fine.
The important point here is the uid of the DCE identity.

Response:

Conference initiated with Mike P., Julie M., Donovan S., Roy K.,
and myself.  We are currently discussing the different interface
in JFS/DFS/and HSM file/directory structure and mount point, 
which could potentially be where the problem reside.

 PROBLEM: customer has a normal JFS filesystem mounted at /image.
This is exported to DFS space at /:/.rw/image.

Then at /image/prod/image/optical/1996/\#\# they have several
filesystems mounted over the \#\#.  There are 00 through 05, each a
seperate filesystem.  When going through JFS space, they can see the
files in the 00 through 05 directories.  However if they go through
the DFS path, they do not get an error, but only get "total 0" from an
"ls -l".

*ACTION TAKEN:  I was able to dial in to aid in troubleshooting.

I had them umount the ..../00 filesystem, and mount it at /test.  We
then exported this to DFS space at /:/.rw/test.  We could then see the
files in /:/.rw/test.

I noticed that through DFS, the mount points of 1996/\#\# were owned by
root, while they were owned by sys in JFS space.  This seems to be
caused by the underlying directory (JFS mount directory) being owned
by root.  They attempted to change this, but couldn't get /test
unmounted.  This may have to do with HSM.

*ACTION PLAN: customer will unmount one of the ..../\#\# filesystems,
change the mount point owner, and then remount it.  They will call
back in with results.

*ACTION TAKEN: customer was able to get the filesystems unmounted
and remounted.  However, changing the sys:sys to root:sys did not
help.  They have since heard that there might be problems in going
through 2-3 mount points.  Therefore they have decided to recreate
the directory structure currently held in /image in the / filesystem.
Then they can mount the 00-05 filesystems on mount points that are
in the root filesystem.

I also mentioned that the problem mount points' path name is 33
characters.  The problem shows up when going from the directory
with 29 characters to the one with 33.  In order to test a possible
path length limit, she will also create a pathname using "o" instead
of optical.  If the filesystem will work when mounted down the
"o" path, but not the "optical" path, we may have a path length limit.

*ACTION TAKEN: after my own testing I thought I had it recreated.
However, I believe this was due to creating the files, and then
mounting the JFS filesystem.  I did find that DFS will mount
the filesystem upon exporting it to DFS space.
I was able to create JFS filesystems with 
1) long initial JFS mount points
2) long fileset names
3) without mounting the JFS filesystem first
(long is >32 characters)

However, I did notice that this caused the dfstab file to have
a strange name for the aggregate name.  It is the first 31
characters of the JFS mount point with the /dev/lv\#\# name 
appended.

*ACTION TAKEN: suggested the solution of creating the longest portion
of the pathname is DFS space.  Then we can export the short mount
point for the 00-05 filesystems into DFS space at the end of their
long path.

ie.
JFS
/hsm/00
/hsm/01
/hsm/05

DFS
/:/.rw/image/prod/image/optical/1996

export /hsm/00 into dfs space, with mount of 
/:/.rw/image/prod/image/optical/1996/00

*ACTION TAKEN: 
fts crmount -dir /:/.rw/image/prod/image/optical/1996/00 -fileset 
        \<00_fileset_name>

Now the lmxuser (with credentials) was able to see the HSM information
through DFS space.

This eliminates one mount point that must be traversed in order to
reach the required data.  This only seems evident when using the HSM
filesystem.  I did not see this behavior when mounting one JFS 
filesystem which had another farther down the JFS directory tree.



Support Line: DFS: access to JFS (HSM) exported into DFS ITEM: CP7731L

Dated: December 1997 Category: N/A

This HTML file was generated 99/06/24~13:30:17

Comments or suggestions?
Contact us