On Thu, May 4, 2017 at 1:18 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 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...
>
If you do like the idea, let me know if you want me to send a patch on
top of v5.
Do you plan to push v5 (+ "else if" bugfix) to overlayfs-next?
If we go for my solution to endianess, we can add that patch
as a fix patch (same goes for null uuid).
Amir.
