On Thu, May 4, 2017 at 12:15 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> One more little detail: file handle byte order. We store the fh in a
> filesystem, which means it can be used by systems with different
> endianness, which basically invalidates it. This scenario is highly
> unlikely to happen in practice, so for simplicity perhaps we should
> just store a bit into the origin structure indicating the byte order
> used to create the file handle and verify it when using it.
>
> Thoughts?
>
Yes, just noticed this wrinkle myself.
Ideal world though:
file handles are exported over the network and should have been in
network order.
What if NFS server goes dead and a hot backup with different endianess
takes over? (even less likely than our use case).
Theoretically, filesystems could still be fixed to export (i.e.
ino/generation) in
network order, but that's not very practical for the question at hand.
Practical thought:
Instead of storing endieness bit in every single ovl_fh,
Store this handle at upper root overlay.origin:
#define OVL_ROOT_INO 2
static const struct ovl_root_fh {
struct ovl_fh hdr;
ino_t ino;
} root_fh = {
.hdr = {
.version = OVL_FH_VERSION,
.magic = OVL_FH_MAGIC,
.type = FILEID_ROOT,
.len = sizeof(struct ovl_fh) + sizeof(ino_t),
},
.ino = OVL_ROOT_INO,
};
I realize that storing an integer overlay.one is 'simpler',
but I'm withdrawn to (my idea of) elegance...
Also, if you agree to check cross-endianess mount once at mount time,
then you should probably also restore the ofs->redirect_fh boolean, so
you can turn redirect_fh off at mount time... Don't you have to do that
anyway for the uuid_is_null() check?
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
