32bit apps and inode64

[Dave Chinner]

On Sat, Feb 16, 2013 at 11:24:13AM +0100, Stefan Priebe - Profihost AG wrote:
> I'm on linux. So no recommended way for production systems?
> 
> Stefan
> 
> Am 15.02.2013 um 22:46 schrieb Ben Myers <bpm at sgi.com>:
> 
> > Hi Stefan,
> > 
> > On Fri, Feb 15, 2013 at 04:06:40PM +0100, Stefan Priebe - Profihost AG wrote:
> >> i've discovered some problems on a host with a disk > 1TB. We've some
> >> binary 32bit applications which are not able to read some directory
> >> anymore after we've formated and installed the system using vanilla
> >> 3.7.7 kernel.
> >> 
> >> Right now we're using 3.0.61 kernel on this host - so 64bit apps work
> >> well and newly created files get 32bit inode numbers as inode64 is not
> >> the default.
> >> 
> >> Is there a way to find / get all 64bit inode files / dies and convert
> >> them back to 32bit without a reinstall?
> > 
> > On IRIX you could use xfs_reno to renumber those inodes.
> > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat1/xfs_reno.z
> > 
> > xfs_reno was ported to linux in '07 and was most recently reposted by Jeff Liu:
> > http://oss.sgi.com/archives/xfs/2012-11/msg00425.html
> > 
> > It isn't in xfsprogs today.

Simple answer: mount with inode32, run find to print out all the
filenames in the filesystem and their inode number, copy the files
with inodes numbers greater than 32 bit to a temporary file and then
rename them over the top of the original.

That's effectively all xfs_reno does, anyway, just with faster
algorithms (like bulkstat) and a bunch of crash resiliency semantics
wrapped around it....

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com