[Top] [All Lists]

Re: [PATCH v2] Check for immutable flag in fallocate path

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.


<Prev in Thread] Current Thread [Next in Thread>