| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH v2] Check for immutable flag in fallocate path |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Mon, 14 Mar 2011 06:24:26 -0400 |
| Cc: | Marco Stornelli <marco.stornelli@xxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, xfs@xxxxxxxxxxx, Linux FS Devel <linux-fsdevel@xxxxxxxxxxxxxxx> |
| In-reply-to: | <20110303213903.GL15097@dastard> |
| References: | <4D6221B8.9040303@xxxxxxxxx> <4D6F5473.2070709@xxxxxxxxx> <20110303213903.GL15097@dastard> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: testcase 011 trips and ASSERT in x86_64 too, Dave Chinner |
|---|---|
| Next by Date: | Re: Does XFS ever relocate extents after they are on disk?, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH v2] Check for immutable flag in fallocate path, Marco Stornelli |
| Next by Thread: | Re: [PATCH v2] Check for immutable flag in fallocate path, Marco Stornelli |
| Indexes: | [Date] [Thread] [Top] [All Lists] |