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?
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:31 EST