Hi, Boaz, On Tue, Aug 23, 2011 at 7:24 AM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > On 08/17/2011 06:42 AM, Peng Tao wrote: > <snip> >>> They look *really* good these patches. But as you said, do they actually work? >>> >>> Did you test any of this? I mean do you have a facility to inject random >>> IO errors and test this out? >> I have tested the patchset by forcing all bio to fail so IO will be >> re-send to MDS. Also I tested read/write by forcing all IO that >> touches pages beyond 16K to fail. Both tests passed. >> > > So that sounds good. Why don't you like these patches? Well, I do like them :) > >>> > <snip> >> I tried to test "git clone linux" on a 384M memory VM but it hangs as >> server is rejecting layoutget with NFS4ERR_LAYOUTTRYLATER. >> /proc/self/mountstats shows that client has sent more than 14K >> layoutgets but never returns any layout. I checked related code and it >> seems client should send layoutreturn for closed files. Will git keep >> all files open? Or is there any case that client won't return the >> layout even after file close? >> > > Yes! our client will never ever return any layouts. The forgetful > model for you. It will only ever "layout_return" on evict_inode which > is way after close, when the Kernel decides to cleanup the inode > cache. Which only happens after a while. > > If Your layout driver sets the RETURN_ON_CLOSE bit on the layout > then the pNFSD server code will simulate a layout_return on a file > close. This is what I use in EXOFS and it works very well. (I should > know because I wrote this patch for the pnfsd server) > > It looks like your blocks-based pNFSD filesystem needs layouts > returned. Set the res->lg_return_on_close = true; flag in your > .layout_get member and you should see layout_return on close. > > Look in Benny's pNFS tree at fs/exofs/export.c file how I do > it there. Thanks for the explanation. Setting return_on_close may lose the chance to reuse layout segments for reopen cases. I will look into it more closely. > >> This seems to be another issue though. >> > > Yes this is a different Issue. > > It looks from what you tested that the second approach works > well. I'll also test this out later on. Lets not rule these > out yet. Thanks again for helping to test them. Cheers, Tao > >> Thanks, >> Tao > > Sorry for the late response I just came back from Vacation, > It'll me some time to catch up > > Thanks > Boaz > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
