All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Boaz Harrosh <bharrosh@panasas.com>
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: Mon, 13 Jul 2009 11:00:56 +0200	[thread overview]
Message-ID: <20090713090056.GA3452@wotan.suse.de> (raw)
In-Reply-To: <4A5AF637.3090405@panasas.com>

On Mon, Jul 13, 2009 at 11:54:15AM +0300, Boaz Harrosh wrote:
> On 07/13/2009 09:59 AM, Nick Piggin wrote:
> > On Sun, Jul 12, 2009 at 10:47:18AM -0400, Christoph Hellwig wrote:
> >> On Sun, Jul 12, 2009 at 11:55:51AM +0300, Boaz Harrosh wrote:
> >>> 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?
> >> Yeah, that seems be a lot cleaner.  But let's wait until we got
> >> rid of ->truncate for all filesystems to have the bigger picture.
> > 
> > Agreed, if it is a common sequence / requirement for filesystems
> > then of course I will not object to a helper to make things clearer
> > or share code.
> > 
> > I would like to see inode_setattr renamed into simple_setattr, and
> > then also .setattr made mandatory, so I don't like to cut code out
> > of inode_setattr which makes it unable to be the simple_setattr
> > after the old truncate code is removed.
> > 
> 
> I thought you meant inode_setattr will go away. There will
> only be simple_setattr() and inode_setattr_nosize()
> 
> For the time been simple_setattr() will also take care
> of old ->truncate FSs. And in the absence of .setattr
> simple_setattr() is called. Have I miss-understood?
> 
> again please tell me when all this is in effect I want
> to do the conversion in exofs.

AFAIKS inode_setattr basically is simple_setattr, so I think at some
point it should just get renamed to simple_setattr. Adding
simple_setattr_nosize or similar helper would be fine too. I don't
care much about the exact details... But anyway these things are not
so important to this truncate patchset at the moment.


> [BTW these changes are a life saver for me in regard to
> the kind of things I need to do for pNFS-exports]

You mean the truncate patches? Well that's nice to know. I
guess it has always been possible just to redefine your own
setattr, but now it should be a bit nicer with the truncate
helpers...

Thanks,
Nick

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Boaz Harrosh <bharrosh@panasas.com>
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: Mon, 13 Jul 2009 11:00:56 +0200	[thread overview]
Message-ID: <20090713090056.GA3452@wotan.suse.de> (raw)
In-Reply-To: <4A5AF637.3090405@panasas.com>

On Mon, Jul 13, 2009 at 11:54:15AM +0300, Boaz Harrosh wrote:
> On 07/13/2009 09:59 AM, Nick Piggin wrote:
> > On Sun, Jul 12, 2009 at 10:47:18AM -0400, Christoph Hellwig wrote:
> >> On Sun, Jul 12, 2009 at 11:55:51AM +0300, Boaz Harrosh wrote:
> >>> 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?
> >> Yeah, that seems be a lot cleaner.  But let's wait until we got
> >> rid of ->truncate for all filesystems to have the bigger picture.
> > 
> > Agreed, if it is a common sequence / requirement for filesystems
> > then of course I will not object to a helper to make things clearer
> > or share code.
> > 
> > I would like to see inode_setattr renamed into simple_setattr, and
> > then also .setattr made mandatory, so I don't like to cut code out
> > of inode_setattr which makes it unable to be the simple_setattr
> > after the old truncate code is removed.
> > 
> 
> I thought you meant inode_setattr will go away. There will
> only be simple_setattr() and inode_setattr_nosize()
> 
> For the time been simple_setattr() will also take care
> of old ->truncate FSs. And in the absence of .setattr
> simple_setattr() is called. Have I miss-understood?
> 
> again please tell me when all this is in effect I want
> to do the conversion in exofs.

AFAIKS inode_setattr basically is simple_setattr, so I think at some
point it should just get renamed to simple_setattr. Adding
simple_setattr_nosize or similar helper would be fine too. I don't
care much about the exact details... But anyway these things are not
so important to this truncate patchset at the moment.


> [BTW these changes are a life saver for me in regard to
> the kind of things I need to do for pNFS-exports]

You mean the truncate patches? Well that's nice to know. I
guess it has always been possible just to redefine your own
setattr, but now it should be a bit nicer with the truncate
helpers...

Thanks,
Nick

--
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>

  reply	other threads:[~2009-07-13  9:00 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
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 [this message]
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=20090713090056.GA3452@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=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 \
    /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.