[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151204205523.GA73158@jaegeuk.local>
Date: Fri, 4 Dec 2015 12:55:23 -0800
From: Jaegeuk Kim <jaegeuk@...nel.org>
To: Chao Yu <chao2.yu@...sung.com>
Cc: linux-f2fs-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: fix to convert inline inode in ->setattr
Hi Chao,
On Tue, Dec 01, 2015 at 11:36:16AM +0800, Chao Yu wrote:
> In commit 3c4541452748 ("f2fs: do not trim preallocated blocks when
> truncating after i_size"), in order to follow the regulation: "truncate(x)
> where x > i_size will not trim all blocks past i_size." like other file
> systems, in ->setattr we invoked truncate_setsize instead of f2fs_truncate
> to avoid unneeded block trimming in such case, but forgot to call
> f2fs_convert_inline_inode keep consistency of inline data conversion rule.
>
> This patch fixes to convert inline data if necessary.
>
> Signed-off-by: Chao Yu <chao2.yu@...sung.com>
> ---
> fs/f2fs/file.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 96e4e04..a018ed3 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -686,6 +686,14 @@ int f2fs_setattr(struct dentry *dentry, struct iattr *attr)
> * larger than i_size.
> */
> truncate_setsize(inode, attr->ia_size);
> +
> + /* should convert inline inode here */
> + if (f2fs_has_inline_data(inode) &&
> + !f2fs_may_inline_data(inode)) {
> + err = f2fs_convert_inline_inode(inode);
> + if (err)
> + return err;
> + }
Without this, f2fs handles correctly inline_data when user tries to write
something later, right?
One corner case is:
if the partiton is filled up to 100% with data + inline_data, we cannot truncate
one of inline_data after merging this patch.
Cause it failed to convert it.
Thanks,
> inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> }
> }
> --
> 2.6.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists