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...@samsung.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to