How to get usbd to umount fle systems without crashing ?

[Joseph Davida]

Providing an FS option to mount such devices
with all synchronous updates (data and metadata)
is a much safer and easier. All that you would
need here is that unplugging the device would
trigger an event which would lead to unmounting
the device automatically with a much
lesser chance of losing
any data from unwritten buffers belonging to the
device. Data could still be lost if say you
were copying large files from some other
drive to the USB stick device. Of course, if
processes had open file descriptors in such
a filesystem , an unplug event should be
handled by returning an error to all
processes with open file descriptors that
attempt to read/write such files, but should
still lead to unmonting the device.

Seems to me the scheme you describe
requires yet another facility in the
kernel to monitor activity
(or inactivity) of a filesystem, change the
superblock fs structure contents
(fs->fs_ronly)...etc which would require yet
another slowdown in the kernel: i.e.
synchronizing with processes.
I imagine it would require that a kernel
watchdog timer (which would set the FS to RO)
synchronize with the sync()er, softupdates,
the pagedaemon, the bufdaemon, and possibly
others, in order to implement the safe
transition of fs_ronly from
0 to 1, and back again from 1 to 0.

Also, what if the device is mounted read only
for the purpose that no one should modify it's
files? The scheme you describe, even if it were
cleanly implementable, would override
that and defeat the purpose.

My $.02's worth :)

Cheers,

Joe

--- Stefan Eßer <se at FreeBSD.org> wrote:

> On 2004-09-20 10:49 -0700, Joseph Davida <jd10008 at yahoo.com> wrote:
> > For these devices (memory sticks), a new
> > option to mount is needed.
> > Currently the default mount is
> > noasync. From mount(8) man page:
> > noasync
> >         Metadata I/O should be done synchronously,
> >         while data I/O should be done asynchronously.
> >         This is the default.
> > 
> > What we need is an option like "noasynchdata"
> > or "synchdata" to force all IO (data and metadata)
> > to be synchronous to these USB memory sticks.
> > This will enable us to hot unplug a memory stick
> > and the OS should automatically unmount
> > the device (I dont know if automatic umount
> > is currently implemented).
> 
> I'd often wanted to have an option that re-mounts a drive R/O after
> some period of inactivity (say, one to three seconds), and which
> switches back to a R/W for the next write request. An implicit fsync
> of all files open for writing on that device is required (which may
> possibly restart the time-out, if (meta-)data has to be written).
> 
> Different from an "mount -u -r" is that files may still be open for
> writing (next write to the device should immediately cause the in-core
> superblock to be marked dirty again and to be written to disk).
> 
> The intent is to mount any removable media (USB stick, hot-pluggable
> disk drive, floppy) with that option and to have the filesystem
> super-block marked clean as soon as the device has not been written to
> for a few seconds.
> 
> I have not thoroughly looked at the complexity of implementing such a
> filesystem option, but I guess that most of the functionality is already
> there:
> 
> An implementation could consist of a time-out handler that calls VFS_SYNC
> when there haven't been any writes during the configured period of time.
> 
> Initially and as long as the super-block is marked clean, fs->fs_ronly
> should be set.
> 
> In the error handler that is invoked when attempting to write to a R/O
> filesystem, the new mount option should be checked, causing an update to
> R/W and the start of the time-out mechanism that will eventually cause
> the downgrade to R/O, completing one iteration of the loop.
> 
> During an attempt to upgrade the mount to R/W, the super-block must be
> verified to match the actual device (it could have been exchanged). In
> case of a mis-match (or the device or media having been removed), a forced
> unmount of the filesystem is required, which will cause all further attempts
> to read or write files on that filesystem to fail.
> 
> Did I miss anything?
> 
> Regards, STefan
> _______________________________________________
> freebsd-mobile at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe at freebsd.org"
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail