From - Wed Jun 30 20:32:19 1999 Path: reader2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail From: "Glenn C. Everhart" Newsgroups: comp.os.vms Subject: Re: CFS; OpenVMS Wizard; WNT (was Re: "Compaq Strategic Directions" Presentation Now Posted Date: Wed, 30 Jun 1999 20:29:14 -0500 Organization: GenCybEng Lines: 89 Message-ID: <377A7E1A.2B501CCA@gce.com> References: <8025679E.00581D70.00@qedilc01.qedi.quintiles.com> <7l8b0g$biq$1@aquila.mdx.ac.uk> <7lam9b$7o8@gap.cco.caltech.edu> <377966F9.42DAC1F2@tsoft-inc.com> <7ld2b2$hsc$1@aquila.mdx.ac.uk> <3779D5B9.42DBE241@Montagar.com> <009DA675.3C52D433@SSRL04.SLAC.STANFORD.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: wwpfd5u4Y8IvTLS2E4V+hxmWZSLT8DuiKNfdgi53SO8= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 1 Jul 1999 00:29:42 GMT X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS E7.1-1H1 DEC 3000 - M300LX) Xref: reader2.news.rcn.net comp.os.vms:236044 Alan Winston - SSRL Admin Cmptg Mgr wrote: > > In article <3779D5B9.42DBE241@Montagar.com>, "David L. Cathey" > writes: > > > The only real way to do it is to have a "thing" control all > >access to a piece of storage and have a well defined protocol for > >accessing it. Break the rules, and "thing" rewards you with an error. > >This is similar to a SCSI controller, but extends knowledge to the > >actual file system. A new file system should in fact do more than the miserable excuses now common. Among other things: * Allow linking lots of disks' structures into one tree or perhaps graph (simple, eh?) * Support lots more file attributes in identifying and lookup for files (so one can for example say things like "set default 8>" or something like it, and find files that way as well as just with long names and paths. Lots of security attributes too. Programs moving between directories could be made to set/unset these search attributes and contents should be able to be indexed and the indices used... * Scale with directories in B-trees or similar so access does not get slower very quickly with huge directories. Spiralog does this. * Support distributed operation and update. DECnet support does distributed stuff, but is a tad slow; something more along AFS lines might be considered... * Have the ability to run very simple file contents (bitstream) without incurring record system overhead, yet allow record system or additional layers where needed. Layers should be able to be added transparently to all else that encrypt, compress, etc. That way the presence of RMS would not imply that simple apps getting at text files and not needing locks could be fast (like they were with good old RT11 utilities, remember?) while stuff needing ISAM or other RMS services, or needing the locking for safety, could have it. * Easy hooks for user access control addins. This should include controls based on access frequency as well as user, program, time, location, privs, imagename, etc. * Should be possible to hide files or quietly open alternate ones where access control says so. * Should be possible to merge many filestructures with one master so physical disks can be backed up separately or restored separately, but so that the collection acts like one filesystem. While not strictly a filesystem thing, there ought to be ways to tell VMS that the user security profile has changed based on other system events (like running a browser that may be running some remote script language, for example) so a user's privs and access rights might reflect the true "subject" rather than the mere user. I also suspect that there ought to be an easier way to handle all these attributes than trying to use ACLs. ACLs are mathematically able to do this sort of stuff, but they can get unusably long real fast if that's all you have. In the Safety product I came up with an alternative, but believe that several such tuples, not just one, per file should be possible to give full generality. ACLs are IMHO unmanageable over time, though. BTW, maintaining device access control as well as filesystem control is a good thing, should be continued. Glenn Everhart > > > > This somewhat protects the file system from corruption, insures > >that corruption does not occur due to dissimilar "file system" > >manipulation, > >and more rigidly requires everyone to adhere to the defined protocol. > >Data corruption within a file is still a problem... > > So aren't we inventing the Network Appliance file server box? It's got > its own file system (WAFL) that's opaque to other platforms, serves out > files via NFS to any client, and does its own FS maintenance. > > -- Alan > > =============================================================================== > Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDU > Disclaimer: I speak only for myself, not SLAC or SSRL Phone: 650/926-3056 > Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA 94309-0210 > ===============================================================================