From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morris Subject: Re: [PATCH 05/11] NFSv4: Add label recommended attribute and NFSv4 flags Date: Thu, 28 Feb 2008 12:52:48 +1100 (EST) Message-ID: References: <1204150294-4678-1-git-send-email-dpquigl@tycho.nsa.gov> <1204150294-4678-6-git-send-email-dpquigl@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hch@infradead.org, viro@ftp.linux.org.uk, trond.myklebust@fys.uio.no, bfields@fieldses.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: "David P. Quigley" Return-path: Received: from namei.org ([69.55.235.186]:49351 "EHLO us.intercode.com.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755234AbYB1BxX (ORCPT ); Wed, 27 Feb 2008 20:53:23 -0500 In-Reply-To: <1204150294-4678-6-git-send-email-dpquigl@tycho.nsa.gov> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 27 Feb 2008, David P. Quigley wrote: > +#define NFS4_MAXLABELLEN 255 I remember raising this before, but I think we need to try and find a better way to implement this than always allocating labels of a fixed and possibly too-small size. What about perhaps starting with a statically allocated array of say 64 bytes (I can't see any labels on my system larger than that), and then falling back to a a dynamic allocation of up to 32k if it turns out to be too small ? i.e. large labels are a slow path and there is no practical limit on label size. - James -- James Morris