From: Christoph Hellwig <hch@lst.de>
To: Tao Ma <tao.ma@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Joel Becker <joel.becker@oracle.com>,
Christoph Hellwig <hch@lst.de>, Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH v3] ocfs2: Let ocfs2_setattr use new truncate sequence.
Date: Thu, 10 Jun 2010 10:27:11 +0200 [thread overview]
Message-ID: <20100610082711.GA2173@lst.de> (raw)
In-Reply-To: <1276146485-9346-1-git-send-email-tao.ma@oracle.com>
On Thu, Jun 10, 2010 at 01:08:05PM +0800, Tao Ma wrote:
> Let ocfs2 use the new truncate sequence. The changes include:
> 1. Use truncate_setsize directly since we don't implement our
> own ->truncate and what we need is "update i_size and
> truncate_pagecache" which truncate_setsize now does.
> 2. For direct write, ocfs2 actually don't allow write to pass
> i_size(see ocfs2_prepare_inode_for_write), so we don't have
> a chance to increase i_size. So remove the bogus check.
You just leave the duplicate inode_newsize_ok in, but still have
one as part of inode_change_ok. See the previous thread - we'll
need to move inode_change_ok to under the cluster locks, both
for the truncate and non-truncate case.
> /*
> + * Since all the work for a size change has been done above.
> + * Call truncate_setsize directly to change size and truncate
> + * pagecache.
> */
> if ((attr->ia_valid & ATTR_SIZE) &&
> + attr->ia_size != inode->i_size)
this could be on one line now.
> + truncate_setsize(inode, attr->ia_size);
But any reason this isn't done inside the
if (size_change && attr->ia_size != inode->i_size) {
conditional above? You'll never get size and uid/gid changes in the
same request, so there won't be any change in behaviour.
next prev parent reply other threads:[~2010-06-10 8:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 3:53 [PATCH v2] ocfs2: Let ocfs2_setattr use new truncate sequence Tao Ma
2010-06-10 4:42 ` Nick Piggin
2010-06-10 5:06 ` Tao Ma
2010-06-10 5:08 ` [PATCH v3] " Tao Ma
2010-06-10 5:58 ` Joel Becker
2010-06-10 8:27 ` Christoph Hellwig [this message]
2010-06-10 8:44 ` Tao Ma
2010-06-10 8:47 ` Joel Becker
2010-06-10 12:09 ` Tao Ma
2010-06-10 12:09 ` Tao Ma
2010-06-10 12:28 ` Nick Piggin
2010-06-10 18:11 ` Joel Becker
2010-06-11 0:00 ` Tao Ma
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=20100610082711.GA2173@lst.de \
--to=hch@lst.de \
--cc=joel.becker@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=tao.ma@oracle.com \
/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.