Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp723401pxa; Sat, 1 Aug 2020 04:11:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUJBJoihDKvk0oE1sS9mMvSakD6h2T2PL5kvZkq+NoE9+w2fuJ+ULz0DVixSHx3CFPzq4A X-Received: by 2002:a17:906:7709:: with SMTP id q9mr8070745ejm.123.1596280285630; Sat, 01 Aug 2020 04:11:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596280285; cv=none; d=google.com; s=arc-20160816; b=cYlc41E99n5RfuEoTLWa56rNKs5Bu7j5gOKNOdEsDt2Ix2vOoCtN1X3xQ4AwxrlQ52 Ty6lYkzZbgU9uvZr5nCpYDFis5aAfQQF6Ll0YNvHIC+rD26EOQCCvkiuN4EUPCdsLn/F DzqGNGd6BJGRAzTRdPBSYL75KYu9JTiwlZqpo+hnUDkLUzLPUVqgv1GSpxYrx0D1ZHqs ObT6iR+cHgcKL56t8lNxyqMEb6HEGHULt4GFScosbi2dKCee+nVacf7EHW8452Kh9izb GbfwpPtuflu1x9erAiX27sm8HI1Za9KvLdw1axuJA0DJt3XTNW6WvpYrHhFlzI7In/s1 x5Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=pAmL4k/JVZLMCB2r6A1QI/PffLuIzBDgu2w1EwYbcC8=; b=hqJ0aWoBxDcLaySJjNGMbMCe7GIk4oqjOdedHNw8od4pD6xjx7y4RNlC7v0ejSEKc/ /UohIQSW97rscFeTiN+8SIh9MLxBZH0VBHAVFKjqYuh2G7xtXAU135WGEJmMUGwC3hpa aave8I7msaWbed4G+9eOasba3CXWz/VOsODzXA5KSpXDMfBKT4Sw3VXHF27BzaTcmE9n 2llkSwpIMPzOF5NONN1K4Zer3/TVnl2dFTLmUdHESHxoCpl/8t3ozPndYoLcRjCxhy1e Wjat2AkiWE5M8K6XMHdETTQH1N92i2Y6vEHoEC5104ciTfSuZk3niC+t0djwKzrKG3W+ QhEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QvzIuR8j; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bc2si7112725edb.424.2020.08.01.04.10.49; Sat, 01 Aug 2020 04:11:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QvzIuR8j; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728609AbgHALKr (ORCPT + 99 others); Sat, 1 Aug 2020 07:10:47 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:34619 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728505AbgHALKq (ORCPT ); Sat, 1 Aug 2020 07:10:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596280245; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=pAmL4k/JVZLMCB2r6A1QI/PffLuIzBDgu2w1EwYbcC8=; b=QvzIuR8j2hSqNvJ4Kvuj/P1IQT+wEy9/9/BKhRj40FgOfSuuDjh5ZoO+SeADSKUVUtu8BI Rk7uI4IAUV6/fKaG8tzKHS6nSTrEY9fjOZiYulaVal7eRObYhlVCskdraFkZbJxcjEFi1h Sd5XtdDUZn2IX3t+W47dhZWzPquIbcQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-60-J0AqIk8rPYeram2FWvJmPA-1; Sat, 01 Aug 2020 07:10:41 -0400 X-MC-Unique: J0AqIk8rPYeram2FWvJmPA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B81FF8014D7; Sat, 1 Aug 2020 11:10:40 +0000 (UTC) Received: from aion.usersys.redhat.com (ovpn-115-198.rdu2.redhat.com [10.10.115.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 66F155D9E8; Sat, 1 Aug 2020 11:10:40 +0000 (UTC) Received: by aion.usersys.redhat.com (Postfix, from userid 1000) id 8C6BA1A0006; Sat, 1 Aug 2020 07:10:39 -0400 (EDT) From: Scott Mayhew To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com Cc: linux-nfs@vger.kernel.org Subject: [PATCH v2 0/2] nfs: two writeback error reporting fixes Date: Sat, 1 Aug 2020 07:10:37 -0400 Message-Id: <20200801111039.1407632-1-smayhew@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org These fixes fix two regressions reported by Red Hat QE. This first issue reported was that writing a file larger than the available space would result in a client hang instead of returning -ENOSPC. The second issue reported was that the client was returning -EIO instead of -EDQUOT when a quota is exceeded. On further investigation, I found that in the first issue the client wasn't really hung. Instead it was performing all of the requested writes before it would eventually return -ENOSPC. The dd command was writing 400TB, which would have taken a few weeks to complete. Adjusting the 'bs' and 'count' arguments so that the resulting file would be much smaller (but still enough to fill up the space on the NFS server) showed that the dd command would indeed complete with -ENOSPC. But on older kernels even the 400TB dd would return -ENOSPC quickly. In the second issue, I found that adding 'conv=fsync' would make the dd command return -EDQUOT. So what was happening with the original command was that it was doing a close() without first calling fsync() and the close() was returning -EIO. I bisected both of these down to commit aded8d7b54f2 ("NFS: Don't inadvertently clear writeback errors"). HOWEVER, as a test I reverted that commit and it wasn't sufficient to bring back the old behavior. I turns out that was due to commit 6fbda89b257f ("NFS: Replace custom error reporting mechanism with generic one"). This is why I listed the second commit in the 'Fixes:' tag of both of my patches. The first patch fixes the -EDQUOT issue and the second one fixes the -ENOSPC issue. -Scott v2: - Use filemap_sample_wb_err() & filemap_check_wb_err() instead of file_check_and_advance_wb_err() so that the error is not consumed. Scott Mayhew (2): nfs: ensure correct writeback errors are returned on close() nfs: nfs_file_write() should check for writeback errors fs/nfs/file.c | 17 +++++++++++++---- fs/nfs/nfs4file.c | 5 ++++- 2 files changed, 17 insertions(+), 5 deletions(-) -- 2.25.4