-----Original Message-----
From: James Sutherland [mailto:jas88@cam.ac.uk]
Sent: Tuesday, June 13, 2000 9:35 AM
To: Steve Holdener
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: Floppy Handling
On Tue, 13 Jun 2000, Steve Holdener wrote:
> Quoth Billy Harvey:
>
> - What is needed is a program which when called will dd the image of the
> - floppy just inserted into a file, in some specified location, perhaps
> - /var/floppy-`date +%s`, for example. with ownership assigned to
> - whomever did the calling.
> -
> - Once the dd is complete, the floppy must be removed, this file is then
> - mounted using loopback. Removal of the floppy will force the newbie
> - to realize that the data being operated on is not physically on the
> - floppy.
> -
> - Once the work is complete, there is a similar reverse process, which
> - can check to ensure that either a blank floppy or the same floppy is
> - used, that will call for the floppy to be inserted, and then will
> - dd the file back to the floppy, and then call for it to be removed.
> -
> - The image file can then be either automatically umounted and deleted,
> - or alternatively marked in some way so that if it is kept mounted and
> - further written to, it will be considered dirty, annotating a need for
> - a further sync to the floppy.
>
>
> I like the idea, but the dd takes too long. I'd hate to wait for
> 1440K to transfer just so I can access a 1K file--on read AND write.
> Perhaps if the file could be opened immediately so the user can get
> working and the dd is run in the background...It still seems like a
> lot of work. And what if the user did want to read off one disk,
> edit, and write to a new disk?
>
>Yep. The idea's not quite there yet...
>
> It strikes me that, to be consistent with the typical conceptual model
> a user has of the floppy, it might be more appropriate to perform a
> mount/read/umount to open a file. Saving a file would, of course, be
> a mount/write/umount procedure. This makes removing/swapping floppies
> between opens and saves safe and does so w/o any (much?) added
> complexity.
>
Better, certainly...
>
> There is, certainly, the drawback that buffering writes to the disk
> becomes ipossible. But it achieves *predictability* for the user.
>
>OK, how's this:
>
>User inserts disk and opens a file on it, then reads the contents.
>Disk contents get cached (to VM), starting with the bit being used.
>User can now read/write to/from the disk freely, at HDD speeds.
>The cached image is written through to the disk when possible; if the disk
>is removed prematurely, an error is displayed - but I/O can continue,
>since it uses the cached image.
>
>Once another disk has been inserted, and the image is in sync with the old
>disk, the image is discarded.
>
>Thoughts?
>
Been watching this thread for a while now... here's my take.
1. Floppy is inserted. There can be a total of three things the user wants
to do, read a file,
write a file, list directory contents of floppy. Need to handle each
possible branch. Also, we'll need a standardized mount point for the floppy
(akin to a:), so each time a new floppy is inserted, the mount point will
always be the same. /proc/floppy? /var/disk/floppy-IDENTIFIER?
2. If the user goes for a direct file read, say through the Open Menu in
Star Office, we
a. Attempt to mount device under standardized mount point.
b. Attempt to read file, and cache contents in VM, as stated above.
c. Unmount floppy.
As above, the user can now read/seek at VM speeds. Problem now is periodic
writes to floppy. What if the user changes disks to load a file under a
different application? Once we open, cache, and close, the drive light will
go off and a windows user will think it's safe to remove the disk. If we
periodically flush to disk, then we'll have a) "Invalid Disk" Errors
everywhere, or b) Files mysteriously appearing on odd disks. The only real
way to write to disk is when the user explicitly saves work. Then attempt to
overwrite the file on floppy with the modified copy. If the disk has
changed, bitching is a possibility, or the attempt to write to floppy can be
made. My vote is to bitch.
3. If were going to try and do a directory read, mount floppy, readdir,
umount. Call for each subsequent "cd x;ls". May sound slow, however this is
how DOS handles it (if my dos memory is working today ;-). Cache directory
contents, and disk info in memory so we don't have to re-read for the same
floppy, clear this portion of cache memory should there be a write on this
floppy, so future readdir's are correct.
4. Writes to disk would be as explained in #2. Attempt to
mount/write/umount.
This type of thing could easily (well, in theory) be jammed in at the VFS
level, and could be incorporated for CD's, floppies, punch cards, Rosetta
stones, etc...
Just my take,
Jeff
>
>James.
>
>
>-
>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/
-
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:11 EST