unionfs: ULFS information storage issues

[Sergiu Ivanov]

Hello,

On Fri, Aug 14, 2009 at 11:23:22PM +0200, Thomas Schwinge wrote:
> On Fri, Aug 14, 2009 at 10:26:10PM +0300, Sergiu Ivanov wrote:
> 
> > You are right -- if a node contains more node_ulfs entries than there
> > are registered in ulfs_chain, then something has gone seriously
> > corrupted.  However, I have a question, which is related to
> > consistency (again *sigh*): ulfs_get_num is invoked in two places
> > only: in netfs_attempt_sync and in node_init_root (node.c:533 in my
> > code version).  In node_init_root the return value of ulfs_get_num is
> > checked in an if statement.  Is it alright to check this value via an
> > assert in netfs_attempt_sync?  Or should I change the handling of the
> > return value in node_init_root instead?
> 
> I don't really know the unionfs code, but if these two structures are
> always meant to be kept synchronized (which I don't really know, so you'd
> have to verify that -- or unify these structures, which was the long-term
> plan, isn't it?), then a fatal error (assert) is OK.

I don't remember any snippets of the unionfs code where the ULFS list
and the list of ports in the root node were intentionally kept
unsynchronized.  However, it seems I can see the reason for the lists
being maintained separately: *each* unionfs node contains a list of
ports to the corresponding nodes in the underlying filesystems.  If
one would like to keep *both* the information about the filesystems
*and* the ports to their root nodes in *a single* place, one would
have two choices: either add something like a ``port'' field to each
entry in the ulfs_chain, thus duplicating the port list in the
netfs_root_node and still leaving the necessity of synchronizing
things explicitly; or keep the information about the filesystems
(i.e. the information stored in ulfs_chain) in *every* node, thus
duplicating the same bits of information across a (potentially) large
number of locations.

Unfourtunately, it seems that solving this issue without deep thinking
is not something easily achieved :-(

Regards,
scolobb