From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom To: 9fans@cse.psu.edu, Ronald G Minnich References: <20263.1138166979@piper.nectar.cs.cmu.edu> <43D79B60.5010006@lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <43D79B60.5010006@lanl.gov> Subject: Re: [9fans] fuse bashing Message-Id: <20060126011647.755F078FBD@dexter-peak.quanstro.net> Date: Wed, 25 Jan 2006 19:16:47 -0600 Cc: Topicbox-Message-UUID: ea3e0558-ead0-11e9-9d60-3106f5b1d025 one could write a fileserver that allows you to give it a file to watch and either send a plumbmsg back or write a Dir structure back on the original fd when it changes. i'm not sure one needs to modify the underlying filesystem. actually making the notifier live outside the filesystem would allow many "notifiers" running against the same fs. say 1 fs 10 notifiers and 100 clients per notifier. - erik Ronald G Minnich writes | | Dave Eckhardt wrote: | >>The big complaints I know of so far on 9P are [...] | > | > | > If servers routinely dealt with thousands of clients and/or | > clients with large persistent caches then some sort of | > acceleration for cache validation might be nice--callbacks | > (aka leases) or maybe something based on a log of | > invalidations. | > | > But given current usage patterns it's not clear there's | > a need. | | | except here and some other sites, where there is a burning need, and | current parallel file systems are not quite working (yet) | | having enough thousand nodes all try to stat the same file, at the same | time, in a callback-based file system, can be trouble. | | | ron