Re: Overlay Filesystem Documentation page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 22, 2024 at 7:27 PM Edouard Gaulué <edouard@xxxxxxxxxxxx> wrote:
>
> I tried to provide a proposal, but I worry there are too much thing I don't fully understand.
>
> Could you look at this "use case" and associated questions (I tried to answer some)? With those answers, I should be able to propose something for the first 2 paragraghs.
>
> /dir1 : production website
> /dir2 : website source code (git repo)
> /dir3 : transitional
> /dir4 : workdir
> /dir5 : dev website
>
> Mount command: sudo mount -t overlay overlay -o lowerdir=/dir2:/dir1,upperdir=/dir3,workdir=/dir4 /dir5
>
> According to me, undefined behaviour is coming from xattrs created in /dir3. So, everytime a file is changed in /dir2: /dir3 is emptied and /dir5 is remounted.
>
>
> Q1: If “metacopy”, “index”, “xino” or “redirect_dir” is not used, do we really need to empty /dir3 ? Should be 'no' due to the fact we won't have those specifics xattrs.

hard to answer what you *should* do.
only thing I can say is that the results would be quite predictable -
dir5/ will be the merge of dir1+dir2+dir3 as one could expect.

Note that there are some other xattr in dir3 files - "origin", "impure"
Specifically, "origin" is always set on copy up and there is no way to
opt out from it. if does have some impact in this scenario related to which
inode numbers files in dir5/ will have after this maneuver
I have no desire to document the expected behavior in this regard.

>
> Q2: If “metacopy”, “index”, “xino” or “redirect_dir” is used. Does emptying /dir3 before remount remove all possible undefined behaviours ? Should be 'yes', we are restarting from scratch.
>

dir3 itself also has xattrs, so it needs to be recreated.
dir4 (the workdir) as well.

> Q3: Knowing that the website will never modify any files in /dir2 (neither production nor dev), do we really need to remount the overlay everytime a file is changed in /dir2 ?
> Files in /dir3 will never overlap with those in /dir2. There shouldn't be any xattrs inconsistency. Is there other risks?
>

Yes.
Overlay has many caches. Changing lower layers while overlay is
mounted will have unpredicted outcome.

> Q4: If production website generate cache files in /dir1 and dev website generate cache files in /dir3 that may opverlap. What are the risks? For /dir1: I suppose none. For /dir3 ? And /dir5 ? In ohter words, what do we mean by "the behavior of the overlay is undefined"? Could we say : "we don't know which layer file will be served"? Or is it worse?
>

For changes while overlay is mounted could be much worse.
Let's just say that the statement "...though it will not result in a
crash or deadlock."
is not really a promise - it is only a statement of intentions.

For changes while overlay is offline you wont know which file will be served
and it is quite possible the -EIO will be served in many cases.

> Q5: Would mount -t overlay overlay -o lowerdir=/dir2:/dir1 /dir5 get to an undefined behavior, if changes to /dir1 or /dir2 are made? According to me, as /dir5 is RO, it should work, always respecting /dir2 priority above /dir1.

For changes while overlay is mounted, same answer as above.
For changes while overlay is offline, same answer as for Q1.
results should be quite predictable - dir5 will be the merge of dir1+dir2.

Please refrain from proposing detailed documentation on what "undefined"
behavior means to kernel documentation, because I do not want to commit
to any specific "undefined" behavior in the future.

Thanks,
Amir.





[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux