The AFS client caches volumename:volumeID# -- when asked to
process the mount point it assumed old volumeID#, which no longer
existed.
The cache expires every two hours by default, IIRC.
In any case, issue "fs checkv" to force an update of the cached
name:ID maps, and I suspect that will fix
On Fri, 5 Nov 2010 11:04:32 -0400
Thomas Briggs wrote:
> I wanted to purge the files in the account and start with a clean
> volume, so :
>
> ---
> fs rmmount team1
> vos remove fs1 a user.team1
>
> vos create fs1 a user.team1
> fs mkmount team1
>
> ---
>
> This results in a mount point w/out
Here's the scenario: I had a volume, "user.team1" created, and mounted on a
directory "team1"
I wanted to purge the files in the account and start with a clean volume, so :
---
fs rmmount team1
vos remove fs1 a user.team1
vos create fs1 a user.team1
fs mkmount team1
---
This results in a mo
On Fri, Nov 5, 2010 at 5:11 AM, Simon Wilkinson wrote:
>
> On 5 Nov 2010, at 07:44, Andrej Filipcic wrote:
>
>> the current openafs 1.4.12.1 does not compile the libafs module with kernel
>> 2.6.36, although it does with the latest stable branch. What is the schedule
>> for the next stable release
On 5 Nov 2010, at 07:44, Andrej Filipcic wrote:
> the current openafs 1.4.12.1 does not compile the libafs module with kernel
> 2.6.36, although it does with the latest stable branch. What is the schedule
> for the next stable release?
If you can identify the changes that are necessary for 2.6
Hi,
the current openafs 1.4.12.1 does not compile the libafs module with kernel
2.6.36, although it does with the latest stable branch. What is the schedule
for the next stable release?
Cheers,
Andrej
--
_
prof. dr. Andrej Filipc
