On Mon, 2006-12-04 at 19:12 +0200, Janne Karhunen wrote: > > 2) NFS provides persistent storage. > > To me this sounds like a chicken and an egg problem. It > both depends and provides this at the same time :/. But > hey, if it's supposed to work then OK.
??? Locking depends on persistent storage, but persistent storage never depended on locking. Neither rpc.statd nor lockd, nor the nfs client depend on locking working a priori. > Anyhoo, I tried this at some stage and failed as random > clients seemed to occasionally get stuck in insmod¹ at > boot (infinite wait on lock that never gets released). > At that stage guess was that server could not properly > recognize client reboot given stale client lock data. > But if it's supposed to work I guess I have to give it > another shot and do better analysis on it. > > What about NLM/NSM protocol issues - do they properly > deal with packet loss and clients that stay down (client > holding a lock crashing and staying down; will the lock > ever be released)? 1) Packet loss is dealt with by retrying ad-infinitum. 2) No. The problem of client crashes was fixed in NFSv4 with the addition of lease-based locks. > ¹ And why does insmod require a lock on module at load?? Does it? I've no idea why it should need that. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/