I'm having trouble understanding the following.
-Rick
arctura vos remove -id rcc2.backup
Volume 536870926 on partition /vicepb server avoca01.serverfarm.cornell.edu
deleted
arctura fs rmm /afs/afsdemo.cit.cornell.edu/users/jim1/Yesterday
arctura vos backup rcc2
Created backup volume for rcc2
On May 20, 2010, at 17:36 , Rick Cochran wrote:
I'm having trouble understanding the following.
(elided)
I've seen that when Linux gets its dcache confuzzled; flushing the
dcache in various ways --- or, sometimes, the path, but I think that's
actually triggering the garbage dcache entries
On 20 May 2010, at 22:36, Rick Cochran wrote:
I'm having trouble understanding the following.
Does 'fs checkvolumes' solve the problem?
If so, my suspicion is that there's a caching problem somewhere, where the
client is caching the ID of the backup volume, and not invalidating that cache
Hello, John of printing fame!
After rehabilitating my typing fingers, as Andrew Deason suggests, I get
the following:
samuel ls /afs/.afsdemo.cit.cornell.edu/users/rcc2
afs Private Yesterday
samuel ls /afs/.afsdemo.cit.cornell.edu/users/rcc2/Yesterday
ls: cannot access
On 5/20/2010 11:25 PM, Rick Cochran wrote:
What I did previous to losing track of this backup volume was to move
volume rcc2 from one server to another. Should that cause this kind
of behavior?
-Rick
This is not the desired behavior.
Please file a bug report to openafs-b...@openafs.org so
