MHW> DOS, Win/DOS, and NT don't "automount" anything. They don't
MHW> have the concept of mounting media. The other challenge presented
MHW> by this request is that of maintaining cache coherency. MS'
MHW> products avoid this problem by not caching writes to the floppy.
MHW> Caching is the chief technical reason for operating systems to
MHW> have the mount/unmount concept.
MHW>
MHW> Actually there is a gadget called SMARTDRV which adds an I/O
MHW> block cache to DOS or Win/DOS. In effect it must automount
MHW> any volume that it is directed to cache. It has no way to
MHW> auto-UNmount, though; if you allow it to cache writes then
MHW> IIRC you must give an explicit command before removing a
MHW> removable volume or data loss can occur.
The above is incorrect in almost every respect. Since the subject of
this thread is the idea of making Linux operate "just like Windows", it
is worthwhile explaining how Windows *actually* operates and correcting
the errors in the above:
* DOS-Windows and Windows NT *do* have the concept of mounting media.
What they don't have is the concept of manual mounting of volumes.
Mounting is done automatically by the kernel when the first reference is
made to a particular volume. Each installable filesystem driver is
queried in turn at its mount entrypoint until one recognises the volume
format and mounts the volume.
* Microsoft operating systems, at least DOS-Windows and Windows NT,
*do* cache writes to floppy discs. Indeed, this was full write-back
caching at one point. (This is the origin of the "had to give DOS an
explicit command" misconception in the above. The actual story is that
SMARTDRV would perform write-back caching, and I/O to the floppy disc
would hence still be in progress when the command interpreter returned
to the prompt. Unfortunately, many users had the preconception that any
system "sitting at the prompt" was idle, and as a consequence tended to
remove the floppy disc in the middle of the write-back I/O operations.
This was cured by forcing all lazy writes to be flushed to disc before
the command interpreter displayed the prompt. (An operation that was
only feasible on an operating system such as DOS, since it involved the
disc cache hooking directly into the internals of the command
interpreter.))
* SMARTDRV is not applicable to more recent versions of DOS-Windows, or
to Windows NT, and its behaviour isn't really relevant here because of
this. It is the *DOS* cache manager. The cache manager in DOS-Windows
is VCACHE. In Windows NT the cache manager is the kernel's Cache
Manager.
* SMARTDRV is not in charge of auto-mounting. That is done by the
operating system kernel itself (by IFSMGR in the case of DOS-Windows,
and by the I/O Manager in the case of Windows NT).
* Unmounting -- or at least the semantic equivalent -- in Windows NT is
also automatic. It occurs in response to the physical disc device
driver noticing a media change event and notifying the layers above it.
Documentation on how this affects the upper layers and what the FSD and
I/O Manager do in response is not freely available. But a description
of this process from the perspective of the physical storage device
driver is; and can be read at
http://msdn.microsoft.com/library/ddkdoc/ntddk/16issues_27.htm .
It's also worth noting, as an aside, that lumping the behaviour of
DOS-Windows and Windows NT into "this is how Windows behaves" is
incorrect. There is no single behaviour that can be attributed to
"Windows". DOS-Windows and Windows NT behave quite differently when it
comes to floppy discs. For example, DOS-Windows has the ability to
treat a single physical disc unit as two virtual volumes, A: and B:,
whereas Windows NT does not.
Much of the cause of the difference, ironically, is the fact that it is
as difficult to shoehorn the old floppy handling behaviour of DOS into
the architecture of Windows NT as it would be to shoehorn it into the
architecture of Linux.
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:20 EST