Re: [PATCH v4 00/15] overlayfs constant inode numbers

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

 



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



[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