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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
