In message <[EMAIL PROTECTED]>,Tom Keiser writes: >Have you ever taken a close look at FetchData_RXStyle in >afsfileprocs.c? Did you notice how it calls readv(); rx_Writev() in a >tight loop? Did it ever occur to you that this is horribly >inefficient? What is the kernel disk io scheduler doing when we're >busy in a sendmsg() syscall? If it actually bothers to do something,
the fileserver is threaded. i would call it somewhat similar to an nfs file server. several threads are waiting for requests. when one is busy the others are free to handle requests. thus the tuning for number of nfsd's in early servers. >No. Optimal read-ahead knowledge does not exist, courtesy of the >halting problem. Of course, the fileserver's kernel knows less than the fileserver basically knows how much a client has requested and that it can only fulfill a certain fixed amount per fetchdata. if the client made a request bigger than this fixed amount, i suppose the fileserver could read and cache that amount from the file the knowing that the client will just ask for the rest. i suppose you could just read the "right" amount anyway and rely on your operating system's disk block caching to keep the data available for subsequent calls. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
