> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the atomicity: when you set an `xattr` to
> the orignal dir then `rename()` the copied up dir, though this means 2
> actions, the `rename()` is atomic since no data is actually copied. My
> understanding is that such actions are somehow "prepared" in the `workdir`.
Indeed, the `redirect_dir` feature looks like an optimization. That said, I'm
not sure what happens internally in OverlayFS when you actually do a "copy-up".
I'd assume no data is physically copied either, unless it changes in the upper
layer, but that's again just a guess.
> I don't know if in the` rpm --rebuilddb` you need this atomicity or not but
> that would be the first question to be answered I think ?
I think atomicity is not a concern here - that's hopefully ensured by the
(OverlayFS) filesystem, regardless of whether we choose to do a regular copy of
the old directory (to trigger a copy-up) or use the `redirect_dir` feature.
However, I believe we should do (if we decide to implement this) the former
since that's reasonably filesystem-agnostic, unlike the latter (which is,
again, OverlayFS specific).
In any case, thanks for pointing out `redirect_dir`, I wasn't aware of it
before!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456461
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2905/comments/8456...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
