On Sat, Jun 30, 2001 at 08:05:40PM -0700, Timothy Swenson wrote:
> At 01:12 PM 6/28/2001 -0400, Nasta wrote:
>
> >Let me give you an example. Suppose someone implemented SCSI on the Q40.
> >Then, you could connect an IDE and a SCSI hard disc to it. Boh would use
> >the QWA file system, but here is the problem: each device would have it's
> >own copy of the QWA handling code. If there was a CD connected to either
> >(and here we would already be circumventing another driver that works on
> >the same hardware), with a QXL.WIN on it, then the CD driver would also
> >need it's own copy of the QWA handling code. And, there would be no way to
> >make one be win1_ the other win2_ and the QXL.WIN on the CD be a win3_,
> >although they logically should be. It could be done, if they were all set
> >to _USE another name, then some sort of DEV_USE would be used to make them
> >dev1,2,3, and then a DEV_USE win would make them win 1,2,3. Total number of
> >QWA copies: 3. Total number of directory devices used: 4. If you think
> >about it, only one copy of the QWA handler code and only one device driver
> >would really be needed.
>
> Now, I'm not an expert in XFS (the IRIX file system), but I spent enough
> time listening to the experts talking about it so that I know a little
> about it.
>
> With XFS, the file system is separated from the physical device by a
> virtual file system (vfs). In other words, an XFS inode, points to a vfs
> inode, which points to a physical device sector. This way XFS can work
> across hard drives and CD's. This also allows for a volume manager (XLV)
> to come into play, and step in between XFS and the VFS. XLV allows
> striping and disk mirroring.
is that how its called in IRIX? Completely different in Linux, here the
vfs sits on top of the filesystem, between userspace (system calls) and
the filesystems, it could be roughly compared to QDOS trap#2 handling of
directory device drivers. It is responsible for the common tasks each
filesystem has to do, in QDOS terms eg managing the drive definition block.
Access to the underlying device is virtualised through the block device
layer which also includes the loop, raid, crypto and similar pseudodevices.
We already the vfs part in QDOS, unfortunately it is somewhat aged
and requires a few changes to handle things like longer filenames.
What is completely missing is a clean separation between the filesystem
and the block device layer.
> With SCSI pretty much being the only way to hook up disks and tapes, the
> SCSI controller one the one point where every call has to go through and
> the controller could handle multiple conversations (sort of timeshared as
> the SCSI protocol only allows one conversation at a time).
>
> Something like this could be implemented in SMSQ/E, but it would take a
> concerted effort. The XFS team had about 5-8 people at any one time. With
> SMSQ/E we just have TT.
XFS is a top end filesystem with very impressive performance.. iirc
they blasted away Linux and Solaris (MS wasn't considered competition).
QDOS doesn't need even a fraction of this performance.
Bye
Richard
