Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Oct 2002 16:26:41 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Gregory Bond <gnb@itga.com.au>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: unmounting disabled with writeprotected floppy 
Message-ID:  <200210300026.g9U0QfQW012243@apollo.backplane.com>
References:   <200210292337.KAA25179@lightning.itga.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help

:> I think a write-protected floppy should _not_ be allowed to be
:> mounted _writeable_ at all. It should either not be mounted at all
:> or be mounted readonly implicitly.
:
:This is a hardware limitation.  The only way to discover a floppy is 
:write-protected is to try and write to it and get an error back.
:

    My take on this whole thing is:

    * There is a generally recognized problem with user-inserted media.

    * Some potential solutions clash with the necessity that the OS
      keep its representation of the data in a sane state, and the OS
      really does not currently have a good/safe framework to deal with the
      situation (error'd dirty write buffers).  Such a framework is not
      as simple as you might think.  Consider async writes on a softupdates
      managed buffer for example.  Wishing for it isn't going make it happen.

    * The best overall solution to the floppy issue, in my view, is to be
      able to throw away the dirty write-error'd buffers at umount time,
      and to perhaps mark them in a way that reduces the system's constant
      attempts to write them out while the mount is still active so it
      does not intefere with unrelated system operation.

    So.  Maybe a BX_HADWRITEERROR flag to begin with to indicate historical
    write errors (B_ERROR cannot be used for this purpose), and a flag to
    umount that tells it to get rid of any dirty buffers with 
    BX_HADWRITEERROR set, allowing the umount operation to succeed.  That
    seems to be a reasonable interim solution (and one that would not have
    to be ripped out later if a more involved solution is implemented).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210300026.g9U0QfQW012243>