John R Pierce wrote:> On 8/4/2015 7:14 AM, m.roth at 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
----- Original Message ----- | John R Pierce wrote: | > On 8/4/2015 7:14 AM, m.roth at 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 -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 604-365-6432 Fax : 778-782-3045 E-Mail : jpeltier at sfu.ca Website : http://www.sfu.ca/itservices Twitter : @sfu_rcg Powering Engagement Through Technology
James A. Peltier wrote:> ----- Original Message ----- > | John R Pierce wrote: > | > On 8/4/2015 7:14 AM, m.roth at 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
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 problematicThe 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