Re: How to get usbd to umount fle systems without crashing ?

On 2004-09-20 10:49 -0700, Joseph Davida <[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"