On Tue, Mar 20, 2018 at 10:04 AM, Ian Kent <raven@xxxxxxxxxx> wrote: > Hi Amir, Miklos, > > On 20/03/18 14:29, Amir Goldstein wrote: >> >> And I do appreciate the time you've put into understanding the overlayfs >> problem and explaining the problems with my current proposal. >> > > For a while now I've been wondering why overlayfs is keen to avoid using > a local, persistent, inode number mapping cache? > A local persistent inode map is a more complex solution. If you remove re-factoring, my patch set adds less than 100 lines of code and it solves the problem for many real world setups. A more complex solution needs a use case in the real world to justify it over a less complex solution. I am not saying we can avoid the complex solution forever, but so far, I did not yet see the requests from users to justify it. > Sure there can be subtle problems with them but there are problems with > other alternatives too. > There is a difference between "not applicable" and "problematic" The -o xino solution is not applicable to all setups, but I am not aware of any problems with this solution. Even without underlying filesystem declaring number of used ino bit, user can declare this with overlayfs mount option, so practically, the problem for overlayfs over xfs is already solved. The discussion about a VFS API for max_ino_bits is to make users life easier, but the API is not required to fix the overlayfs inode number problem. Thanks, 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
