Re: [RFC PATCH] client: don't use special inode for /..

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

 



On Wed, Aug 10, 2016 at 4:30 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Wed, 2016-08-10 at 16:08 -0400, Patrick Donnelly wrote:
>> On Wed, Aug 10, 2016 at 12:30 PM, Jeff Layton <jlayton@xxxxxxxxxx>
>> wrote:
>> >
>> > The CEPH_INO_DOTDOT thing is quite strange. Under most OS (Linux
>> > included), the parent of the root is itself. IOW, at the root, '.'
>> > and
>> > '..' refer to the same inode.
>> >
>> > Change the ceph client to do the same, as this allows users to get
>> > valid stat info for '..', as well as elimnating some special-
>> > casing.
>> >
>> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
>>
>> Don't forget Client::_lookup:
>>
>>   if (dname == "..") {
>>     if (dir->dn_set.empty())
>>       r = -ENOENT;
>>     else
>>       *target = dir->get_first_parent()->dir->parent_inode; //dirs
>> can't be hard-linked
>>     goto done;
>>   }
>>
>> Otherwise LGTM.
>>
>
>
> Ahh, thanks. So will dir->dn_set.empty() be true at the root? If so,
> then something like the patch below?

Well, that's tricky actually. My understanding is that if dn_set is
empty then either the inode is unlinked or it is the root inode (from
the client's perspective). So the below patch is probably not quite
right? I think if the directory is unlinked but not the root, its ".."
should still refer to its first parent? The ENOENT error is probably
wrong.

> Note that this patch is not strictly necessary, but it does simplify
> some other changes that I have queued up:

I think the patch is a good change but there may be some other code
paths that need fixed. This change needs some simple tests.

-- 
Patrick Donnelly
--
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