On Sat, Oct 22, 2016 at 4:00 PM, jd1008 <jd1008@xxxxxxxxx> wrote: > > > On 10/22/2016 12:14 PM, Gordon Messmer wrote: >> >> On 10/22/2016 06:13 AM, bruce wrote: >> >>> I've thought of having a "pid" file on the nfs, where each clientApp >>> would reset/lock/use the pidFile to then get/use/delete the file as >>> required, but this seems tb slow.. but doable. >> >> >> Probably. You'd have a bunch of clients periodically checking for the >> lock file before they do work. You'll lose some time to idling when one >> application finishes, before another application gets the lock and starts >> working. You may be better off having one process scheduling work, starting >> up or signaling an application when the data is available. You'll avoid the >> complexity of the locking, and possibly reduce idle time. > > So, you are suggesting: One process on the nfs server that knows about all > the files in question and waits for clients to ask for a file (any > file????), returns back to that nfs client an nfs handle for some specific > file chosen by the server, creates some flag somewhere (on the server) that > the file has been served to username xyz, uid cde, on client a.b.c. When > is finished with that file, does something like ask the server to delete > that file, or says to the server I am done with that file; at which point > server might delete the file per client request, or simply remove the flag > that the file is in use by username xyz, uid cde, on client a.b.c, ... and > so on. > Well, now you have another wait problem for each request for some unserved > file. In such a serial service of requests - clients might time out, and can > err out or simply retry. > What if the list of files is in the thousands? Serially serving said files > would be very time consuming. > > Parallel server processes: > The server process might be coded so that for each request, it forks a child > process to serve the request. > Now, child processes have to compete for a lock on the list of files to be > served, one of the children will succeed, and > set the flag (mark username xyz, uid cde, on client a.b.c has file > /filename/), serve the file, unlock the list and exit. Same client that > requested the file must then request the server to delete the file or tell > the server it is done with the file - again requiring the child server > process (not same child process that served the file, but a new child > spawned to handle the request) to lock the list + delete the file or simply > remove the flag of the client. > > On the surface of it, it sounds like this is a slow process. But it is not. > > A sever process that spawns children that compete for the list is a good way > to serve said files. ----- Hey JD! Thanks for the reply. I thought about having some sort of "nfs/server" side process that iterates through the list of files, and then determines when a "client" is ready, and pushes the file to the client. In having the clients, pull the file (set the pidFILE), there's the possibility that the pidFile, could be messed up, along with a few other minor issues, but it would be simple to implement. Thanks -b > > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
