On 5/8/18 4:57 PM, Allison Henderson wrote:
> On 05/08/2018 02:17 PM, Eric Sandeen wrote:
...
>>> Ok, it took me a minute to remember why I did this too. We had ended up adding a parameter to libxfs_dir_createname to get the offset needed for creating the parent pointer in the protofile, and I ended up following the compiler errors back around the repair code that uses the same function calls as well.
>>
>> Except that this patch isn't fixing the parameter count, it's changing it from NULL, right?
>>
>> @@ -1170,7 +1181,7 @@ mv_orphanage(
>> libxfs_defer_init(&dfops, &first);
>> err = -libxfs_dir_createname(tp, orphanage_ip, &xname,
>> - ino, &first, &dfops, nres, NULL);
>> + ino, &first, &dfops, nres, &offset);
>>
>>
>> ...I wonder if there's much hope for doing this series in a bisectable way. :)
>>
>>> Maybe I should make a separate patch just for the offset like the kernel space set does, and then have two smaller patches for the protofile and repair code.
>>
>> That might be good. Any hint about what the attr_repair.c changes are?
>>
>> Thanks,
>> -Eric
>>
> Oh, you're right. I probably just tracked it down then. Reasoning that anything using it would likely need the pptr update to go along with it. It can still be a separate patch though.
It's fine by me if the commit is something like "xfsprogs: update parent pointers in mkfs and repair"
It's just confusing to have a terse commit log stating that it does one thing, and in fact it is doing 3 unrelated things.
> The changes in repair/attr_repair.c are because the parent pointer names are not strings, they are the binary {ino, gen, diroffset}. So it doesnt make sense to run a name check on them. I'll try to get something added to only skip the check for pptrs though.
Ah, that makes sense (and sounds necessary) - we can't skip the check on every attribute name just because it might possibly be a parent pointer.
Thanks,
-Eric
--
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
