John R Pierce wrote:

On 8/4/2015 7:14 AM, m.roth@5-cent.us wrote:

...

CentOS 6.6 (well, just updated with CR). I have some xfs filesystems on a RAID. They've been mounted with the option of defaults. Will it break the whole thing if I now change that to inode64, or was that something I needed to do when the fs was created, or is there some conversion I can run that won't break everything?

you can enable that option at any time, but once you've used it, you can't go back.

note that 64 bit inodes cause a minor issue with NFS if you have shares exported other than the root. there's an easy workaround.

Thanks, John. I believe I did exports elsewhere, last year. This just came up on a huge backup RAID - the rsync was failing, though there was plenty space, and inode64 just popped up from my stack - it was just the conversion that I didn't remember the answer to.

For those looking at this, here's a gotcha: you *cannot* change fstab, then mount -o remount, you *must* umount, then mount. Merely -o remount fails to make the change.

mark

James A. Peltier wrote:

----- Original Message ----- | John R Pierce wrote: | > On 8/4/2015 7:14 AM, m.roth@5-cent.us wrote: | >> | >> CentOS 6.6 (well, just updated with CR). I have some xfs filesystems | >> on a RAID. They've been mounted with the option of defaults. Will it break | >> the whole thing if I now change that to inode64, or was that something | >> I needed to do when the fs was created, or is there some conversion I | >> can run that won't break everything? | > | > you can enable that option at any time, but once you've used it, you | > can't go back. | > | > note that 64 bit inodes cause a minor issue with NFS if you have shares | > exported other than the root. there's an easy workaround. | | Thanks, John. I believe I did exports elsewhere, last year. This just came | up on a huge backup RAID - the rsync was failing, though there was plenty | space, and inode64 just popped up from my stack - it was just the | conversion that I didn't remember the answer to. | | For those looking at this, here's a gotcha: you *cannot* change fstab, | then mount -o remount, you *must* umount, then mount. Merely -o remount | fails to make the change. | | mark

Some older 32-bit software will likely have problems addressing any content outside of the 2^32 bit inode range. You will be able to see it, but reading and writing said data will likely be problematic

Fortunately, I think we've gotten rid of all our 32-bit servers, which is where people work, and workstations, as well.

mark

----- Original Message ----- | On 8/4/2015 12:47 PM, James A. Peltier wrote: | > Some older 32-bit software will likely have problems addressing any content | > outside of the 2^32 bit inode range. You will be able to see it, but | > reading and writing said data will likely be problematic | | | The 99% of software that just does open,read,write will be fine | regardless of word size. | | NFS is the only broken thing I ran into (on CentOS 6 anyways), and then | only if you export subdirectories in the XFS file system, if you just | export the root of it, you won't have any issues. if you are | exporting subdirectories (something I find Windows admins like to do), | then you have to specify a locally unique integer fsid on each export. | I just use fsid=1, fsid=2, ... | | | | | -- | john r pierce, recycling bits in santa cruz

This is not at all our findings on large file systems or filesystems with large numbers of inodes. We in fact on many occasions ran into such problems. To the OP, if you're 64-bit everywhere there's no problems so enjoy the benefits of XFS ;)