All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Zhang Yi <yi.zhang@huawei.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-ext4@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, yukuai3@huawei.com
Subject: Re: [PATCH v2 3/4] ext4: factor out write end code of inline file
Date: Fri, 16 Jul 2021 12:08:20 +0200	[thread overview]
Message-ID: <20210716100820.GF31920@quack2.suse.cz> (raw)
In-Reply-To: <eced292f-cdbe-ff0f-3d4d-d6e3a3c84520@huawei.com>

On Fri 16-07-21 11:56:06, Zhang Yi wrote:
> On 2021/7/15 20:08, Jan Kara wrote:
> > On Thu 15-07-21 09:54:51, Zhang Yi wrote:
> >> Now that the inline_data file write end procedure are falled into the
> >> common write end functions, it is not clear. Factor them out and do
> >> some cleanup. This patch also drop ext4_da_write_inline_data_end()
> >> and switch to use ext4_write_inline_data_end() instead because we also
> >> need to do the same error processing if we failed to write data into
> >> inline entry.
> >>
> >> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
> > 
> > Just two small comments below.
> > 
> >> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> >> index 28b666f25ac2..3d227b32b21c 100644
> >> --- a/fs/ext4/inline.c
> >> +++ b/fs/ext4/inline.c
> > ...
> >> +out:
> >> +	/*
> >> +	 * If we have allocated more blocks and copied less. We will have
> >> +	 * blocks allocated outside inode->i_size, so truncate them.
> >> +	 */
> >> +	if (pos + len > inode->i_size && ext4_can_truncate(inode))
> >> +		ext4_orphan_add(handle, inode);
> > 
> > I don't think we need this error handling here. For inline data we never
> > allocate any blocks so shorter writes don't need any cleanup.
> > 
> >> -	return copied;
> >> +	ret2 = ext4_journal_stop(handle);
> >> +	if (!ret)
> >> +		ret = ret2;
> >> +	if (pos + len > inode->i_size) {
> >> +		ext4_truncate_failed_write(inode);
> >> +		/*
> >> +		 * If truncate failed early the inode might still be
> >> +		 * on the orphan list; we need to make sure the inode
> >> +		 * is removed from the orphan list in that case.
> >> +		 */
> >> +		if (inode->i_nlink)
> >> +			ext4_orphan_del(NULL, inode);
> >> +	}
> > 
> > And this can go away as well...
> > 
> 
> Yeah, but if we don't call ext4_truncate_failed_write()->..->
> ext4_inline_data_truncate(), it will lead to incorrect larger i_inline_size
> and data entry. Although it seems harmless (i_size can prevent read zero
> data), I think it's better to restore the data entry(the comments need
> change later), or else it will occupy more xattr space. What do you think ?

Good point. I've found this out last time when I was reviewing your patches
and then forgot again. So please leave the code there but fix this
misleading comment:

/*
 * If we have allocated more blocks and copied less. We will have
 * blocks allocated outside inode->i_size, so truncate them.
 */

Something like:

/*
 * If we didn't copy as much data as expected, we need to trim back size of
 * xattr containing inline data.
 */

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2021-07-16 10:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15  1:54 [PATCH v2 0/4] ext4: improve delalloc buffer write performance Zhang Yi
2021-07-15  1:54 ` [PATCH v2 1/4] ext4: check and update i_disksize properly Zhang Yi
2021-07-15 11:52   ` Jan Kara
2021-07-15  1:54 ` [PATCH v2 2/4] ext4: correct the error path of ext4_write_inline_data_end() Zhang Yi
2021-07-15  1:54 ` [PATCH v2 3/4] ext4: factor out write end code of inline file Zhang Yi
2021-07-15 12:08   ` Jan Kara
2021-07-16  3:56     ` Zhang Yi
2021-07-16 10:08       ` Jan Kara [this message]
2021-07-16 12:04         ` Zhang Yi
2021-07-15  1:54 ` [PATCH v2 4/4] ext4: drop unnecessary journal handle in delalloc write Zhang Yi

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=20210716100820.GF31920@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.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.