Re: No space left on device

[Turbo Fredriksson <turbo@bayour.com>]

[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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs