summaryrefslogtreecommitdiff
path: root/Documentation/filesystems/overlayfs.rst
diff options
context:
space:
mode:
authorAmir Goldstein <amir73il@gmail.com>2020-02-21 16:34:45 +0200
committerMiklos Szeredi <mszeredi@redhat.com>2020-03-27 16:51:02 +0100
commit926e94d79baf76ce7a4d26c3116b6d85a77a475b (patch)
treebc9b8e116125fcde78ba41f6b048725cdd6171ac /Documentation/filesystems/overlayfs.rst
parentdfe51d47b7eeb5642ed92558b62eeff558f00eda (diff)
downloadlinux-rpi-926e94d79baf76ce7a4d26c3116b6d85a77a475b.tar.gz
linux-rpi-926e94d79baf76ce7a4d26c3116b6d85a77a475b.tar.bz2
linux-rpi-926e94d79baf76ce7a4d26c3116b6d85a77a475b.zip
ovl: enable xino automatically in more cases
So far, with xino=auto, we only enable xino if we know that all underlying filesystem use 32bit inode numbers. When users configure overlay with xino=auto, they already declare that they are ready to handle 64bit inode number from overlay. It is a very common case, that underlying filesystem uses 64bit ino, but rarely or never uses the high inode number bits (e.g. tmpfs, xfs). Leaving it for the users to declare high ino bits are unused with xino=on is not a recipe for many users to enjoy the benefits of xino. There appears to be very little reason not to enable xino when users declare xino=auto even if we do not know how many bits underlying filesystem uses for inode numbers. In the worst case of xino bits overflow by real inode number, we already fall back to the non-xino behavior - real inode number with unique pseudo dev or to non persistent inode number and overlay st_dev (for directories). The only annoyance from auto enabling xino is that xino bits overflow emits a warning to kmsg. Suppress those warnings unless users explicitly asked for xino=on, suggesting that they expected high ino bits to be unused by underlying filesystem. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'Documentation/filesystems/overlayfs.rst')
0 files changed, 0 insertions, 0 deletions