I don’t think it will give the similar performance as ‘no lock’ scenario like here. But, I am really very skeptical about this FDCache stuff since in the random workload scenario it will miss the cache 99.99% of time. Only advantage of this FDCache I can think of in the IO read path where getattr followed by a read(). But even that will be missed  (depends on the high work load/FDCache size etc.) probably 70% of the time in the customer environment. I am sending this FD and the string upstream just to take care of this scenario i.e getattr followed by read() so that read don’t have to open the fd again. One problem with my logic is that since the FD is not closed till the following read call, in very high workload scenario the fd limit can reach. But, this needs to be stress tested.