On Mon, Mar 19, 2018 at 5:03 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Mon, Mar 19, 2018 at 1:02 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> Given that overlay has a persistent inode numbering problem, why >> doesn't overlay just allocate and store it's own inode numbers and >> other required persistent state in an xattr? > > First, this is not as simple as it sounds. > If you have a huge number of readonly files in multiple lower layers, > it makes no sense to scan them all on overlay mount to discover which > inode numbers are free to use and it make no sense either to create > a persistent mapping for every lower file accessed in that case. > And there are other problematic factors with this sort of scheme. Such as when all layers are read-only. Where do we store the persistent inode numbers in that case? > > Second, and this may be a revolutionary argument, I would like to > believe that we are all working together for a "greater good". > Sure, xfs developers strive to perfect and enhance xfs and overlayfs > developers strive to perfect and enhance overlayfs. > But when there is an opportunity for synergy between subsystems, > one should consider the best solution as a whole and IMHO, > the solution of filesystem declaring already unused ino bits > is the best solution as a whole. xfs is not required to declare > s_max_ino_bits for all eternity, only for this specific super block > instance, in this specific kernel. The "specific kernel" part requires clarification. We do promise backward compatibility when upgrading the kernel, and silently increasing s_max_ino_bits on a kernel upgrade would break that promise. Could be backed by a feature flag. And unlimited use could be the default, people have learned to live with needing special features for overlayfs. And I do agree with Amir, that the "mine all mine" philosophy isn't necessarily the right one. In normal cases overlayfs would just use one or two bits of the inumber space. While Amir's current patch keeps the layer index in the spare bits, it is sufficient to hold an "fs index" that is incremented when a new superblock is encountered during enumeration of layers. The number of different fs instances used for creating an overlay is unlikely to be large, so for all practical purposes a few (4-6) bits should be enough. Thanks, Miklos -- 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
