Pete Zaitcev wrote:

> > From: Gordon McNutt <[EMAIL PROTECTED]>
> > Date: Wed, 18 Apr 2001 11:10:26 -0600
>
> > I've got to wondering about the mass storage profile, and how the host
> > f/s keeps in synch. I assumed the typical usage scenario was that the
> > host would mount the device and get access to stored pictures. But what
> > if the device snapped a new picture while it was mounted? How would the
> > host filesystem learn about it without unmounting/remounting?
> >[...]
>
> I know only one way to deal with this: trigger a media change on every
> update, in the same way a floppy does.

Thanks for responding, but I'm not certain what you mean. What do you mean
by 'media change' and 'update'? If you mean make the host filesystem flush
to the media any time it makes a change then that's not enough. It also has
to refresh its own data structures by rereading the media.


> Another fix is to use userland tools instead of a mounted filesystem
> (mtools).

Let's see... man mtool... Mm... so the userland tool implements the file
system operations... interesting.

Ok, but I think the essential problem remains: unless the file system
(wether it be kernel or userland) keeps all of its inode-type data on the
media (and not in data structures in RAM) then the mass storage profile will
have problems on devices that can asynchronously modify the media while
plugged in. For one thing, neither the mass storage protocol nor the
block-level protocol it transports have any kind of event notification model
whereby the device can tell the host it changed something. The only way the
host can figure it out is to go reread everything. And how often should it
do this?

And even if the host does keep all the inode-type data on the media I think
race conditions will still prevail. Perhaps if the mass storage or its
payload protocol had locking commands... but they don't appear to.

I've about convinced myself that mass storage won't work on a device like a
camera unless the device refrains from modifying the media while plugged in.

--gmcnutt


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to