Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-vc0-f182.google.com ([209.85.220.182]:54871 "EHLO mail-vc0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891AbaIEUUt (ORCPT ); Fri, 5 Sep 2014 16:20:49 -0400 Received: by mail-vc0-f182.google.com with SMTP id im17so13230842vcb.27 for ; Fri, 05 Sep 2014 13:20:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20140903070048.56201d1d@tlielax.poochiereds.net> <70D58138-CB00-433C-8BF8-01584E6460F0@oracle.com> From: Chris Perl Date: Fri, 5 Sep 2014 16:20:28 -0400 Message-ID: Subject: Re: nfs-utils - TCP ephemeral port exhaustion results in mount failures To: Trond Myklebust Cc: Chuck Lever , Jeff Layton , Linux NFS Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: It looks like they may have come through after all, unfortunately I already sent them again. Apologies for the spam. On Fri, Sep 5, 2014 at 4:04 PM, Chris Perl wrote: > I tried to send them to the list, but I guess they didn't come through > because my sender was set to chris.perl@gmail.com, but I ran `git > send-email' from work, so the smtp sender ip wouldn't authorized. > > I'll figure out a way to send them now. > > On Fri, Sep 5, 2014 at 4:03 PM, Trond Myklebust > wrote: >> On Fri, Sep 5, 2014 at 3:40 PM, Chris Perl wrote: >>> I just submitted two patches, one for nfs-utils and one for linux-nfs. >>> >>> As I said in my previous email, the patch to nfs-utils was enough to >>> get us farther along, but we failed inside mount(2) with EIO (with a >>> decidedly more confusing error message). >>> >>> So, I've also submitted a patch for the rpc code in the kernel that >>> also avoids bind when asking for a random ephemeral port. I've tested >>> the combination of these two patches with my system while in the >>> situation I originally outlined. I can continue to successfully mount >>> NFS filesystems using both of these patches. >>> >>> I don't particularly love the kernel patch, as it makes `xs_bind' not >>> actually bind in all circumstances, which seems confusing. However, I >>> thought trying to rework things in a larger way would cause more >>> issues given that I'm not very familiar with this code. If everyone >>> hates it, I can try something else. >> >> To whom did you submit these patches? I don't see anything in the >> linux-nfs mailing list. >> >> -- >> Trond Myklebust >> >> Linux NFS client maintainer, PrimaryData >> >> trond.myklebust@primarydata.com