[OpenAFS-devel] Re: [OpenAFS] namei interface lockf buggy on Solaris (and probably HP-UX and AIX)

[Rainer Toebbicke]

Ken Hornstein wrote:

> 
> Whew, you ain't kidding.  When I looked at that, I believe a lot of it
> was the link table.  I have been idly thinking about simply removing
> most of those fsync() calls, or collapsing a whole bunch of them ... it
> would probably speed up operations like volume clones a whole lot.  A
> few thought experiments made me think that perhaps the consequences of
> an incorrect link count aren't so catastrophic that that salvager
> couldn't easily recover from it ... but AFS has fooled me before, so
> I'm not convinced of that yet :-)
> 

We've been running since several years with syncing gradually reduced 
to now all syncs batched and done as a precaution in a separate 
thread, every now and then.

All vos operations speed up a couple of hundred times on big volumes, 
life would be impossible without that (we have volumes of 1 million 
files). Furthermore we had a performance requirement for creating so 
many directories with one file per second which was not reachable with 
all those syncs.

 From what I understood from the namei code the link table sync does 
not eliminate the need for a salvager in case of a crash, there's 
always a window. And even with a sync, how about a power cut and disk 
caches, RAID systems, and the like.

I'd like to see a scenario where the salvager would get the link file 
grossly wrong, like such that a volume goes when you remove its backup 
clone (horror). And then the proof that the fsync would have prevented 
that for good, not just made it "less likely".


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155