[OpenAFS] Re: Afs User volume servers in VM's

Jason Edgecombe jason@rampaginggeek.com
Wed, 26 Oct 2011 14:58:05 -0400


On 10/26/2011 02:48 PM, Jason Edgecombe wrote:
> On 10/26/2011 11:57 AM, Andrew Deason wrote:
>> On Wed, 26 Oct 2011 17:26:55 +0200
>> Stephan Wiesand<stephan.wiesand@desy.de>  wrote:
>>
>>> Running multiple fileservers on different ports on the same system
>>> would be even more efficient. Is this possible or could be implemented
>>> (in theory)?
>> In theory, of course. You just need a way in the fileserver to specify a
>> port, vldb modifications to store a port for the fileserver, and the
>> protocol modifications to communicate a port to the vldb and to clients.
>> You know, "just" all that :) The prerequisites for the vldb
>> modifications have already been discussed a bit on the standardization
>> list.
>>
>> That would of course limit the amount of clients that can actually
>> access that fileserver, since no clients today can do any of that.
>>
>>> What would be a great feature to have is a way to keep the server from
>>> using more than, say, half of the available threads for a single
>>> volume. Would this be feasible to implement at all?
>> Sure. Well, sort of. The server can obviously keep track of which calls
>> are associated with what volume (and already do post-1.6, for
>> -offline-timeout functionality), so if the number of calls is greater
>> than "X", we can just not service the request.
>>
>> However, the way to do that is to return a VBUSY error to the client
>> ("busy; try again later"), which cause the clients to sleep and retry
>> after some number of seconds (and make them log those "busy waiting for
>> volume" messages). And we only do that after we've obtained some kind of
>> reference to the relevant volume, which is after a considerable amount
>> of processing has been done. Maybe we could check that a bit earlier,
>> but the point is we'd have to receive the call and return an error if
>> we're over quota for the volume, which takes some extra processing; we
>> can't, like, direct calls dealing with volumes to a certain subset of
>> threads or something. But I guess that's probably not a problem; it
>> could make things worse in some situations but better in others.
>>
> I vaguely recall a hard limit to the number of file servers in a cell. 
> That number is 127 if I'm correct.
>
> Is that the case?
nevermind. I didn't read the whole thread before posting.