On Nov 20, 2006 16:41 -0800, Nathaniel Rutman wrote: > >Sounds like a good start at least. Would the addition of separate > >operation modes like "connect only", "enqueue locks", etc be straight > >forward? > > > connect, create/destroy, c/write/read/d would be easy. locks - locks > divorced from these operations?
Yes, it would be desirable from a load/test POV to create thousands of locks on a single resource, millions of locks in total, to verify behaviour before & after scalability changes are done for the DLM. It would be inconvenient to have to have thousands of clients to test this. > >I think once you are running thousands of your clients on a single node > >it will inevitably have problems because of task switching latency, > >swapping, etc. That said, if we can reasonably simulate some hundreds or > >thousand(s) of clients per node this should give us the ability to simulate > >any reasonable sized cluster. > > Which leads me to a Q: apparently the echo ioctl's expect immediate > results (within lock > or obd timeouts (I should investigate)) but shouldn't real client VFS > ops just block? > Say everybody is writing to 1 disk, faster than the disk can go. I > would not expect errors, > but instead slowed responses. Pings in this case would continue to be > returned in a timely > manner, so I would expect that both the client and the server would both > agree that nobody needs to be reconnected or evicted. This is why we are working on adaptive timeouts. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
