From: Boaz Harrosh <bharrosh@panasas.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [rfc][patch 3/4] fs: new truncate sequence
Date: Sun, 12 Jul 2009 11:55:51 +0300 [thread overview]
Message-ID: <4A59A517.1080605@panasas.com> (raw)
In-Reply-To: <20090709075100.GU2714@wotan.suse.de>
On 07/09/2009 10:51 AM, Nick Piggin wrote:
> On Wed, Jul 08, 2009 at 07:07:17PM +0300, Boaz Harrosh wrote:
>> On 07/08/2009 03:34 PM, Nick Piggin wrote:
>>> On Wed, Jul 08, 2009 at 06:47:01AM -0400, Christoph Hellwig wrote:
>>> Index: linux-2.6/fs/attr.c
>>> ===================================================================
>>> --- linux-2.6.orig/fs/attr.c
>>> +++ linux-2.6/fs/attr.c
>>> @@ -112,7 +112,12 @@ int inode_setattr(struct inode * inode,
>>>
>>> if (ia_valid & ATTR_SIZE &&
>>> attr->ia_size != i_size_read(inode)) {
>>> - int error = vmtruncate(inode, attr->ia_size);
>>> + int error;
>>> +
>>> + if (inode->i_op->new_truncate)
>>> + error = simple_setsize(inode, attr->ia_size);
>> I don't understand this branch.
>> If a filesystem has been converted to set "i_op->new_truncate=true"
>> then it must have been converted to intersect ->setattr and has set
>> the i_size (And needs to clear ATTR_SIZE, why?)
>>
>> All other cases of systems not converted, or systems that do not have
>> ->truncate will fall to the "else" part.
>>
>> before the removal of i_op->new_truncate you will need to do something
>> with the systems that do not have ->truncate which will be a
>> .setattr = simple_setattr or something
>>
>> So I don't understand this conditional
>
> inode_setattr *is* our "simple_setattr".
>
I wish you would split it.
one - helper to be called by converted file systems
(Which just ignores the ATTR_SIZE)
second - to be set into .setattr which does the simple_setsize + above.
More clear for FS users like me (and that ugly unmask of ATTR_SIZE)
or it's just me?
Thanks
Boaz
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <bharrosh@panasas.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [rfc][patch 3/4] fs: new truncate sequence
Date: Sun, 12 Jul 2009 11:55:51 +0300 [thread overview]
Message-ID: <4A59A517.1080605@panasas.com> (raw)
In-Reply-To: <20090709075100.GU2714@wotan.suse.de>
On 07/09/2009 10:51 AM, Nick Piggin wrote:
> On Wed, Jul 08, 2009 at 07:07:17PM +0300, Boaz Harrosh wrote:
>> On 07/08/2009 03:34 PM, Nick Piggin wrote:
>>> On Wed, Jul 08, 2009 at 06:47:01AM -0400, Christoph Hellwig wrote:
>>> Index: linux-2.6/fs/attr.c
>>> ===================================================================
>>> --- linux-2.6.orig/fs/attr.c
>>> +++ linux-2.6/fs/attr.c
>>> @@ -112,7 +112,12 @@ int inode_setattr(struct inode * inode,
>>>
>>> if (ia_valid & ATTR_SIZE &&
>>> attr->ia_size != i_size_read(inode)) {
>>> - int error = vmtruncate(inode, attr->ia_size);
>>> + int error;
>>> +
>>> + if (inode->i_op->new_truncate)
>>> + error = simple_setsize(inode, attr->ia_size);
>> I don't understand this branch.
>> If a filesystem has been converted to set "i_op->new_truncate=true"
>> then it must have been converted to intersect ->setattr and has set
>> the i_size (And needs to clear ATTR_SIZE, why?)
>>
>> All other cases of systems not converted, or systems that do not have
>> ->truncate will fall to the "else" part.
>>
>> before the removal of i_op->new_truncate you will need to do something
>> with the systems that do not have ->truncate which will be a
>> .setattr = simple_setattr or something
>>
>> So I don't understand this conditional
>
> inode_setattr *is* our "simple_setattr".
>
I wish you would split it.
one - helper to be called by converted file systems
(Which just ignores the ATTR_SIZE)
second - to be set into .setattr which does the simple_setsize + above.
More clear for FS users like me (and that ugly unmask of ATTR_SIZE)
or it's just me?
Thanks
Boaz
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-07-12 8:56 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 14:44 [rfc][patch 1/4] fs: new truncate helpers Nick Piggin
2009-07-07 14:44 ` Nick Piggin
2009-07-07 14:46 ` [rfc][patch 2/4] fs: use " Nick Piggin
2009-07-07 14:46 ` Nick Piggin
2009-07-07 14:53 ` Christoph Hellwig
2009-07-07 14:53 ` Christoph Hellwig
2009-07-07 14:48 ` [rfc][patch 3/4] fs: new truncate sequence Nick Piggin
2009-07-07 14:48 ` Nick Piggin
2009-07-07 14:58 ` Christoph Hellwig
2009-07-07 14:58 ` Christoph Hellwig
2009-07-07 15:02 ` Nick Piggin
2009-07-07 15:02 ` Nick Piggin
2009-07-07 15:07 ` Christoph Hellwig
2009-07-07 15:07 ` Christoph Hellwig
2009-07-07 15:48 ` Nick Piggin
2009-07-07 15:48 ` Nick Piggin
2009-07-07 16:30 ` Christoph Hellwig
2009-07-07 16:30 ` Christoph Hellwig
2009-07-08 6:32 ` Nick Piggin
2009-07-08 6:32 ` Nick Piggin
2009-07-08 10:47 ` Christoph Hellwig
2009-07-08 10:47 ` Christoph Hellwig
2009-07-08 12:34 ` Nick Piggin
2009-07-08 12:34 ` Nick Piggin
2009-07-08 12:40 ` Christoph Hellwig
2009-07-08 12:40 ` Christoph Hellwig
2009-07-08 12:48 ` Nick Piggin
2009-07-08 12:48 ` Nick Piggin
2009-07-08 16:07 ` Boaz Harrosh
2009-07-08 16:07 ` Boaz Harrosh
2009-07-09 7:51 ` Nick Piggin
2009-07-09 7:51 ` Nick Piggin
2009-07-12 8:55 ` Boaz Harrosh [this message]
2009-07-12 8:55 ` Boaz Harrosh
2009-07-12 14:47 ` Christoph Hellwig
2009-07-12 14:47 ` Christoph Hellwig
2009-07-12 15:00 ` Boaz Harrosh
2009-07-12 15:00 ` Boaz Harrosh
2009-07-13 6:59 ` Nick Piggin
2009-07-13 6:59 ` Nick Piggin
2009-07-13 8:54 ` Boaz Harrosh
2009-07-13 8:54 ` Boaz Harrosh
2009-07-13 9:00 ` Nick Piggin
2009-07-13 9:00 ` Nick Piggin
2009-07-13 11:17 ` Boaz Harrosh
2009-07-13 11:17 ` Boaz Harrosh
2009-07-13 11:32 ` Nick Piggin
2009-07-13 11:32 ` Nick Piggin
2009-07-13 13:53 ` Christoph Hellwig
2009-07-13 13:53 ` Christoph Hellwig
2009-07-13 14:05 ` Nick Piggin
2009-07-13 14:05 ` Nick Piggin
2009-07-13 14:10 ` Christoph Hellwig
2009-07-13 14:10 ` Christoph Hellwig
2009-07-07 14:48 ` [rfc][patch 1/4] fs: new truncate helpers Christoph Hellwig
2009-07-07 14:48 ` Christoph Hellwig
2009-07-07 14:49 ` [rfc][patch 4/4] fs: tmpfs, ext2 use new truncate Nick Piggin
2009-07-07 14:49 ` Nick Piggin
2009-07-07 16:38 ` Christoph Hellwig
2009-07-07 16:38 ` Christoph Hellwig
2009-07-08 6:53 ` Nick Piggin
2009-07-08 6:53 ` Nick Piggin
2009-07-08 11:14 ` Jan Kara
2009-07-08 11:14 ` Jan Kara
2009-07-08 12:22 ` Nick Piggin
2009-07-08 12:22 ` Nick Piggin
2009-07-08 12:32 ` Christoph Hellwig
2009-07-08 12:32 ` Christoph Hellwig
2009-07-08 12:39 ` Nick Piggin
2009-07-08 12:39 ` Nick Piggin
2009-07-08 13:49 ` Christoph Hellwig
2009-07-08 13:49 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A59A517.1080605@panasas.com \
--to=bharrosh@panasas.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.