Re: [PATCH] ceph: don't set st_dev to 0 for stat(2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 11 Dec 2017, at 19:59, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> 
> On Mon, 2017-12-11 at 16:47 +0800, Yan, Zheng wrote:
>> Zero st_dev confuses ls(1) code. it make 'ls -l' not print '+' sign
>> for file/directory with ACL.
>> 
>> Signed-off-by: "Yan, Zheng" <zyan@xxxxxxxxxx>
>> ---
>> fs/ceph/inode.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
>> index c6ec5aa46100..b5529b0b77a6 100644
>> --- a/fs/ceph/inode.c
>> +++ b/fs/ceph/inode.c
>> @@ -2244,7 +2244,7 @@ int ceph_getattr(const struct path *path, struct kstat *stat,
>> 		if (ceph_snap(inode) != CEPH_NOSNAP)
>> 			stat->dev = ceph_snap(inode);
>> 		else
>> -			stat->dev = 0;
>> +			stat->dev = 1; /* the smallest snapid is 2 */
>> 		if (S_ISDIR(inode->i_mode)) {
>> 			if (ceph_test_mount_opt(ceph_sb_to_client(inode->i_sb),
>> 						RBYTES))
> 
> This looks wrong to me.
> 
> This should be getting filled out with the value of the sb->s_dev field
> in generic_fillattr. The right fix would be to ensure that that field
> ends up with something valid in it, and that should be happening when we
> call set_anon_super.
> 
> I think we need to understand why that isn't happening here.

I think the reason we set st_dev to snapid is to distinguish head inode from snapped inode. It avoids user programs (eg backup program) from recognizing snapped inode as the same as head inode. (We probably can allocate an anon super for each snapid we encountered)

Regards
Yan, Zheng

> 
> -- 
> Jeff Layton <jlayton@xxxxxxxxxx>

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux