From: Stef B. <st...@gm...> - 2011-06-10 11:32:33
|
HI, you can do anything with FUSE, but isn't the problem here the decoder using a lock, cause of reasons you've descibed. It cannot hanlde fifo queueing, what causes this. So I suggest the problem lies with the decoder, it should be able to handle on a fifo basis, and what Goswin is suggesting ( generation number, is currently not used) is a step towards this, to make the decoder aware a request is part of a serie of request. If this key isn't there, it's dealing with random access, if it unlocks the mutex it should look for the first on basis of the generation number...... how I do not know, but I guess this is a good sollution. Same problem with access to cdrom. Stef 2011/6/10 Goswin von Brederlow <gos...@we...>: > Michael McTernan <Mic...@cs...> writes: > >> On 08/06/11 16:41, Miklos Szeredi wrote: >>> Michael McTernan <Mic...@cs...> writes: >>>> Miklos kindly said he'd have a look at it again, so it would be >>>> interesting to know how it changes your filesystem's performance. >>> >>> Yes, it would definitely be interesting to do some experiments with >>> this. >>> >>> There's one fundamental problem with Michael's patch: it uses fi->fh as >>> a key to select a thread. This works most of the time but is >>> conceptually wrong. The file handle is supplied by the filesystem >>> implementation and libfuse should not use it or assume anything about >>> it. >>> >>> The alternative is to implement this on top of the low level API, >>> forwarding calls to another instance of this API. >>> >>> Thoughts? >> >> Yep - the fh hash is a total hack, but it keeps the changes very local. >> There's also a bit of overhead on cracking the message to get at fi->fh >> and then computing the hash - small, but not strictly necessary. >> >> Given full freedom to change anything, I would prefer to keep most of >> the patch, but add another identifier to the kernel<->userspace >> interface. This could be something like a fi->wh e.g. a worker-handle >> internal to libfuse. New requests from the kernel would pass 0 meaning >> that userspace can dispatch to any free worker thread. Operations that >> use a handle (i.e. have fi->fh) can then pass the kernel back a non-zero >> fi->wh to identify an elected worker thread. Further operations on the >> fi->fh would then be sent to the same thread using the associated fi->wh. > > Why not use the inode and generation number? > > MfG > Goswin > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > |