| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH v2] Check for immutable flag in fallocate path |
| From: | Marco Stornelli <marco.stornelli@xxxxxxxxx> |
| Date: | Mon, 14 Mar 2011 11:40:26 +0100 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, xfs@xxxxxxxxxxx, Linux FS Devel <linux-fsdevel@xxxxxxxxxxxxxxx> |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jksURX9Pwr+wGBdGXvyfeU9AyGsFs1xZINkbDv/CKbQ=; b=HJ0G66x5wPb5YFgUuHhd7prkoRj/aQtHNq5gDLT4HmcLAW0sx8g+pbgkbpdnXwVf3q OaD7GNq6GEEXQV6fgiuIpLF3bdJuYS6auM9IHVeX6hU4+DQup/OLLkUhzZoyPRW8oUtF m99anwGUArDenngwotG9o6Bc0zlXyKcDXRhxQ= |
| Domainkey-signature: | a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kqYc0Z1WmrPUgQMMz1/CkBIIviX/kIg9VJIKgVccy4eyjxOPEprFGhEP2XZZ4NUYew 3kWEuOXgNu3jJUQmGTcNwgi6zsT6QpssY8A3+aeB4iK5xlQINpNcHFNQWrRb3UDyimAN gHMRoI9OpfXpA5xrdDAjrNmCwCGMySfG6Cz6U= |
| In-reply-to: | <20110314102426.GA29888@xxxxxxxxxxxxx> |
| References: | <4D6221B8.9040303@xxxxxxxxx> <4D6F5473.2070709@xxxxxxxxx> <20110303213903.GL15097@dastard> <20110314102426.GA29888@xxxxxxxxxxxxx> |
2011/3/14 Christoph Hellwig <hch@xxxxxxxxxxxxx>: > On Fri, Mar 04, 2011 at 08:39:03AM +1100, Dave Chinner wrote: >> WTF? Why does append mode have any effect on whether we can punch >> holes in a file or not? There's no justification for adding this in >> the commit message. Why is it even in a patch that is for checking >> immutable inodes? What is the point of adding it, when all that will >> happen is people will switch to XFS_IOC_UNRESVSP which has never had >> this limitation? > > xfs_ioc_space unconditionally rejects inodes with S_APPEND set for > all preallocation / hole punching ioctls. This might be overzealous for > preallocations not changing the size, or just extending i_size, but it's > IMHO entirely correct for hole punching. > xfs_ioc_space is in the ioctl path, but we are talking about the fallocate path. Both of them calls the xfs_change_file_space, isnt'it? However we are agree about hole punching, the patch is already in Linus's git tree. Marco |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Does XFS ever relocate extents after they are on disk?, Christoph Hellwig |
|---|---|
| Next by Date: | Re: testcase 011 trips and ASSERT in x86_64 too, Chandra Seetharaman |
| Previous by Thread: | Re: [PATCH v2] Check for immutable flag in fallocate path, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 3/5] xfs: convert ENOSPC inode flushing to use new syncd workqueue, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |