Re: [RFC][PATCH 00/13] overlayfs stable inodes

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

 



On Thu, Apr 20, 2017 at 1:15 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote:

> I recall there was a similar issue with GlusterFS assuming only 32-bit
> readdir cookies on ext4, and stashing some information in the high bits,
> but that broke when ext4 moved to 64-bit readdir cookies to avoid hash
> collisions on "normal sized" directories (above ~32k entries).
>
> I'd agree that it is the filesystem's prerogative to use any/all of the
> 64-bit inode number when it wants, and stacking filesystems shouldn't
> try to usurp those bits for something else, only to suffer later on.

Thought experiment:  we extend statx with 128bit inode numbers; is it
now the filesystems' prerogative to use all of the 128 bits for what
it wants?

See the flaw with that reasoning?

Ideally we'd want dynamically sized inode numbers and we have that:
file handles.  But file handles do more than inode numbers and they
are more heavyweight.


> There is already some interest to add 64-bit inode numbers for ext4, and
> it may allocate inode numbers sparsely, so just because the filesystem has
> 2^33 inodes in it doesn't imply that the highest possible inum is 2^33,
> but could instead be 2^48 or something else entirely.

Exactly.

I'm not saying we should limit filesystems use of MSB's but that
filesystems should be able to say that they will use at max say 56
bits or whatever.   They would be free to say they use all 64, but
that would limit their use in stacking filesystems so they may not
want to do that.

Is that not reasonable?

Thanks,
Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux