On Mon, Oct 23, 2017 at 11:40 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Mon, Oct 23, 2017 at 09:48:24AM +0300, Amir Goldstein wrote:
>> On Mon, Oct 23, 2017 at 8:32 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> > On Mon, Oct 23, 2017 at 07:30:01AM +0300, Amir Goldstein wrote:
>> >> If there is no such reason I would like to propose to store parent
>> >> pointers of directory inodes with an xattr name that is diroffset agnostic,
>> >> namely:
>> >>
>> >> struct xfs_dir_parent_name_rec {
>> >> __be64 p_ino;
>> >> __be32 p_gen;
>> >> } __attribute__((packed));
>> >>
>> >> It makes sense for metadata consistency anyway, but the reason I am
>> >> proposing this is so xfs_fs_get_name() could be implemented at O(1).
>
> [...]
>
>> But you missed my question completely. I understand why diroffset
>> is needed for non-dir. But directories are not allowed to have 2 differnt
>> parents nor 2 entries in the parent dir, so I was asking if we can
>> special case parent pointer stored in *directory inodes*.
>
> I did answer it - not directly, but the answers are there.
>
>> Am I missing something?
>
> Because you are just looking at it from a "reverse lookup"
> perspective, I suspect you're not seeing the "detect and
> reconstruct" broken directory structure side of the picture.
>
> The directory offset is redundant information which needed to fully
> cross-check and, if necessary, reconstruct broken direcotry
> structures. E.g. if a directory is missing a block due to a bad
> sector, we can reconstruct that block exactly from the parent
> pointer information because we know exactly what inodes had dirents
> in the block that was lost, and we know exactly what order they
> appeared in the directory block...
>
> If we don't have that info for all child inodes (directory or
> regular file), we can't tell the difference between "lost/stale
> child that we should ignore" and "child that was referenced by the
> block we lost". So even directories need to have the diroffset in
> their parent pointer....
>
I see. Thanks for explaining that point.
In that case, I would like to re-phrase my proposal to store parent
diroffset in the value rather than in the key of xattr, i.e.:
name={parent inode #, parent inode generation}
value={dirent filename, dirent offset}
OR value={dirent offset, dirent filename}
I guess you do see the value of my proposal to the "reverse lookup"
workload. The question is what is the cost (in code complexity/
maintainability) of special casing directory parent pointer format
and whether it is worth the benefits of "reverse lookup" performance.
Thanks,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
