On Tue, 22 Jun 1999 12:15:13 -0600, "Jeff Merkey"
<jmerkey@timpanogas.com> said:
> I've reviewed the code sections you are refering to. This is along the same
> lines to what Windows NT is doing, but not identical. From what I've seen,
> this could really help Linux. The next step would be to create file runs
> for SMP read/write.
We can do that on Linux. The io_request spinlock protects the block
device request structures, but otherwise the actual IO to/from can
progress in parallel on multiple devices and (in 2.3) copies between
user space and the caches can also run in parallel.
> MS actually stores the file allocations in the VM Cache, and then
> transacts them by completely bypassing the file system driver. In
> essence, the file system driver is reduced to simply being an on-disk
> decode agent for the VM Cache Manager.
Just like Linux. The "decode agent" for existing data is the bmap()
function. 2.3 now uses a similar fs-supplied agent for writes too,
which encapsulates both overwrite and allocate in a transparent manner.
> In the Windows NT Fenris, only certain requests ever make it into an
> IORP request. Files are read and written directly by the VM Cache
> Manager and the File System driver only maintains meta-data fior the
> file system (FAT's, Dirs, etc.). This is how NTFS, FASTFAT, CDFS, and
> FENRIS are all structured on Windows NT. WARNING!!!! There are some
> very complex unwind cases associated with the methods used by MS in
> their file systems. On SMP, however, their model is unequalled from
> structly a parallelism standpoint.
Linux behaves very similarly. Only requests which have to hit disk
actually get a "struct request" generated; everything else is done in
cache.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/