Date: Mon, 06 May 2002 22:43:49 -0400 From: Chuck McCrobie <mccrobie@cablespeed.com> Cc: freebsd-fs@freebsd.org Subject: Re: New File system to commit to FreeBSD Message-ID: <3CD73F65.1D9241A2@cablespeed.com> References: <3CD5F4CD.2F394EFE@cablespeed.com> <20020506040438.GZ36741@elvis.mu.org> <3CD63C3F.2F4E8F02@mindspring.com> <20020506082125.GC36741@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > * Terry Lambert <tlambert2@mindspring.com> [020506 01:18] wrote: > > Alfred Perlstein wrote: > > > * Chuck McCrobie <mccrobie@cablespeed.com> [020505 20:13] wrote: > > > > 3. OpenVMS and ODs-2 keep record attributes and embedded meta-data in > > > > the regular file data. I've been writing some utility programs that > > > > understand the meta-data, like "ods2_cat" and "ods2_cp". Also, some > > > > work has progressed on an RMS library. Should and how are such things > > > > committed? > > > > > > This sounds like quite a suite of utilities, my _guess_ is that > > > the FS code could/would be committed to FreeBSD, but the utilities > > > to manipulate the FS (ods2_cat, ods2_cp) would go into a port. > > > > You could either hack into the namespace, or you could provide > > an fcntl() that gets passed down to the FS for an open descriptor, > > to turn these utilities tiny, and incorporate most of the code into > > the FS itself (you are much better off doing this, if you can, since > > it means that the facilities won't be "lost" into a port for which > > FTP services will have to be maintained in perpetuity). > > > > Right now, since FreeBSD doesn't propagate namespace selection > > information from the POSIX namespsace escape down properly, you > > would have to hack it to operate on a per component basis (not > > as bad as you might imagine, but still an annoying thing to have > > to do), so for my money, an fcntl() would be the best approach. > > Yeah, I find it really odd that one would expose the internals > of the actual meta-data to applications. > > ...wandering off topic... > Is that how VMS does it (in the kernel)? Or is there some userland > library that you _must use_ to access files that does this sort of > thing for you? Or does each userspace application have to do magic > to parse meta-data? > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ 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"? --- 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? 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... -- 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?3CD73F65.1D9241A2>