From patchwork Tue Jun 16 20:07:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 6619881 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9A95FC0020 for ; Tue, 16 Jun 2015 20:10:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 83A262080C for ; Tue, 16 Jun 2015 20:10:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F07820813 for ; Tue, 16 Jun 2015 20:10:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754613AbbFPUKI (ORCPT ); Tue, 16 Jun 2015 16:10:08 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:38337 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752365AbbFPUKG (ORCPT ); Tue, 16 Jun 2015 16:10:06 -0400 Received: by wibdq8 with SMTP id dq8so30653663wib.1 for ; Tue, 16 Jun 2015 13:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=xkB5P1fyx3xWRqxxksdQl/FdYys23c9fa++2R/REa2c=; b=Cc3mmGRrnH0Zq6HeQPBTAyryYSaxn43QSsoGAchx9gtWNLSZ1zY/IB1z6OvAtF+Tii cSVIja7UDSYAg0NUBNA0qOSNRbQBSgxlC+SjA9Ye/PA3SO3PDipUeOhzJhztp37IPgSj 87IXZZrhVkCmG62+Jku6ZrCaXwOnAxDenjENpFAqF4Al0H7p8ZlQunXjItnMM2Vkhpt/ QNy0TU91fWUMu73m0YcSHmldCeTHiDoKUD/DZ83JlJ4UhkcJSMzg+ED+69zI55dBwHcD 8Vnf3J19CsqzdbELZzPLwDLqCcT79C54alG6xjMXrANylUgFCLiCLZEpvIcXt1VDjmM7 ZhtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=xkB5P1fyx3xWRqxxksdQl/FdYys23c9fa++2R/REa2c=; b=VgcnpCUXVyfowY8bZysaKs6f0gajHd+jpEK74nPj7tg8K/f8Z59A8Qm2PPzjyxA3QG ljWYCQkIy2d6d0vUuPR4V3UEq93kKcFHCokSJzxwZnruijTTjUR4r992mXMiPLorZicC bNGHbQm9hgEs7SAXQnDr8FRA49jReVX0yUEWqgQZzUxwPqtId5waamH48M00u4Im6VFY JEkm/N1qdRsGhUPGyIMS/RnBt3p1A4xqFqsmWy5C/+3AdOjfk222Xq8/ok6eyzl34c1d w+B2G/A+xNVP+8Prq21WgxQG+tdSfcvnwQGcIzQWH4Mv9xnG3FsA9zYBG+KKWYXoEWqW OYQw== X-Gm-Message-State: ALoCoQmtiKSQPcMlU9g8z5OQDzy48e8R+ozGr6UjiXJYOVEjcQWcJ8khkTso+7JX6LM25elxu/pM X-Received: by 10.180.187.82 with SMTP id fq18mr10086914wic.47.1434485405577; Tue, 16 Jun 2015 13:10:05 -0700 (PDT) Received: from [192.168.1.217] ([212.169.60.169]) by mx.google.com with ESMTPSA id kc4sm3242112wjc.2.2015.06.16.13.09.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 13:10:04 -0700 (PDT) Date: Tue, 16 Jun 2015 13:07:04 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Josef Bacik , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH] tmpfs: truncate prealloc blocks past i_size In-Reply-To: Message-ID: References: <1432049251-3298-1-git-send-email-jbacik@fb.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Josef Bacik One of the rocksdb people noticed that when you do something like this fallocate(fd, FALLOC_FL_KEEP_SIZE, 0, 10M) pwrite(fd, buf, 5M, 0) ftruncate(5M) on tmpfs, the file would still take up 10M: which led to super fun issues because we were getting ENOSPC before we thought we should be getting ENOSPC. This patch fixes the problem, and mirrors what all the other fs'es do (and was agreed to be the correct behaviour at LSF). I tested it locally to make sure it worked properly with the following xfs_io -f -c "falloc -k 0 10M" -c "pwrite 0 5M" -c "truncate 5M" file Without the patch we have "Blocks: 20480", with the patch we have the correct value of "Blocks: 10240". Signed-off-by: Josef Bacik Signed-off-by: Hugh Dickins --- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/shmem.c +++ b/mm/shmem.c @@ -569,7 +569,7 @@ static int shmem_setattr(struct dentry *dentry, struct iattr *attr) i_size_write(inode, newsize); inode->i_ctime = inode->i_mtime = CURRENT_TIME; } - if (newsize < oldsize) { + if (newsize <= oldsize) { loff_t holebegin = round_up(newsize, PAGE_SIZE); unmap_mapping_range(inode->i_mapping, holebegin, 0, 1); shmem_truncate_range(inode, newsize, (loff_t)-1);