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....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
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
