Re: Screw Linux, I'm going back to Windows!

From:
Date: 09/13/02 

Date: Fri, 13 Sep 2002 23:27:55 +1000

> > I've seen a Unix varient machine with a motorised floppy drive (ala
> > some Mac's), and no eject button at all. We just typed 'eject' when
> > we wanted the disk back. (Or 'eject /floppy', 'eject .', etc. as
> > appropriate)
> Yes, sun sparc stations with solaris works that way. It is some
> time since I last used one, so I don't remember exactly how it
> worked. But it never gave me the same feeling of a well designed
> system that I had with the Amiga, but I don't actually remember
> exactly what I disliked.

That sounds familiar. Wasn't too excited at it myself, but the floppy idea
was kinda novel.

> > In our case, the disk was automounted on insert (as root, world
> > usable), and autoejected when the system was shut down.
> That sounds like a nice idea. In particular the autoeject on
> shutdown is nice on drives with no mechanical eject. Though we
> should be carefull about that with tray loaders typically used
> for CDs. I never saw a trayloader for floppies, does such a
> thing exist? I know there does exist some rare CD drives using
> caddies instead of tray loading, for such drives ejecting on
> shutdown would also be nice.

Another type is the CD that does it the same as most car CD's, using neither
caddy nor tray. Also not very common, but they do exist.

But in most cases, autoeject would be nice. I've lost count of the number
of times I've needed to start up the computer just to eject a CD.

> > And besides which, I was under the distinct impression that most
> > of the decent file system browsers were smart enough to
> > automatically mount/unmount a floppy.
> I don't consider that to be smart. It is actually plain
> annoying. The system is not prepared to handle a mounted
> media getting removed, and now you have the drive getting
> mounted behind your back causing all kinds of troubles.

Well, not really. The drive gets mounted when you open up window showing
you the files on the floppy disk. Then when you close the window, it
unmounts the disk. Presumably you wouldn't eject the disk while the
window's open. But I agree that it doesn't help any when you're using a
VC...

> > I know the one I use under Gnome does - so as long as you close
> > the window before you press the button, there's no problem.
> Insert a CD. Now gnome mounts the CD and opens a browser
> window. Really annoying.

Urgh. I've always hated that under Windoze... I *DO* hope Gnome lets you
disable that bad habit.

> With no CD in the drive, I have seen the following happen:
> - Every 10 minutes, cron calls rmmod -a.
> - The module unloader decides the CD driver is no longer
> needed, and unloads it.
> - 10 seconds later gnome probes for a CD.
> - The kernel doesn't have a driver for the device and
> thus executes the module loader.
> - The module loader loads the module.
> - A message from the driver pops up on the screen.

Gnome's probing of the drive doesn't count as module usage? I'd have
thought that as long as Gnome's probing interval was less than the modules
unused timeout, it wouldn't happen.

> But we need some kernel support. A virtual block device,
> that can be bound to physical devices on command, might be
> what we need. It should be possible to disasociate the
> physical device from the block device even when it is
> mounted, in that case our userspace application should be
> notified if any process needs to access the drive.

How about a symlinik? I'd think that simply having a directory containing
symlinks associating the drive's label and/or serial number to the physical
drive, would do. If it's made and broken by the mount process, it should be
pretty reliable. Even a virtual block device would need to be created and
deleted as appropriate. Unless you did something similar to the
automounter. And even then, making it appear as a symlink should work just
fine, with the added bonus of making it easy to determine the hardware
device we're referring to.

> We also need automatic remounting between readonly and
> readwrite. The remounting from readwrite to readonly can
> be done periodically every second, though help from the
> kernel would be slightly more efficient. But the other
> way is needed on demand. Of course this feature must be
> optional, we still want to be able to make a usual ro
> mount.

Indeed. Though if we're going to jump between readonly and readwrite all
the time (which would requre kernel support), may as well just make a hybrid
writeback mode -- someone suggested "semi-sync", or being a C programmer, I
suggested "volatile". Regardless of name, the concept is simply to write
all the apropriate metadata to "close" the filesystem right after all
avaliable data writes have been completed. Presumably should new data
become avaliable for writing before the closure is completed, the new data
would be written immediately and the process of closing the filesystem
simply restarted right after.

It would, though, be advantageous for the system to be able to detect disk
insertion and removal, otherwise it would be neccesary for the driver to
verify that the correct disk was still in the drive before comencing a
write. Things could get ugly otherwise.