Re: [OpenAFS] Re: Writing allowed where it's not expected
On 9/20/2011 11:50 AM, Dirk Heinrichs wrote: > Thanks a lot for the clarification. Can this 2 hour delay be > configured somewhere? > > Bye... It is configurable in the Windows client. It is not configurable for the Unix client. Jeffrey Altman signature.asc Description: OpenPGP digital signature
Re: [OpenAFS] Re: Writing allowed where it's not expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 19.09.2011 16:39, schrieb Andrew Deason: > Yes, sorry, I read 'below' as 'above'. In this case, perhaps the > client still had old vldb information, which did not contain the RO > site? The 'vos examine' info for the RO said: > > CreationSat Sep 17 09:41:04 2011 CopySat Sep 17 > 09:41:04 2011 Backup Never Last Access Sat Sep 17 09:40:59 > 2011 Last Update Sat Sep 17 09:40:59 2011 > > And the original problem was seen around: > > % touch sw/foo % ll -g -n sw/foo -rw--- 1 100 0 2011-09-17 > 11:14 sw/foo > > Which is less than two hours later. If around 9:40 on Saturday was > the first time that RO had existed, you need to wait about 2 hours > to guarantee all clients will "see" the new RO (or you can run 'fs > checkv' on specific clients, to not need to wait). Thanks a lot for the clarification. Can this 2 hour delay be configured somewhere? Bye... Dirk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOeLZa8NVtnsLkZ7sRAvo8AKCy9/+JdQX+BwilOJOQrkjfYPbnZACfS58f yyJ5eFLSLzFwp4QeIvaE8wI= =XSTi -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Writing allowed where it's not expected
On Mon, 19 Sep 2011 10:20:49 -0400 Jeffrey Altman wrote: > On 9/19/2011 9:36 AM, Andrew Deason wrote: > > On Sun, 18 Sep 2011 10:20:05 +0200 > > Dirk Heinrichs wrote: > > > >> The only thing I did was to "vos release" _another_ volume that was > >> mounted below .../sw and which showed up as "not released" in the > >> output of "vos listvldb". Does this also count as "being on a > >> read/write path"? [...] > The state of foo.readonly should not impact the evaluation of > /afs/cell/sw. There clearly is something weird going on here. Yes, sorry, I read 'below' as 'above'. In this case, perhaps the client still had old vldb information, which did not contain the RO site? The 'vos examine' info for the RO said: CreationSat Sep 17 09:41:04 2011 CopySat Sep 17 09:41:04 2011 Backup Never Last Access Sat Sep 17 09:40:59 2011 Last Update Sat Sep 17 09:40:59 2011 And the original problem was seen around: % touch sw/foo % ll -g -n sw/foo -rw--- 1 100 0 2011-09-17 11:14 sw/foo Which is less than two hours later. If around 9:40 on Saturday was the first time that RO had existed, you need to wait about 2 hours to guarantee all clients will "see" the new RO (or you can run 'fs checkv' on specific clients, to not need to wait). -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Writing allowed where it's not expected
On 9/19/2011 9:36 AM, Andrew Deason wrote: > On Sun, 18 Sep 2011 10:20:05 +0200 > Dirk Heinrichs wrote: > >> The only thing I did was to "vos release" _another_ volume that was >> mounted below .../sw and which showed up as "not released" in the >> output of "vos listvldb". Does this also count as "being on a >> read/write path"? > > Yes. You can usually pretty quickly see which volume is causing the > "read-write path"-ness by running 'fs exa' or 'fs lq' on each parent > directory starting with /afs/ and working your way down. If I understand Dirk's situation, path that should have been rw was /afs/cell/sw/foo with volumes root.afs root.afs.readonly root.cell root.cell.readonly swsw.readonly foo foo.readonly (not properly released) In which case if normal mount points were used everywhere in the path, then /afs should be readonly, /afs/cell should be readonly, and /afs/cell/sw should be readonly but /afs/cell/sw/foo should end up read/write because foo.readonly was in an error state. The state of foo.readonly should not impact the evaluation of /afs/cell/sw. There clearly is something weird going on here. signature.asc Description: OpenPGP digital signature
[OpenAFS] Re: Writing allowed where it's not expected
On Sun, 18 Sep 2011 10:20:05 +0200 Dirk Heinrichs wrote: > The only thing I did was to "vos release" _another_ volume that was > mounted below .../sw and which showed up as "not released" in the > output of "vos listvldb". Does this also count as "being on a > read/write path"? Yes. You can usually pretty quickly see which volume is causing the "read-write path"-ness by running 'fs exa' or 'fs lq' on each parent directory starting with /afs/ and working your way down. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
