On 3/2/2013 3:48 AM, Simon Wilkinson wrote: > >> >> I also find this notion that callback revocations could be used in an >> amplification attack silly. The CM is not going to respond to every >> RXAFSB_CallBack() with RXAFS_FetchStatus(). It will only do that the next >> time that afs vnode is touched by a client > > The discussions around 'pinning' support for disconnected AFS came up on > doing exactly this as the only real option for implementing pinned vnodes on > clients without XCB. Significant concerns around about server load and > callback storms mean that it has not yet been implemented. However, I don't > think the idea that a client might respond to a callback break with a fetch > status is that far fetched.
Any afs client that provides support for the operating system's file
change notification service (as Windows has done since IBM days) will
issue FetchStatus events in response to callbacks. These storms are
real and the Windows cache manager goes to great extent to filter
incoming callback messages by known file servers and callback issuers
explicitly in an attempt to avoid storms that plagued universities
around 2005.
In fact, one of the motivations for extended callbacks is reducing the
impact of these storms.
1. explorer shell enumerates the contents of a directory
2. explorer shell issues directory tree change notification
on a directory
3. explorer shell begins to enumerate the child directories
4. callback is broken
5. since reason is unknown and cache manager no longer has
current status, notification handle is canceled signalling
the explorer shell that a change occurred without specifying
what changed.
6. explorer shell returns to step 1 and repeats.
With XCB, the ability to notify the explorer shell of what changed
avoids an RPC storm.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
