Fwd: [PATCH] pnfs-obj: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Finally the right email address this time

Sorry
Boaz

-------- Original Message --------
Subject: Re: Fwd: [PATCH] pnfs-obj: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done
Date: Tue, 14 Jan 2014 17:10:58 +0200
From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
To: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
CC: Stable Tree <stable@xxxxxxxxxx>, NFS list <linux-nfs@xxxxxxxxxxxxxxx>

On 01/14/2014 04:58 PM, Boaz Harrosh wrote:
> Sorry forgot to CC Stable Tree <stable@xxxxxxxxxx>
> 
> Greg hi
> 
> In Linux v3.9 there is a conflict around this area exactly do to change:
> 	[30005121] NFSv4.1: LAYOUTGET EDELAY loops timeout to the MDS
> 
> If there are stables below 3.9 please tell me I will send you a patch
> for these.
> 
> Thanks
> Boaz
> 
<>
> Subject: [PATCH] pnfs-obj: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done
> 
> 
> An NFS4ERR_RECALLCONFLICT is returned by server from a GET_LAYOUT
> only when a Server Sent a RECALL do to that GET_LAYOUT, or
> the RECALL and GET_LAYOUT crossed on the wire.
> In any way this means we want to wait at most until in-flight IO
> is finished and the RECALL can be satisfied.
> 
> So a proper wait here is more like 1/10 of a second, not 15 seconds
> like we have now. (We use NFS4_POLL_RETRY_MIN here)
> 
> Current code totally craps out performance of very large files on
> most pnfs-objects layouts, because of how the map changes when the
> file has grown and spills into the next raid group.
> 
> CC: Stable Tree <stable@xxxxxxxxxx>
> Signed-off-by: Boaz Harrosh <bharrosh@xxxxxxxxxxx>

Trond hi

I'm sitting on this bug for over 6 month now. I completely forgot about
it until QA moved to new Fedora and a vanila Kernel which is missing this
fix.

This is a real bummer for objects, in the case of large clusters for example
a Panasas cluster with two shelves and up. So on big clusters where performance
should be better, but with out this fix it is miserably unacceptedly slow.

Thanks
Boaz



--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]