[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3ED34739A4E85E4F894367D57617CDEFCA5978B0@LAX-EX-MB2.datadirect.datadirectnet.com>
Date: Mon, 3 Jul 2017 02:58:28 +0000
From: Wang Shilong <wshilong@....com>
To: "miaoxie@...wei.com" <miaoxie@...wei.com>,
Wang Shilong <wangshilong1991@...il.com>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
CC: "tytso@....edu" <tytso@....edu>, Li Xi <lixi@....com>,
"yi.zhang@...wei.com" <yi.zhang@...wei.com>,
"adilger@...ger.ca" <adilger@...ger.ca>,
Shuichi Ihara <sihara@....com>
Subject: RE: [PATCH 1/2] ext4, project: expand inode extra size if possible
________________________________________
From: Miao Xie [miaoxie@...wei.com]
Sent: Monday, July 03, 2017 10:49
>> that file is dirtied(touch etc), changing project id will
> <...SNIP...>
>
> ext4_expand_extra_isize should be invoked after ext4_reserve_inode_writ
>
> For changing projectid, we could know how many credits before start transaction..
I found most check in set_projectid is the same as ext4_mark_inode_dirty, so I think it's better
to move those checks into ext4_expand_extra_isize to avoid the reduplicated code.
---> I agreed, it could reduce dubplicated codes, but again, ioctl failure is visible to common
users, the behavior might be confusing for users? what kind of failure we should return to
userspace? EAGAIN or EOVERFLOW?
Thanks,
Shilong
Powered by blists - more mailing lists