Date: Mon, 06 May 2002 23:31:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Chuck McCrobie <mccrobie@cablespeed.com> Cc: freebsd-fs@freebsd.org Subject: Re: New File system to commit to FreeBSD Message-ID: <3CD774CF.3EC90036@mindspring.com> References: <3CD5F4CD.2F394EFE@cablespeed.com> <20020506040438.GZ36741@elvis.mu.org> <3CD63C3F.2F4E8F02@mindspring.com> <20020506082125.GC36741@elvis.mu.org> <3CD73F65.1D9241A2@cablespeed.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck McCrobie wrote:
> This fcntl would place the open descriptor in "record mode", during
> which the application would have to specify a buffer large enough to get
> the entire record. Most files in OpenVMS are record oriented, not
> byte-stream oriented as in Unix.
>
> Do you mean by "namespace selection" something like
> "/openvms/dir1/file1:record_access" as in the concept of "streams"?
//<namespace>/<path> ...per POSIX, a doubled initial slash is
to be treated as implementation defined.
The collapse of multiple intermediate "/" to a single "/" is
also documented, but it's really only applicable to the default
namespace.
Doing the POSIX namespace escape thing should cause all subsequent
path components to be interpreted as being in the selected namespace
(the namespace selection should be inherited).
This is kind of hard with the FreeBSD vop_lookup interface,
unforunately. The first hard part is that it doesn't use
real recursion, but uses mutual recursion, instead. You
could handle that part by preparsing the "//" off in an upper
level routine, and then calling the current upper level lookup
code from the higher level code (basically, insert a function
call layer to parse out the namespace to hold it constant for
all subsequent path components). This takes care of the
complication introduced by necessity of handling symbolic link
information by expansion into the same path name buffer that
was copied into with the user argument to the pathname taking
functions.
The second hard part is that there are instances internally
where lookups are called multiple times. Rename is pretty
hard, as is obtaining an empty directory entry slot in which
to place the name of a newly create file. THe problem is
also complicated, if you attempt to handle Macintosh style
semantics ("case sensitive on storage, case insensitive on
lookup") or multiple namespaces (e.g. "the 8.3 vs. the Unicode
namespace under VFAT32 or NTFS", particularly when it comes
to renaming that results in naming moving from one name space
to another, and coupling the renaming of both names).
The third hard part is that VFS layers are permitted, by
the definition of VOP_LOOKUP, to consume multiple intermediate
path components, and return an answer that isn't only per
component.
For this to be completely handled, you'd probably have to
modify the FreeBSD path management code to use a Windows-like
path component list descriptor "parsed path" object. THat's
possible, but it's a lot of work, and would be a hard sell to
the BSD community, I think.
> --- off-topic on OpenVMS ---
>
> OpenVMS has a "semi-user-land" layer called Record Management Services
> (RMS). You get RMS by default with the "RMS Services". One can
> completely by-pass this layer and do the meta-data handling in the
> application, but why bother. One can also create files without any
> embedded meta-data.
>
> My idea is to duplicate this RMS layer which sits between the file
> system and the user applications. Since most application in OpenVMS
> deal with Records, applications to read data from OpenVMS systems would
> also need to deal with records - there are exceptions, of course, like
> .jpg, .gif, etc. type files. Think UDP socket reading - if you don't
> specify a buffer big enough for the record, only part is read - how does
> one get the rest of the record?
Seeks get pretty interesting, too, particularly for language
files with "variable length records with implied carriage return
carriage control" -- the default text file type created by
editors, and used for almost all source files.
You would have to be careful here. Your library for using the
code on FreBSD would have to make a decision here (and several
other places) between bug-for-bug compatability, and POLA from
someone coming into it as their first experience.
One of the problems here is that, at least until the mid 1990's,
VMS had the nasty habit of advancing the pointer after the
character following the implied carriage return carriage control
was read, rather than merely after reading the implied terminator.
It also put the seek onto a record boundary (seeking to a saved
position is implementation defined, and VMS defined it to be at
the record boundary). So for parsed languages, you got the wrong
start of line for the loop control structures for the loop start
in one token look-ahead parsers, unless before recording you did
an "ungetc(getc());". 8-).
There are a lot of advantages to record oriented I/O that UNIX
could benefit from learning from Files-11. The major one is
that single record insertion in a list is trivial, which makes
the FS *much* better at supporting databases.
It's all very entithetical to C, so a library would probably
be the correct way of handling the translation from stream.
But I don't think it will work for records, which are intrinsic
to the FS structure. You might be able to provide a record
interface on top of a stream interface, but providing record
access to an underlying record structured FS is hard, through
UNIX interfaces (as "Eunice", the UNIX interface emulation package
for VMS, really demonstrated).
> The entire intent of this project is to provide OpenVMS users with the
> ability to access their data on ODS-2 optical media. My initial goal
> was to make understanding and using the file system and utilities
> similar as on OpenVMS...
Wow. Are you going to implement the entire HSM, or are you
planning on single volume access only? The former would be
a heck of an involved project... though FreeBSD could really
use an HSM project (IMO).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD774CF.3EC90036>