On Fri, Sep 16, 2016 at 10:56 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > Inode exhaustion? > > If the installer is going to create the file system used for overlayfs > backing storage with ext4, that probably means mkfs.ext4 -i 4096 will > need to be used; so how does that get propagated to only AH installs, > for both automatic and custom partitioning? Or figure out a way to > drop custom/manual partitioning from the UI. Or does using XFS > mitigate this issue? A simple search turns up no inode exhaustion > reports with XFS. The work around for ext4 is at mkfs time, it's not > something that can be changed later. I just did some more digging, and also chatted with Eric Sandeen about this. Here's what I've learned: - Inode exhaustion with mkfs.ext4 defaults can be a real thing with overlayfs [1] - mkfs.ext4 -i 4096 will make 1 inode per 4096 byte block, so 1:1, which is a metric shittonne of inodes - a different -i value might be more practical most of the time, but if the maximum aren't created at mkfs time and are exhausted the fs basically face plants and no more files can be created; and it's only fixable by a.) deleting a bunch of files or b.) creating a new file system to have more inodes preallocated. - mkfs.ext4 hands off the actual creation of the inodes to lazy init at first mount time, it's a lot of metadata being written to do this - XFS doesn't have this issue, its inode allocation is dynamic (there are limits but can be changed with xfs_growfs) - XFS now defaults to -m crc=1, and by extension -n flags=1 which overlayfs wants for putting filetype in the directory entry; Fedora 24 had a sufficiently new xfsprogs for this from the get go. I don't know what the workflow is for creating the persistent storage for the host, whether this will be Anaconda's role or something else? If Anaconda, my experience has been the Anaconda team are reluctant to use non-default mkfs unless there's a UI toggle for it. You'd need to run all this by them and see if there's a way to do a mkfs.ext4 -i 4096 for just Atomic Host installations, there's no point doing that for workstation installations. Or just use XFS. [1] https://github.com/coreos/bugs/issues/264 https://github.com/boot2docker/boot2docker/issues/992 -- Chris Murphy _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
