Mail Archives: opendos/1997/02/12/21:22:35
On Thu, 13 Feb 1997, Mark Habersack wrote:
> Once upon a time (on 11 Feb 97 at 21:39) mharris AT blackwidow DOT saultc DOT on. said:
>
> > > > Your definition of "mount" seems to be faulty. To "mount" a
> > >
> > > My apologies, I looking for a term which hasn't been declared yet, how
> > > about we call it INTEND?
> >
> > Ok, sounds fair. I don't understand the logic behind it though.
> > You could just make the kernel smart enough to detect what
> > filesystem is on the disk in the drive, and automount it like it
> > allready does with FAT disks. Note, that automounting is only
> > possible for READ-ONLY disks (write protected) and/or disk drives
> > with write caching disabled. This is the case in DOS right now,
> > and will always be. The reason is that if the info hasn't been
> > written to disk yet, and you yank it, then the disk is toasted.
> > Sure, the kernel could print an error message saying "please put
> > that disk back in" but this would ONLY work if you complied, and
> > actually did it. A better solution is not caching removable
> > media.
> But, in case of mountable partitions/drives, this makes impossible caching of
> *any* drive except for the root FS!
Linux caches drives other than the root. SMARTDRV can cache the
CDROM as well, and it must be mounted (albeit automatically). I
don't see how mounting a drive prevents caching. SMARTDRV lets
you turn caching on or off on any drive on the fly, so it is
totally possible.
> Better way would be to build into the
> mount utility some intelligent code that'd just flush *all* caches before
> unmounting the drive.
I believe that this is allready done. I never flush the cache
before unmounting any cached drives and it works fine. The same
could be implemented in DOS.
> In case of floppies you're on your own though. But I
> think that write cache for floppies is, err..., funny idea ;-)
Yes, I agree. Unfortunately, the damned drive cache (SMARTDRV)
must be forced to NOT cache it (under my setup anyway).
> > > and see what command.com does. If command.com was doing raw reads, it
> > > should crash, but it doesn't because it checks to see it the disk id's as
> > > the one it was using to begin with.
> >
> > Well, COMMAND.COM doesn't contain the filesystem code, the kernel
> > code does, but yes, the kernel does detect disk changes. What
> > I'm saying is that it would ALSO have to detect different
> > filesystem types. The other point is what I've stated above,
> > that drive write caching must be disabled in order to automount
> > removeable disks.
> What's wrong with adding some code to flush the cache *inside* the
> device driver or, as I wrote above, in the utility (or kernel API) that
> unmounts the FS?
Nothing at all. The code *should* be inside the device driver or
whatever just as you state, however I'm talking about removeable
disks that could be yanked out before someone unmounts them, thus
the cache software doesn't get a chance to unmount the drive. I
guess the cache software is what should be responsible. In other
words, by using the current method of picking which drives get
cached, you could enable/disable caching on removable media as
you see fit. I think that the default behavior of the disk cache
should be to not cache any removeable disks though.
> > If this is the case then automounting any FS is possible as long
> > as the kernel can understand what FS is on the disk to begin
> > with. Then NO program (MOUNT, INTEND, whatever) is needed at
> > all. If write caching is enabled, then a MOUNT utility is
> > needed.
> If I were to chose, I wouldn't want to have automounting enabled. This makes
> a case for many errors you cannot help/prevent. Come on, people! Let's not
> get that lazy - all you have to do is type (perhaps once only) 'mount
> /dev/hdb1 /mnt ex2fs'!! (or sth similar with DOS syntax). I don't knwo how it
> is with you, but I don't like too much automagical doodas in the OS - I'd
> rather automate it myself with scripts, aliases, batch files - take your
> pick.
Exactly, one could choose how they want it, either automounted,
or manually. Also, as long as the drive has an entry in fstab,
you only need to say "mount /dev/hdb1" or "mount /usr" or
wherever the mount point usually is. Also, a "mount -a" mounts
all drives in fstab. This could be done in DOS in a very similar
manner. (Should someone not want automounting that is).
> > > As far as I know, _any_ disk reserves the first sector for the media
> > > information, if not a volume label, then a serial number.
> >
> > Yes, I'm sure that every disk contains a serial number too, but
> > what I'm curious about is HOW to detect a particular filesystem's
> > SIGNATURE in sector 0. Hmmm. This is very interesting.
> It's not always stored in sector 0. This sector contains just the OS loader
> code which has not commonly defined format (I'm talking about partition BR,
> not MBR). You detect, eg. FAT, by first looking up the partition table in the
> MBR, then (if one exists) extended partition's partition table, get the
> partition code byte and it tells you what *OS* has created the partition. In
> case of DOS this tells you at once what type of FS is on the partition in
> question (FAT12, FAT16, DOSBIG etc.). Other systems (mostly Unices) use
> their superblock to store information about the file system on that partition
> (DOS actually does exactly the same) - you have to read the signature from
> known spot in the superblock and voila! Linux, for example, has two (AFAIK)
> reserved codes to store in the MBR partition table - Linux native (0x80 - I'm
> not sure) and swap (0x81 - again, not sure). Then you read the superblock and
> read whether it's a minix, ext2fs or other FS.
Yah, I've seen the table of fs types that fdisk prints out, but
wasn't sure exactly how to detect this from a C program. I'm
working on it though.
> > Do you know how to do it? I'm going to create a bunch of
> > floppies tonight with different filesystems on them (in Linux)
> > and examine the boot sectors to see if I can determine unique
> > signatures. If anyone knows how to do this, then please let me
> > know. I'll post my results if anyone is interested. This could
> > be the beginning of a universal automount for OpenDOS.
> Download the GRUB sources, it detects file systems on the boot time (probably
> using technique similar to what I described above). Also look in the Linux
> kernel sources for the FS drivers code.
Well, if this is in GRUB, etc, then it could easily be put into
DOS and provide automounting.
> > Is someone keeping an OpenDOS wishlist together? I'm going to
> > make one based on my own wishes, and also those of everyone else
> > in here (an unbiased wishlist that is).
> Mail me with your ideas, we can talk about it.
Will do. They're not all my ideas, but a lot are. I'll send it
to you in a few days.
> > If anyone wants to add to the wishlist, please drop me a line.
> I just did! Above... ;-))
Yip.
TTYL
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca
WABI: A commercial Windows emulator for Linux. http://www.caldera.com
- Raw text -