Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ FilesystemDiscussion ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

Up: FilesystemGroup
Next: FilesystemDiscussion2

The information on this page may be outdated; it reflects the discussion led/being led about the subject "Filesystem for JOS". Feel free to join!

I have a good mind to write a JOS file system (FS), but there are some fundamental questions we have to answer first:

• What is the basic structure for our FS? Is it an object store, and we have to implement directory structures on top of it? Or is it a standard FS architecture (directories and the like), and we have to implement an object store on top of it?
• What do we want to support? NTFS, Linux, FAT volumes ...
• Is there a need for a new JOS-proprietary FS, incompatible to existing FSs?

Despite these open questions, this is the design approach I made up so far (package names are fictional):

• There is an interface org.jos.fs.Medium with methods like getSize(), readBytes(), writeBytes(), eject() that models low-level storage medium access.
  Implementors of this interface are native harddisk drivers. For debugging, there will be a Java implementor that creates an image file in the host FS.

• There is an interface org.jos.fs.FileSystem with methods like readDir(String dirname), getInputStream(String filename), getOutputStream(String filename), deleteFile(String filename).
  Implementors of this interface are (best case) Java classes that read/write common file systems (Linux etc.). Other implementors could be network/FTP clients. When JOS runs atop a host OS, bridge classes can "mount" the host FS.

• There is a org.jos.fs.FileSystemManager that keeps track of registered Medium-s (media) and FileSystem-s. Every Medium has one FileSystem, at most. The FileSystemManager could also glue together the individual FileSystems, in a Unix-like manner (/diskdrive/..., /mount/anothersystem/...).

• The java.io.* classes access the FileSystemManager to implement their functionality. E.g., a FileInputStream is not much more than a stub; it obtains an InputStream from a FileSystem and delegates all read calls to that stream.

I'll be glad to receive comments from any of you.

StefanReich, 02-11-98

I confess I do not know the gnitty gritty details of most filesystems, aside from knowing that FAT does not allow for file-level security, but NTFS does (I'm assuming Linux' ext2fs does as well?). However, I do think that someone more knowledgeable than myself should lay out the pros/cons of your two different approaches (i.e. FS on top of Object Store, or vice versa). What are the advantages and disadvantages of each? What advantages could we gain by implementing a proprietary FS. If we do an object store with an FS on top of it, I am assuming we would need a proprietary FS.

I think if you can break this down for us FS-ignorant folks, then we might be able to provide some ideas from a user perspective.

I have only one request... whatever we do, please do NOT use as the delimiter in the FS! What was Microsoft thinking?!?! --MasonZhwiti

I don't know much about object stores. I guess most of these systems use a single image file they organize themselves.

While it is certainly possible to implement a file system on top of an object store, I can't see any advantages of this approach. (Despite the fact that it's "innovative" in the sense that nobody has done it before, as far as I know.)

The other way round, it makes a lot more sense to me. Use whatever FS you like and create an Object Store image file in it. This way, we retain compatibility with existing FS.

Anyway, we can leave all choices open by specifying well-defined interfaces to an object store and to a file system (I'm currently designing the latter). You just call Store.storeObject(...) and don't care about the underlying structures.

--StefanReich, 2/13/98

I like this idea. It makes sense to build a file system that could hold an object storage system, since I don't know how easy it would be to have an object store that can hold a file system. I would love to see someone working on an object store, with a well defined interface as Stefan mentioned, since it would be great to have all of these packages a few months down the line. Imagine a FAT file system (it's also phat), an object store, comparmentalized XML Browser/File Finder beans, and Thomas's high-level File Finder interface that could fit on the top of everything. Sounds good to me.

You know, I'd love to see this Wiki system automatically create a new page when the existing page gets too long; it could just append a number to the end of the current page, and insert a "Click here for next page (you are on page 3 of 5)" link at the bottom of the page. Maybe Wiki could also provide an XML tag COMMENT that we each would put around our comment blocks. This nifty COMMENT block could then be dated, linked, presented any way we want, searchable, etc. Actually, it'd be nice to base Wiki on XML.... SGML for the masses, baby!

--Brad Neuberg, 2/13/98

While thinking about it, I realized that there could be advantages of modelling a FS in an object store. Imagine you have Folder objects, and add Listeners to this objects. One listener could automatically process (compile, etc...) any file that is added to the directory. And, since we have persistence, the listener remains active when the system is shut down and rebooted!

--StefanReich, 2/14/98

Any interest in making the file system accessible via JDBC? (In addition to the object model). Microsoft plans to do something similar (or already does) with OLEDB. I think it can be very interesting to query the file system as if it were a relational database.

--MarioCormier, 6/22/98

--StefanReich, 24/Jun/98

Content of these pages are owned and copyrighted by the poster.
Hosted by: