[Rpm-maint] [rpm-software-management/rpm] rpm --rebuilddb in an overlayfs without redirect_dir=on (Discussion #2905)

Michal Domonkos notifications at github.com
Tue Feb 13 16:59:11 UTC 2024


> 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/8456461 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240213/6ddd6561/attachment.html>


More information about the Rpm-maint mailing list