On Wed, Apr 18, 2001 at 12:56:00PM -0600, Gordon McNutt wrote:
> 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.
Media change notification is accomplished in the usb world by setting the
user attention bit, which causes media-access commands to fail until a
request sense command is sent, and the device transmits it's sense data.
That sense data will have the sense codes for a media change.
I suggest you read the SCSI-II specification for more details.
> > 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?
On media or in memory doesn't matter. It's the async modification that's
the problem.
And no, there is no event notification interface. The model is based on
SCSI-II. See above for how this works.
> 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.
No locking commands. Locking is implicit, since there is a "master" and a
"slave". If the camera can modify the data without the PC, then it's also
a "master" and you have a problem.
> 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.
That's the right answer.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
YOU SEE!!?? It's like being born with only one nipple!
-- Erwin
User Friendly, 10/19/1998
PGP signature
