On 12/10/2010 03:22 AM, Fred Isaman wrote:
> Recent changes to close can delay pending layoutcommit until umount,
> when the async layoutcommits can come tricklng in after we have destroyed
> the session.
Then "Recent changes" are broken and should be fixed. It was fine
before. New broken code is not acceptable.
> Since file does not need them, just turn them off for
> the moment. Non-file layouts will probably have to trigger them in
> some fashion at close.
>
Rrrr. Are we back to this argument. We stand down win an argument
and 2 weeks later you are back on it has if we never talked about it.
NO!!! only "coherent clustered filesystems" do not need them. It has
nothing to do with layout type. A none-clustered aggregated parallel
filesystem will need them just the same as blocks and objects.
AND THE STD DOES NOT GIVE YOU A CHOICE!!!
> A better solution is to just push all the layoutcommit code outside
> of the pnfs-submit branch. This is really just a stop gap until code
> is rearranged to make that easier.
>
Than all this is not finished. Please keep it in the shops until the
final solution is presented and we can actually see the new compared
to the old system. Until then we should keep what worked and was tested.
Boaz
> Signed-off-by: Fred Isaman <iisaman@xxxxxxxxxx>
> ---
> fs/nfs/nfs4proc.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 9b15535..224bdfe 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -3098,7 +3098,6 @@ static void pnfs4_update_write_done(struct nfs_inode *nfsi, struct nfs_write_dat
> {
> #ifdef CONFIG_NFS_V4_1
> pnfs_update_last_write(nfsi, data->args.offset, data->res.count);
> - pnfs_need_layoutcommit(nfsi, data->args.context);
> #endif /* CONFIG_NFS_V4_1 */
> }
>
--
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
