From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D5CEC7618F for ; Fri, 19 Jul 2019 18:04:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D83121872 for ; Fri, 19 Jul 2019 18:04:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730354AbfGSSEX (ORCPT ); Fri, 19 Jul 2019 14:04:23 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:46175 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729769AbfGSSEX (ORCPT ); Fri, 19 Jul 2019 14:04:23 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-99.corp.google.com [104.133.0.99] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6JI4Ic9012427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2019 14:04:19 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 4A231420054; Fri, 19 Jul 2019 14:04:18 -0400 (EDT) Date: Fri, 19 Jul 2019 14:04:18 -0400 From: "Theodore Y. Ts'o" To: Ian Malone Cc: linux-ext4@vger.kernel.org Subject: Re: ext4 reserved blocks not enforced? Message-ID: <20190719180418.GD19119@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Jul 18, 2019 at 04:26:19PM +0100, Ian Malone wrote: > Recently we extended a ~1.9TB filesystem by 20GB, however afterwards > df reported 0 available bytes. The LV had been increased and running > resize2fs reported that the fs was already the full size of the > device. tune2fs showed fewer free blocks than reserved blocks. Despite > this, normal users could create files on the filesystem (via nfs) It's the "via NFS" which is the issue. The problem is that model with NFS is that access checks are done on the client side, and the NFS client doesn't know about ext4's reserved block policy (nor does the NFS client have a good way of knowing how blocks are reserved, or, without constantly requesting the free space via repeated NFS queries, how many free blocks are availble on the server). On the NFS server side, the server has no way of knowing whether or not "root" was issuing the write. The NFS server could know whether or not the "root squash" flag is set, and pass that to ext4, but that's not currently being done. - Ted