Hi Arne,
(pls don't take this as if I pretend to have understood the code
better than you, because I have a list of questions for Alexander
too).
>> +/*
>> + * Helper function to generate a file name that is unique in the root of
>> + * send_root and parent_root. This is used to generate names for orphan
>> inodes.
>> + */
>> +static int gen_unique_name(struct send_ctx *sctx,
>> + u64 ino, u64 gen,
>> + struct fs_path *dest)
>> +{
>> + int ret = 0;
>> + struct btrfs_path *path;
>> + struct btrfs_dir_item *di;
>> + char tmp[64];
>> + int len;
>> + u64 idx = 0;
>> +
>> + path = alloc_path_for_send();
>> + if (!path)
>> + return -ENOMEM;
>> +
>> + while (1) {
>> + len = snprintf(tmp, sizeof(tmp) - 1, "o%llu-%llu-%llu",
>> + ino, gen, idx);
>
> wouldn't it be easier to just take a uuid? This would save you a lot
> of code and especially the need to verify that the name is really
> unique, saving seeks.
As far as I understand the logic of orphans, the unique name should
depend only on the send_root and parent_root contents, which are both
frozen. So when you re-generate this name for a particular (ino,gen),
you must receive the same exact name every time. If the user has kind
of oXXX-YY-Z file(s) in the top dir by accident, then they are the
same every time we recalculate the orhpan name, so we get the same
result every time. Does it make sense?
So did you mean to generate a uuid here, and save it somewhere
in-memory, and later look it up based on (ino,gen)? Or you mean some
other improvement?
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
