[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...
|