From patchwork Thu Apr 7 16:37:37 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever III X-Patchwork-Id: 692941 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p37Gbf6L012519 for ; Thu, 7 Apr 2011 16:37:42 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755913Ab1DGQhj (ORCPT ); Thu, 7 Apr 2011 12:37:39 -0400 Received: from mail-iw0-f174.google.com ([209.85.214.174]:57766 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755392Ab1DGQhj (ORCPT ); Thu, 7 Apr 2011 12:37:39 -0400 Received: by mail-iw0-f174.google.com with SMTP id 34so2629173iwn.19 for ; Thu, 07 Apr 2011 09:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:subject:to:cc:date:message-id :in-reply-to:references:user-agent:mime-version:content-type :content-transfer-encoding; bh=oUC/iMrZvTqADk8jVRprKMvIyuRZY+Rj0bWZ/w+H8OU=; b=IOKC/wmDwQUdwM8xsSSdxRIaZKTYEwsux5dnQWL3wQ5YBXf46ECR1xl3BZnwkzJJzF k6xEkysNf8nM49VWUa8VLPi2pg19jumJnoCAfxzv0Unbzv0zDviaUuDp7ZRiviB3fMOd KGfO/mpGn+fo/imw6hYosBjHGv2RAaG0blYKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:subject:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; b=QKX8z671KDWYHZOscGmkGhCI6diT6/pFKdtVSlhuwGWBp9tySsjpVoFoJfJYKkPy3F 2EsLpxE6nZfYV7HQh2b0/wzxVe/FePsP/T4WdJJ11BKO8/g5fRYdMY26yEJb3GssdV8x ckzxB9GEkVeDtaBv31hGQubjQWqXC+R9dMsBg= Received: by 10.231.28.164 with SMTP id m36mr1068832ibc.163.1302194258883; Thu, 07 Apr 2011 09:37:38 -0700 (PDT) Received: from matisse.1015granger.net (adsl-99-26-161-222.dsl.sfldmi.sbcglobal.net [99.26.161.222]) by mx.google.com with ESMTPS id hc41sm1247296ibb.30.2011.04.07.09.37.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 09:37:38 -0700 (PDT) From: Chuck Lever Subject: [PATCH 1/2] NFS: Revert NFSROOT default mount options To: trond.myklebust@netapp.com Cc: linux-nfs@vger.kernel.org Date: Thu, 07 Apr 2011 12:37:37 -0400 Message-ID: <20110407163736.8531.98316.stgit@matisse.1015granger.net> In-Reply-To: <20110407163304.8531.18745.stgit@matisse.1015granger.net> References: <20110407163304.8531.18745.stgit@matisse.1015granger.net> User-Agent: StGIT/0.14.3 MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Thu, 07 Apr 2011 16:37:42 +0000 (UTC) Marek Belisko reports that recent attempts to fix regressions in NFSROOT have broken his configuration: > After update from 2.6.38-rc8 to 2.6.38 is mounting rootfs over nfs not possible. > Log: > VFS: Mounted root (nfs filesystem) on device 0:14. > Freeing init memory: 132K > nfs: server 10.146.1.21 not responding, still trying > nfs: server 10.146.1.21 not responding, still trying > > This is never ending. I make short bisect (not too much commits > between versions) > and bad commit was reported: 53d4737580535e073963b91ce87d4216e434fab5 > > NFS: NFSROOT should default to "proto=udp" > > I've tested on mini2440 board (DM9000, static IP). > Is there some missing option or something else to be checked? An examination of a network trace captured during the failure shows that the mount is actually succeeding, but that the client is not seeing READ replies larger than 16KB. This could be a local packet filtering issue on the client, but we didn't troubleshoot this further because of the reported "git bisect" result. Last fall we removed the ad hoc mount option parser in fs/nfs/nfsroot.c in favor of using the main parser in fs/nfs/super.c (see commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing"). That commit changed the default NFSROOT mount options to be the same as those employed by user space mounts. As it turns out, these new default mount options are not tolerated by many embedded systems. So far these problems have been due to specific behavior of certain embedded NICs. The NFS community does not have such hardware on hand for running tests. Commit 53d47375 recently introduced a clean way to specify default mount options for NFSROOT, so we can now easily restore the traditional defaults for NFSROOT: vers=2,udp,rsize=4096,wsize=4096 This should revert the new default NFSROOT mount options introduced with commit 56463e50. Tested-by: Marek Belisto Signed-off-by: Chuck Lever --- fs/nfs/nfsroot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/nfs/nfsroot.c b/fs/nfs/nfsroot.c index c541093..c4744e1 100644 --- a/fs/nfs/nfsroot.c +++ b/fs/nfs/nfsroot.c @@ -87,7 +87,7 @@ #define NFS_ROOT "/tftpboot/%s" /* Default NFSROOT mount options. */ -#define NFS_DEF_OPTIONS "udp" +#define NFS_DEF_OPTIONS "vers=2,udp,rsize=4096,wsize=4096" /* Parameters passed from the kernel command line */ static char nfs_root_parms[256] __initdata = "";