Return-Path: <@SEARN.SUNET.SE,@SEARN.SUNET.SE:NETTLE@GDLVM7.VNET.IBM.COM>
Newsgroups: bit.listserv.sfs-l
Date:         Wed, 23 Dec 1992 08:41:42 EST
From:         Scott Nettleship <NETTLE@GDLVM7.VNET.IBM.COM>
Subject:      SFS questions

< I've tried to answer these questions as best I can.  Everyone
< out there have a great holidays.

After working with SFS for a few months now I have a number of questions which
I'd appreciate any help on.  So thanks in advance for any help on:

1.  When reading up on SFS it seemed that at a certain point response
    time will be much better for a directory controlled directory than
    for a file controlled directory.  So far we have worked with file
    control directories with small amounts of files but are now
    starting to look at setting up some new directories which would
    contain many more files (over 2000 large compiles for a start).
    Does any one out there know a what point response time would
    noticeably slow down for file control directories?  If it slows
    down on one directory would it also slow down on other directories
    as well?

< In general, performance savings for DIRCONTROL directories are
< because once you access them, the checks for locking at the file
< level are unnecessary (authority on the directory implies the same
< authority on the file).  I don't know of any performance "curve"
< for this.  In general, the more you open files the more the savings.
< Also, there is a performance advantage for using data spaces if
< you have the hardware.  It's easy to test if you want to.  Place
< the files in the directory (created with the NEWREAD/NEWWRITE auth)
< for filecontrol and then convert it to DIRCONTROL.

2.  How does SFS search for a file in file control directories.
    Does it first look for the sub-directory and then tree
    down to the file?  If this is true, does making more sub-
    directories increase search speed?

< No such real concept that I'm aware of (I'm not the expert on
< the SFS Server searching internals).  Searching is done via
< a relational database type search through the SFS catalogs if that
< means anything to anyone.  Some things to keep in mind:
<
< - If you access a directory, caches are created in the CMS user
<   machine.  FST searching is done there the same as minidisks.
<   Intelligent subsetting of files using subdirectories can keep
<   searching at a minimum and ease virtual storage requirements
<   in the user machine.
< - Once a file is found in the user machine catalog information is
<   passed to the server so it doesn't have to do the lookup.  So
<   accessing the directory may help.
< - There is no real difference between FILECONTROL and DIRCONTROL for
<   this procedure.
< - Using aliases can get you better groupings because you can leave
<   the base files in several large directories but create a
<   subdirectory structure of aliases for performance.

3.  Are there any SFS Adminitration classes?

< No, known requirement for this.  A local External Security Manager
< (ESM) can be written to provide this.  Also, you can filter
< requests through an SFS Administrative PROP machine.  We do need
< to provide native support for this in SFS.

4.  When using the REVOKE command to revoke authority for a userid
    on a sub-directory, then any access that the SFS administrators
    have to that sub-directory gets broken (and they have to re-access
    before using).  Is there any way to prevent this from happening?

< Not that I'm aware of but I'll look into the problem after the
< holidays when all the folks are back.

5.  I've seen the discussion on this but still wonder:  Is there any
    way to cause Xedit and COPYfile to look first at access rather
    than at authority?

< The whole sad story has been posted before so I won't get into
< it again.  One method I use is to put SHARE locks on files I want
< to "guard" against this.  Again, another known requirement.

6.  Is there a way to cause DIRList to use update locks rather than
    exclusive locks?

< Not sure what you mean here.  DIRLIST itself doesn't do any locking.
< It will do an ACCESS when us try FILELIST from the screen.


Scott Nettleship
CMS/SFS Planning/Development
Internet: NETTLE@GDLVM7.VNET.IBM.COM
IBMMAIL:  USIB2WF7 at IBMMAIL
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU