headers
mmarion | 3 Sep 2004 23:31

Odd problem with a change not propagating..

Don't know if anyone's seen this, or if it's a known issue, but I made some 
changes yesterday where I changed a couple directories into symlinks..
i.e.
qt was a dir, changed it to:
qt -> .qt. <at> sys
with new .qt.i386_linux24 and .qt.amd64_linux26 paths.

On a couple of the amd64_linux26 hosts, the change is seen in rw space, but
not ro.  I've tried fs flush[v] on the paths and the parent.. doesn't seem to
help.  Only thing I know is that the hosts where this seems to have gotten
stuck.. are ones that had active jobs on them when the volumes were released..
those that were totally idle were ok.

Rebooting (or restarting arla.. if I can) seems to clear this up.

ls shows the problem:
Read-only:
preto066 mmarion {501}$ cd /pkg/qct/software/
preto066 software {502}$ ls -al | egrep 'qt|ssl'
drwxrwxrwx   2 root     root  2048 2003-09-17 15:54 openssl
drwxrwxrwx   2 root     root  2048 2004-09-02 17:05 .openssl.amd64_linux26
drwxrwxrwx   2 root     root  2048 2003-09-17 15:54 .openssl.i386_linux24
drwxrwxrwx   2 root     root  2048 2003-09-17 15:58 qt
drwxr-xr-x   2 root     root  2048 2004-09-02 17:45 .qt.amd64_linux26
drwxrwxrwx   2 root     root  2048 2003-09-17 15:58 .qt.i386_linux24

Read-write:
preto066 software {503}$ cd /.pkg/qct/software/
preto066 software {504}$ ls -al | egrep 'qt|ssl'
lrwxr-xr-x   1    90113 root    13 2004-09-02 16:51 openssl -> .openssl. <at> sys
(Continue reading)

Permalink | Reply | 9 comments |
headers
Massimo Marino | 4 Sep 2004 09:44
Favicon

AFS cache

On OS X 10.3.5 and Arla 0.36.2

I noticed that cache does not get flushed. Not even manually with 'fs 
flush'. Too many times I have to stop Arla and then start it again to 
be able to get current versions of files in AFS locations. Any 
trick/tip to avoid that or have Arla reflect current status files in 
AFS directories?

It seems I am always the last kid in the block to realize files have 
changed in AFS and newer versions are in place. When that happens it is 
invariably: Stop Arla, Start Arla. Annoying.

Cheers

Dr. Massimo Marino
NERSC Division - HPC Department
Lawrence Berkeley National Laboratory
On leave at CERN, PH Dept., Atlas & SEAL
✆: (+41) 22 767-1288 fax: (+41) 22 767-8350 ℗: 32-R-C24
✉: marinoATnerscDOTgov, MassimoDOTMarinoATcernDOTch
Permalink | Reply | 6 comments |
headers
Tomas Olsson | 4 Sep 2004 12:05
Picon
Picon
Favicon

Re: Odd problem with a change not propagating..

mmarion <at> qualcomm.com writes:

> Don't know if anyone's seen this, or if it's a known issue, but I made some 
> changes yesterday where I changed a couple directories into symlinks..
> i.e.
> qt was a dir, changed it to:
> qt -> .qt. <at> sys
> 
We had some reports about an invalidation problem when setting a new
sysname, could be the same thing. It didn't happen whenn I tried, and left
it at that for the time being. Setting a new sysname isn't a very common
operation. I'll take a look at it when I find the time.

> Only thing I know is that the hosts where this seems to have gotten
> stuck.. are ones that had active jobs on them when the volumes were
> released..  those that were totally idle were ok.
>
Good thing to know. If you happen to find a simple test case, please tell us.

Apart from this, is everything working well? What's you setup, usage, etc?

thanks
        /Tomas
Permalink | Reply | 1 comment |
headers
Tomas Olsson | 4 Sep 2004 12:07
Picon
Picon
Favicon

Re: AFS cache

Massimo Marino <Massimo_Marino <at> lbl.gov> writes:

> Too many times I have to stop Arla and then start it again
>
You shouldn't need to do that, fs flush* should be enough. The question is
when it happens.

/Tomas
Permalink | Reply | 0 comments |
headers
Harald Barth | 7 Sep 2004 09:18
Picon
Picon
Favicon

Re: AFS cache


> I noticed that cache does not get flushed. Not even manually with 'fs 
> flush'. Too many times I have to stop Arla and then start it again to 
> be able to get current versions of files in AFS locations. Any 
> trick/tip to avoid that or have Arla reflect current status files in 
> AFS directories?

I think Kaj and Tol found something. Can you check if you have therse
files open (with lsof for example) and if the files get updated as
soon as you don't have them open any more? In that case: What
application does typically hold the file open for you?

> Stop Arla, Start Arla. Annoying.

That will forcefully throw away all state. I don't know how friendly
that is to the applications that might have the files open.

Harald.
Permalink | Reply | 4 comments |
headers
Massimo Marino | 7 Sep 2004 09:24
Favicon

Re: AFS cache

On Sep 7, 2004, at 9:18 AM, Harald Barth wrote:

>
>> I noticed that cache does not get flushed. Not even manually with 'fs
>> flush'. Too many times I have to stop Arla and then start it again to
>> be able to get current versions of files in AFS locations. Any
>> trick/tip to avoid that or have Arla reflect current status files in
>> AFS directories?
>
> I think Kaj and Tol found something. Can you check if you have therse
> files open (with lsof for example) and if the files get updated as
> soon as you don't have them open any more? In that case: What
> application does typically hold the file open for you?

usually emacs. I checked that when that happens, even quitting emacs 
and reopening the file soon after the file is not updated unless I quit 
Arla and start it again.

>
>> Stop Arla, Start Arla. Annoying.
>
> That will forcefully throw away all state. I don't know how friendly
> that is to the applications that might have the files open.

emacs then warns that the file has changed on disk and asks for the 
usual instructions on what to do about it.

Massimo
(Continue reading)

Permalink | Reply | 2 comments |
headers
Harald Barth | 7 Sep 2004 09:44
Picon
Picon
Favicon

Re: AFS cache

> usually emacs. I checked that when that happens, even quitting emacs 
> and reopening the file soon after the file is not updated unless I quit 
> Arla and start it again.

Strange. Because:

* In the test we did it was updated after closing all handles and I
  might understand why holding the file open does prevent a cache
  update. Maybe some other application keeping the file open?

* My emacs does not hold the files I edit open (it does hold
  stuff like libs /usr/X11R6/lib/libX11.so.6.2 for example)
  and I use to have 20+ buffers in my emacs.

Harald.
Permalink | Reply | 1 comment |
headers
Massimo Marino | 7 Sep 2004 10:11
Favicon

Re: AFS cache

On Sep 7, 2004, at 9:44 AM, Harald Barth wrote:

>> usually emacs. I checked that when that happens, even quitting emacs
>> and reopening the file soon after the file is not updated unless I 
>> quit
>> Arla and start it again.
>
> Strange. Because:
>
> * In the test we did it was updated after closing all handles and I
>   might understand why holding the file open does prevent a cache
>   update. Maybe some other application keeping the file open?
>
> * My emacs does not hold the files I edit open (it does hold
>   stuff like libs /usr/X11R6/lib/libX11.so.6.2 for example)
>   and I use to have 20+ buffers in my emacs.
>
> Harald.

Harald, it is an intermittent problem. I have not nailed down why it 
happens when it happens. Also doing a 'less <file>' shows the old 
version (when it happens). 'fs flush' does not change the file. Could 
it be related to DHCP (wild guess) changed IP between connections?

	Massimo
Permalink | Reply | 0 comments |
headers
Tomas Olsson | 7 Sep 2004 18:31
Picon
Picon
Favicon

Re: building 0.37rc5 on MacOS X

Massimo Marino <Massimo_Marino <at> lbl.gov> writes:

> > configure CPPFLAGS=-DBIND_8_COMPAT
> 
> did that, then make stops (after lots of ok compilation and libs) with:
> 
> ka-procs.c:238: error: parse error before "DES_cblock"
>
That was with -DKASERVER_SUPPORT, right? In 0.37rc5 you're not supposed to
need that, it checks if you have a recent enough openssl. If so,
KASERVER_SUPPORT is set for you.

But the interesting thing is how to find the right openssl headers so we
find DES_cblock et al. Are there any peculiarities with those headers on
MacOS X? Versions?

/Tomas (adding Cc: arla-drinkers)
Permalink | Reply | 2 comments |
headers
Massimo Marino | 7 Sep 2004 18:43
Favicon

Re: building 0.37rc5 on MacOS X


On Sep 7, 2004, at 6:31 PM, Tomas Olsson wrote:

> Massimo Marino <Massimo_Marino <at> lbl.gov> writes:
>
>>> configure CPPFLAGS=-DBIND_8_COMPAT
>>
>> did that, then make stops (after lots of ok compilation and libs) 
>> with:
>>
>> ka-procs.c:238: error: parse error before "DES_cblock"
>>
> That was with -DKASERVER_SUPPORT, right? In 0.37rc5 you're not 
> supposed to
> need that, it checks if you have a recent enough openssl. If so,
> KASERVER_SUPPORT is set for you.
>
> But the interesting thing is how to find the right openssl headers so 
> we
> find DES_cblock et al. Are there any peculiarities with those headers 
> on
> MacOS X? Versions?
>
> /Tomas (adding Cc: arla-drinkers)
>

yes sorry: without -DKASERVER_SUPPORD and *with* -DBIND_8_COMPAT worked:
Attachment (Picture 1.pdf): application/pdf, 10 KiB
(Continue reading)

Permalink | Reply | 1 comment |

Gmane