Re: cross-device copying / USB improvements

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:dear dragonflyers!
:
:first of all: congratulations for such a great release!
:
:I tried hammer and it worked without a glitch, 
:and I tried USB plugging deplugging, replugging
:and was impressed that the shaky USB implementation 
:inherited from FreeBSD has finally been stabilized!
:
:So this is a mixture of a bug report, a success report and
:some ideas how to improve the user experience :)
:
:I tried the following: 
:- plug in a USB stick
:- mount -t msdos /dev/da0s1 /mnt/usbstick
:- cd  /mnt/usbstick
:- ls
:- unplug the stick
:... lot of warnings, but no panic
:- ls 
:=> shows the old content, even if the stick isn't there any longer
:- dh
:=> shows /mnt/usbstick still mounted
:- plug in USB stick again
:=> surprise! now is da1 ! (same slot though)

    Yah, because there are still references on da0.  Even though
    the filesystem has failed you still have to unmount it.
    (umount -f ought to work, theoretically).

:here I was able to unmount the "ghost" mount on /mnt/usbstick
:and to remount the "new" da1 under /mnt/usbstick again.
:
:however, I then tried to unplug the device while copying a larger 
:file to it. 
:no panic, but when I did
:        ls /mnt/usbstick
:the system froze.
:
:I think it could be related with the fact that ls showed the old 
:files on the previous test (some caching issue?).

    Possibly.  More likely its because the buffer cache filled up
    with dirty buffers which couldn't be flushed because the
    device was pulled.

    There still needs to be some work done in the that regard,
    like to try a few times and then discard the buffer.  There's
    a problem though in that the buffers represent modified meta-data
    that is synchronized with the mount.  If the kernel throws the
    buffers away the filesystem mount could become even more confused
    then just getting I/O errors.

:- would be silently* umounted when the device is plugged off, 
:  so ls should show nothing in the path

    I think an auto-unmount of some sort would be a good idea.
    It would probably solve the remaining panics/lockups.

:- would put the processes trying to access the device into a 
:  waiting loop
:
:- would be silently* remounted if the same device** is plugged in 
:  again in the same slot within a certain timeframe (the 10 seconds)

    Not possible.  Once the filesystem gets that many fatal errors
    due to the device being unplugged it is pretty much a lost cause.

    If the filesystem were idle when the device got unplugged we might
    be able to swing it.  That's a big if.

:- would return errors to the waiting processes after the timeout
:
:This would be a cool way to "recover" from accidently interrupted
:connections or unreliable devices.

    Yah, but I don't think it is in the cards.  There is no way
    for the kernel to know what buffers actually made it to the
    device or not.

:Just a thought. My experiences with C are very limited, so I do not 
:qualify to implement such a beast, nor do I know how difficult it is
:or if it might break Posix.
:
:Whow, that one got longer than expected.
:
:Anyway: keep up the great work!
:
:Regards,
:Benny

    They are all good ideas :-)  Just not so easy to implement.

						-Matt