[please keep all communication on/to the list for posterity] On 27 sep 2010, at 18.26, Turbo Fredriksson wrote: > On 27 sep 2010, at 18.06, Geoffrey Wehrman wrote: > >> | > or to a much more recent kernel, and the problem will go >> | > away. >> | >> | How recent? >> >> Based on the following FAQ, 2.6.35 or later. >> http://xfs.org/index.php/XFS_FAQ#Q:_Can_I_just_try_the_inode64_option_to_see_if_it_helps_me.3F > > That only stated that you can/could switch back > and forth between 32/64bit. Not that it was/is > solved - or solve my problem. > > But thanx. I'll try a later kernel then. > > > Ok, so 2.6.35.6 is the very latest!! I'm running > 2.6.32, which is ancient... I had expected a much > higher minor version... Thanx! Ok, I'm now at 2.6.35.6, AMD64 compiled, which let me create more files - using the inode64 mount option and/or (did both at the same time :) moving what I think was the first 5Gb data. Unfortunately, I'm still using a 32bit user land (can't upgrade at the moment). celia:~# uname -a Linux celia 2.6.35.6 #1 SMP Sat Oct 2 09:12:38 UTC 2010 x86_64 GNU/Linux celia:~# file `which xfs_db` /usr/sbin/xfs_db: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped celia:~# xfs_info /share meta-data=/dev/mapper/movies-movies isize=256 agcount=340, agsize=6104768 blks = sectsz=512 attr=1 data = bsize=4096 blocks=2075610112, imaxpct=10 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime=none extsz=65536 blocks=0, rtextents=0 The big question is now, what do I do if/when (soon) I have to grow the FS?! On 24 sep 2010, at 17.23, Geoffrey Wehrman wrote: > On Fri, Sep 24, 2010 at 04:07:23PM +0200, Turbo Fredriksson wrote: > | The worst thing is that every time I grow > | the FS, I have to reboot into a 32bit kernel: > | > | xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument > > This may be becuase your are running 32bit userland. On 24 sep 2010, at 23.17, Geoffrey Wehrman wrote: > On Fri, Sep 24, 2010 at 10:46:47PM +0200, Turbo Fredriksson wrote: > | On 24 sep 2010, at 17.23, Geoffrey Wehrman wrote: > | > Once you have 64bit inodes, it is difficult to go back to 32bit inodes. > | > | Figured that.. But will the growfs stop working? > > The 64 bit growfs should work. > > | I assume it won't help just recompiling the XFS > | binaries since my libs et all is/will be 32bit?. > > Correct. You must have a 64 bit application/libraries/kernel. Will my current kernel, but compiled as 32bit, work without upgrading to a 64bit user land? Or is 2.6.35.6 also fixing the XFS_IOC_FSGROWFSDATA problem I've been getting on 2.6.32/64bit? But I guess I can't use that older kernel any more, since I'm now using 64bit inodes. The FAQ mentioned above, do say that I'm supposed to go back and forth, but ... I'm a coward! (Actually, I used to call myself 'careful', but I guess it's really the same thing - also, I don't care any more :). It doesn't seem reasonable that I could create a bigger (i.e. 64bit) inode table - and files in that table, switch back to a kernel that only understands 32bit inode tables (correctly and/or 'is buggy'), grow the FS, and then go back to using 64bit inodes and still have all those files created in the 64bit inode table... _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
