[Unionfs] Re: Exporting a union with NFS4 ?

[Jesse I Pollard]

pascal at pabr.org wrote:
> Jesse I Pollard wrote:
>> pascal at pabr.org wrote:
>>> So would it be possible to export unions over NFS4 if we initialized
>>> sb->s_export_op in unionfs_read_super(), along the lines of what was
>>> done in unionfs-1.4 ?
>>>
>>> Does anyone have a patch which does that ?  I do not mind if it only
>>> supports lower filesystems with small inode numbers or if branches
>>> cannot be added/removed afterward.
>> nope. been there, tried that.
>
> Thanks for the feedback...  But did you discover that there are
> fundamental incompatibilities, or only that it did not work as
> easily as expected ?

There were fundamental incompatibilities. The base requirement that
was laid out, is two required functions: fh_to_dentry, and fh_to_parent.
These are defined in the 1.x series, are insufficient for the 2.x.

The ODF version has a complete new file: export.c, which has all of
the export_ops functions defined (5 functions + some supporting
functions). I know there are plans to merge the ODF release into
the regular 2.x release, and maybe there could be an option for
the ODF portion included.

I'm hoping to find a way to include an option for a "copyup" flag,
so I could turn on copyup on read as well as write. This would help
with NAS migration as it would protect the files metadata, which
external methods cannot do. At a minimum inode change date would
always be changed.

It MIGHT be possible to port this file back, but I don't know how
compatible this would be as there are a number of internal changes.
There are more internal functions that appear to be used that are
not necessary with volitile handles.

One problem the lack of ODF support causes is the "contamination"
of the file space for whiteout/rename support.

Oh, one other thing that I forgot to mention: The NFS export must
specify the FSID in the /etc/exports file:

/mnt/fsname    remotehost(rw,fsid=10)

The "fsid=10" is needed, though the value 10 seems pretty arbitrary.