On Fri, Sep 16, 2016 at 2:15 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> 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.
Another possibility is an AH specific /etc/mke2fs.conf file on the
installation media only.
[defaults]
base_features =
sparse_super,large_file,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 0
blocksize = 4096
inode_size = 256
inode_ratio = 16384
By changing inode_ratio = 4096, it achieves the same outcome as -i
4096 without having to pass that flag at mkfs time. And it'd only
affect installation time file systems (including /boot and / as well
as the persistent storage for overlayfs and containers). So... yeah.
FWIW, you're basically already using XFS with the dm-thin
docker-storage-setup you've got going on right now. It doesn't get
mounted anywhere, but
$ docker info
[chris@localhost ~]$ sudo docker info
[sudo] password for chris:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.10.3
Storage Driver: devicemapper
Pool Name: fedora--atomic-docker--pool
Pool Blocksize: 524.3 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
So, just use XFS across the board (plus overlayfs on the persistent
storage for containers).
As for Workstation changing file systems, that's another ball of wax.
I'd just say use XFS + overlayfs there too to keep it simple across
the various products in the near term. And then presumably the
Workstation folks will want Btrfs when it sufficiently stable that the
kernel team won't freak out if there's still no Btrfs specific kernel
dev on the team or at Red Hat.
--
Chris Murphy
_______________________________________________
cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
