[Unionfs] whiteouts and object removal inconsistency
Bharata B Rao
bharata.rao at gmail.com
Thu Aug 23 00:32:21 EDT 2007
On 8/22/07, Yiannos Pericleous <yiannnos at gmail.com> wrote:
> On 22/08/07, Bharata B Rao <bharata.rao at gmail.com> wrote:
> > Hi Josef/Erez,
> > In Unionfs with ODF, since you have the concept of per-union whiteout,
> > the removal of objects from unions is not shared IIUC. But when trying
> > out the ODF patch, I hit upon a few cases which appear inconsistent to
> > me.
> >
> > Consider 2 directories a/ and b/ with a file in each of them.
> > #ls a/
> > top
> >
> > #ls b/
> > bottom
> >
> > Let these two be union mounted at union1/ and union2/ separately with
> > a/ being the topmost branch in both. Here a/ is mounted rw and b/ is
> > mounted ro.
> > (mount -t unionfs -o odf=/odf/odf1,dirs=a=rw:b=ro none union1
> > mount -t unionfs -o odf=/odf/odf2,dirs=a=rw:b=ro none union2)
> >
> > Case 1: removal of 'bottom' in b/ from union1/
> > In this case a whiteout gets created for 'bottom' under union1(in ODF
> > i,e.,) and subsequently it becomes invisible from union1/ (as
> > expected).
> > But the removed file continues to be visible from union2/ as the
> > whiteout is per-union and union2/ doesn't know about the whiteout that
> > got created in union1/
>
> This is expected since: as b is ro, the whiteout is created only for union1
> and gets recorded in odf1. Now odf2 knows nothing about this wh and since
> the file was not physically removed it appears in union2
>
>
> > Case 2: removal of 'top' in a/ from union1/
> > In this case, 'top' gets removed from the underlying filesystem itself
> > as a/ is a rw topmost layer. This makes 'top' to go away from union2/
> > also.
>
> In this case since the file exists only in a rw branch no whiteout is
> necessary and thus is not created and the file is physically removed.
> Thus the file is completely removed and appears in none of the unions.
>
> > So in the first case, the removal of an object from a union didn't
> > affect the other union. But in the second case, it did. Isn't this
> > behavior inconsistent if we look at 'top' and 'bottom' just as files
> > in the union instead of thinking them as files lying in different
> > layers of the union ? So is this the expected behavior ? If so how do
> > you explain this seemingly inconsistent behavior ?
>
> I would say this is the expected behavior since whiteouts are
> created only when necessary.
I get it, but what I am trying to highlight is the behavior of
removing a file from a union is different depending on where the file
is in the union. Isn't that kind of unexpected ? Removal from unions
should either be shared or not, but we here we have situations where
sometimes it is shared and sometimes not. But again there are many
such situations where it simply might not be worth or not possible to
support a uniformly consistent behavior.
>
> > Case 3: removal from rw lower layer
> > Consider the same scenario as above, but the lower layer(b) is mounted
> > rw instead of ro in both the unions. Now the removal of file 'bottom'
> > from union1/ gets effected on the underlying filesystem itself and
> > hence gets reflected in union2 also. So again this is not consistent
> > with the behavior in Case 1.
>
> Same as case 2, since the branch is rw and the file can be removed
> it is removed and no whiteout is necessary
Again behavior varies depending on whether the lower layer is ro and rw.
The motivation behind the question was to understand what is the
expected (sane) behavior of removal in various cases and understand
the pros and cons of per-union vs per-branch whiteouts(as we do in
union mounts).
Thanks for your reply.
Regards,
Bharata.
More information about the unionfs
mailing list