CentOS 7, Xfs

Home » CentOS » CentOS 7, Xfs
CentOS 6 Comments

Well, I’ve set up one of our new JetStors. xfs took *seconds* to put a filesystem on it.

We’re talking what df -h shows as 66TB.

(Pardon me, my mind just SEGV’d on that statement….)

Using bonnie++, I found that
a) GPT and partitioning gave was insignificantly different than creating an
xfs filesystem on a raw disk. I’m more comfortable with the partition, though.
b) There was a small but significant difference if, when I created the filesystem,
if I gave sw and su in the mkfs.xfs command.

I do have a question for the group mind, though: mounting these monstrous partitions… should I, or, in fact, do I *need* to give, as a mount option inode64? There will be a *lot* of files on this sucker…. What are the pros and cons of that?


6 thoughts on - CentOS 7, Xfs

  • yes, you need inode64, as without it, it will be unable to create directories after the first 2TB(?) fills up.

    the only negative impact I’ve found for inode64 is, if this volume is used as an NFS server, and you share directories deeper than the root of the file system, NFS can’t handle 64 bit id numbers, and defaults to using the inode # of the directory as the filesystem ID.

    solution 1) only share the file system base

    solution 2) create ALL the directories that will be NFS shared BEFORE
    you fill up the volume, then the exported inode numbers will be quite low.

    solution 3) specify a fsid with a unique integer for each export. these integers only need to be unique within the volume, I just use 1, 2,
    3… for the shares. example /etc/exports …



  • I have recently found that with XFS and inode64, certain applications won’t work properly when the file system is exported w/NFS4 to a 32-bit system, such as firefox and gnome.


  • Steve Thompson wrote:
    directories won’t work properly when the file system is exported w/NFS4 to a 32-bit system, such as firefox and gnome. That’s one problem we don’t have – I think even all the workstations, though some are > 5 yrs old, are all 64 bit.

    Thanks for the warning, though.


  • Close, it’s 1TB. But you won’t be able to create *any* new inodes, directories or files.


    The FAQ suggests using inode64 for any filesystem larger than 1TB. You can probably get away with not using it for larger filesystems unless you’re planning on having half of your filesystem be inodes. But 66TB
    practically requires inode64; it’d be insane not to use it.

    Are you exporting the root of the filesystem or using a nondefault fsid type?


    I think that if you’re exporting a 66TB filesystem, and exporting to a
    32bit client doesn’t work, then you have to bite the bullet and not allow the 32bit client, or do something like create a smaller filesystem to export for 32bit clients. You really can’t have such a large filesystem and not use inode64.