free space problem

free space problem

[Huszár Viktor Dénes]

Hi all,

 

we encountered a problem with XFS free space and perhaps reserved space. It
reports to have 82 gb free on the raid, however its not possible to write on
the file system. Please tell me if you need more details, we have read
through the previous free space threads, but found nothing useful. We run
2.6.23 kernel.

 

Thanks in advance,

 

Vic



[[HTML alternate version deleted]]

Re: free space problem

[Emmanuel Florac]

Le Sun, 30 Mar 2008 22:29:06 +0200 vous écriviez:

>  We run
> 2.6.23 kernel.

Look in /var/log/messages and the output of dmesg command for xfs
related messages and post them here, please. 

-- 
--------------------------------------------------
Emmanuel Florac               www.intellique.com   
--------------------------------------------------

RE: free space problem

[Huszár Viktor Dénes]

There is nothing extraordinary in it, you can see umount-mount and that it
was mounted after all xfs activity (check, repair, db).

root@mailslave:/home/void# grep -i xfs /var/log/{messages,kern.log,syslog}
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: SGI XFS with ACLs,
security attributes, realtime, large block/inode numbers, no debug enabled
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: SGI XFS Quota
Management subsystem
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: XFS mounting
filesystem md1
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: Ending clean XFS mount
for filesystem: md1
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 18 01:46:08 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: SGI XFS with ACLs,
security attributes, realtime, large block/inode numbers, no debug enabled
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: SGI XFS Quota
Management subsystem
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: XFS mounting
filesystem md1
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: Ending clean XFS mount
for filesystem: md1
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 18 02:23:16 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: SGI XFS with ACLs,
security attributes, realtime, large block/inode numbers, no debug enabled
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: SGI XFS Quota
Management subsystem
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: XFS mounting
filesystem md1
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: Ending clean XFS mount
for filesystem: md1
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 18 02:34:13 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: SGI XFS with ACLs,
security attributes, realtime, large block/inode numbers, no debug enabled
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: SGI XFS Quota
Management subsystem
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: XFS mounting
filesystem md1
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: Ending clean XFS mount
for filesystem: md1
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 20 09:57:50 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 26 22:05:54 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 26 22:05:54 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 27 04:32:09 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 27 04:32:09 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 27 04:36:54 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 27 04:36:54 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0
/var/log/kern.log:Mar 27 05:02:29 mailslave kernel: XFS mounting
filesystem dm-0
/var/log/kern.log:Mar 27 05:02:29 mailslave kernel: Ending clean XFS mount
for filesystem: dm-0

-----Original Message-----
From: Emmanuel Florac [mailto:eflorac@intellique.com] 
Sent: Sunday, March 30, 2008 11:55 PM
To: Huszár Viktor Dénes
Cc: xfs@oss.sgi.com
Subject: Re: free space problem

Le Sun, 30 Mar 2008 22:29:06 +0200 vous écriviez:

>  We run
> 2.6.23 kernel.

Look in /var/log/messages and the output of dmesg command for xfs
related messages and post them here, please. 

-- 
--------------------------------------------------
Emmanuel Florac               www.intellique.com   
--------------------------------------------------


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2985 (20080330) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2985 (20080330) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[David Chinner]

On Sun, Mar 30, 2008 at 10:29:06PM +0200, Huszár Viktor Dénes wrote:
> Hi all,
> 
> we encountered a problem with XFS free space and perhaps reserved space. It
> reports to have 82 gb free on the raid, however its not possible to write on
> the file system. Please tell me if you need more details, we have read
> through the previous free space threads, but found nothing useful. We run
> 2.6.23 kernel.

What is the error you are getting? Does 'dd if=/dev/zero of=/mntpt/file bs=512
count=1' work? If not, what's the error?  What's the output of 'df -h' and
'df -ih'? Output of 'xfs_info <mntpt>'?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

RE: free space problem

[Huszár Viktor Dénes]

-----Original Message-----
From: David Chinner [mailto:dgc@sgi.com] 
Sent: Monday, March 31, 2008 2:39 AM
To: Huszár Viktor Dénes
Cc: xfs@oss.sgi.com
Subject: Re: free space problem

> What is the error you are getting? Does 'dd if=/dev/zero of=/mntpt/file
> bs=512 count=1' work? If not, what's the error?  What's the output of 'df
> -h' and 'df -ih'? Output of 'xfs_info <mntpt>'?
Cheers,

Dave
--

Actually, from yesterday it started working again. So the xfs_info of
yesterday I can't send when it was not working. When it was not working, in
dd there is nothing extra. A simple no space left on device. And kernel does
not log anything (dmesg). The problem appeared suddenly and mysteriously,
and it disappeared in the same way... If it happens again, I'll send you the
info immediately. 

The problem was there for couple of days, we umounted and ran xfs_repair
several times, and we mounted it back and not even mkdir worked, or in 5-10
minutes we wrote few Gb space on the disk and still plenty of Gbs were free,
but it said: no space left on device. So if it appears again, I'll get back
to you guys. 

Im really thankful for your help! 

Viktor from Hungary, Budapest
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2987 (20080331) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

RE: free space problem

[Huszár Viktor Dénes]

-----Original Message-----
From: Emmanuel Florac [mailto:eflorac@intellique.com] 
Sent: Monday, March 31, 2008 9:40 AM
To: Huszár Viktor Dénes; xfs@oss.sgi.com
Subject: Re: free space problem

Le Mon, 31 Mar 2008 02:31:16 +0200 vous écriviez:

>Then maybe you simply ran out of inodes. It's common if you have lots
>of small files. There is a way to increase the number of inodes but I
>don't remember it right now.
--
No, unfortunately not. There are not many small files and the inode usage is
1%. See.

/bin/df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md0             5494272  154415 5339857    3% /
tmpfs                2056252       5 2056247    1% /lib/init/rw
udev                 2056252     487 2055765    1% /dev
tmpfs                2056252      10 2056242    1% /dev/shm
/dev/mapper/a-a      88427616  867107 87560509    1% /var/www/users
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2987 (20080331) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[David Chinner]

On Mon, Mar 31, 2008 at 07:36:56PM +0200, Huszár Viktor Dénes wrote:
> -----Original Message-----
> From: Emmanuel Florac [mailto:eflorac@intellique.com] 
> Sent: Monday, March 31, 2008 9:40 AM
> To: Huszár Viktor Dénes; xfs@oss.sgi.com
> Subject: Re: free space problem
> 
> Le Mon, 31 Mar 2008 02:31:16 +0200 vous écriviez:
> 
> >Then maybe you simply ran out of inodes. It's common if you have lots
> >of small files. There is a way to increase the number of inodes but I
> >don't remember it right now.
> --
> No, unfortunately not. There are not many small files and the inode usage is
> 1%. See.

Yes, but if you have fragemented free space then it is possible that there
are not enough free extents large enough (or aligned correctly) to
allocate more inodes. The number of "free inodes" reported doesn't take
this into account; it only looks at the number of free blocks and converts
that to a theoretical number of inodes that could be allocated in that
space (i.e. it assumes perfect fit and no waste). 

In this "not quite full filesystem" situation, you can write data to the
filesystem, but any attempt to create a new inode (new file, directory,
etc) will fail with ENOSPC. This sounds like the symptoms you are
reporting....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

RE: free space problem

[Huszár Viktor Dénes]

>Yes, but if you have fragemented free space then it is possible that there
>are not enough free extents large enough (or aligned correctly) to
>allocate more inodes. The number of "free inodes" reported doesn't take
>this into account; it only looks at the number of free blocks and converts
>that to a theoretical number of inodes that could be allocated in that
>space (i.e. it assumes perfect fit and no waste). 

>In this "not quite full filesystem" situation, you can write data to the
>filesystem, but any attempt to create a new inode (new file, directory,
>etc) will fail with ENOSPC. This sounds like the symptoms you are
>reporting....

>Cheers,

>Dave.

What you described might happen with lot of small files, but in our case,
our attempts fail to create a new inode and fail to write data. You suppose
that we have fractured free spaces, and on these fractures no inodes can be
created. In our case, the situation was different, however as it started to
work again I still can't provide you any xfs_info/debug.

Thanks again,
Viktor
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2989 (20080401) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

RE: free space problem

[Huszár Viktor Dénes]

Hi guys, the earlier problem came out again:

Here are the logs:

[root]~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0               42G   15G   26G  37% /
tmpfs                 7.9G     0  7.9G   0% /lib/init/rw
udev                   10M   76K   10M   1% /dev
tmpfs                 7.9G  2.2M  7.9G   1% /dev/shm
/dev/md1              420G   31G  389G   8% /var/www/users
/dev/mapper/a-a        17T   17T   51G 100% /var/www/users/sms

[root]~# df -ih
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md0                5.3M    152K    5.1M    3% /
tmpfs                   2.0M       5    2.0M    1% /lib/init/rw
udev                    2.0M     487    2.0M    1% /dev
tmpfs                   2.0M      10    2.0M    1% /dev/shm
/dev/md1                420M    398K    419M    1% /var/www/users
/dev/mapper/a-a         203M    850K    202M    1% /var/www/users/sms

[root]~# xfs_info /var/www/users/sms
meta-data=/dev/a/a               isize=256    agcount=32, agsize=137326144
blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=4394436608, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

[root]~# xfs_logprint /dev/a/a
xfs_logprint:
xfs_logprint: /dev/a/a contains a mounted and writable filesystem
    data device: 0xfd00
    log device: 0xfd00 daddr: 17577746464 length: 262144

Header 0x1 wanted 0xfeedbabe
**********************************************************************
* ERROR: header cycle=1           block=176303                       *
**********************************************************************
Bad log record header

[root]~# umount /var/www/users/sms

[root]~# xfs_repair /dev/a/a
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

[root]~# mount /var/www/users/sms

[root]~# touch /var/www/users/sms/1
touch: cannot touch `/var/www/users/sms/1': No space left on device

[root]~# xfs_logprint /dev/a/a
xfs_logprint:
xfs_logprint: /dev/a/a contains a mounted and writable filesystem
    data device: 0xfd00
    log device: 0xfd00 daddr: 17577746464 length: 262144

cycle: 1        version: 1              lsn: 1,0        tail_lsn: 1,0
length of Log Record: 20        prev offset: -1         num ops: 1
uuid: 68b5aa39-c15e-4170-a43f-9278e95911ea   format: little endian linux
h_size: 32768
----------------------------------------------------------------------------
Oper (0): tid: b0c0d0d0  len: 8  clientid: LOG  flags: UNMOUNT
Unmount filesystem

============================================================================
xfs_logprint: skipped 512 cleared blocks in range: 2 - 513
xfs_logprint: skipped 261630 zeroed blocks in range: 514 - 262143
xfs_logprint: physical end of log
============================================================================
xfs_logprint: logical end of log
============================================================================

We have another server, which has exactly the same hardware architecture,
exactly the same system, it's the same server we use dns load balancing
between the two, and there we have no problem at all, but see the log:

[root]~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0               42G   12G   30G  28% /
tmpfs                 7.9G     0  7.9G   0% /lib/init/rw
udev                   10M   72K   10M   1% /dev
tmpfs                 7.9G     0  7.9G   0% /dev/shm
/dev/mapper/a-a        17T   17T   28G 100% /var/www/users/sms

[root]~# df -ih
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md0                5.3M    293K    5.0M    6% /
tmpfs                   2.0M       5    2.0M    1% /lib/init/rw
udev                    2.0M     469    2.0M    1% /dev
tmpfs                   2.0M       1    2.0M    1% /dev/shm
/dev/mapper/a-a         309M    857K    309M    1% /var/www/users/sms

[root]~# xfs_info /var/www/users/sms
meta-data=/dev/a/a               isize=256    agcount=32, agsize=137326144
blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=4394436608, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

[root]~# xfs_logprint /dev/a/a
xfs_logprint:
xfs_logprint: /dev/a/a contains a mounted and writable filesystem
    data device: 0xfd00
    log device: 0xfd00 daddr: 17577746464 length: 262144

Header 0x3 wanted 0xfeedbabe
**********************************************************************
* ERROR: header cycle=3           block=55900                        *
**********************************************************************
Bad log record header

So you tell me, it appeared again just suddenly.
Thank you,

Viktor

-----Original Message-----
From: David Chinner [mailto:dgc@sgi.com] 
Sent: Tuesday, April 01, 2008 2:35 AM
To: Huszár Viktor Dénes
Cc: 'Emmanuel Florac'; xfs@oss.sgi.com
Subject: Re: free space problem

On Mon, Mar 31, 2008 at 07:36:56PM +0200, Huszár Viktor Dénes wrote:
> -----Original Message-----
> From: Emmanuel Florac [mailto:eflorac@intellique.com] 
> Sent: Monday, March 31, 2008 9:40 AM
> To: Huszár Viktor Dénes; xfs@oss.sgi.com
> Subject: Re: free space problem
> 
> Le Mon, 31 Mar 2008 02:31:16 +0200 vous écriviez:
> 
> >Then maybe you simply ran out of inodes. It's common if you have lots
> >of small files. There is a way to increase the number of inodes but I
> >don't remember it right now.
> --
> No, unfortunately not. There are not many small files and the inode usage
is
> 1%. See.

Yes, but if you have fragemented free space then it is possible that there
are not enough free extents large enough (or aligned correctly) to
allocate more inodes. The number of "free inodes" reported doesn't take
this into account; it only looks at the number of free blocks and converts
that to a theoretical number of inodes that could be allocated in that
space (i.e. it assumes perfect fit and no waste). 

In this "not quite full filesystem" situation, you can write data to the
filesystem, but any attempt to create a new inode (new file, directory,
etc) will fail with ENOSPC. This sounds like the symptoms you are
reporting....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2988 (20080331) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: free space problem

[KELEMEN Peter]

* Huszár Viktor Dénes (hvd@dwo.hu) [20080406 18:09]:

> /dev/mapper/a-a        17T   17T   51G 100% /var/www/users/sms

That's 0.292% of your filesystem free.  Not much by any means.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen@cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'

RE: free space problem

[Huszár Viktor Dénes]

Peter, are you Hungarian :) too?
For us this 0.3 % is vital 50-100 GBytes. Do you think that if we would have
a free space arund 400-500 Gb the problem would never appear?

Thanks, Viktor

-----Original Message-----
From: KELEMEN Peter [mailto:Peter.Kelemen@cern.ch] 
Sent: Sunday, April 06, 2008 6:27 PM
To: Huszár Viktor Dénes
Cc: 'David Chinner'; 'Emmanuel Florac'; xfs@oss.sgi.com
Subject: Re: free space problem

* Huszár Viktor Dénes (hvd@dwo.hu) [20080406 18:09]:

> /dev/mapper/a-a        17T   17T   51G 100% /var/www/users/sms

That's 0.292% of your filesystem free.  Not much by any means.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen@cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3005 (20080406) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3005 (20080406) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[David Chinner]

On Sun, Apr 06, 2008 at 06:09:39PM +0200, Huszár Viktor Dénes wrote:
> Hi guys, the earlier problem came out again:
> 
> Here are the logs:
> 
> [root]~# df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/md0               42G   15G   26G  37% /
> tmpfs                 7.9G     0  7.9G   0% /lib/init/rw
> udev                   10M   76K   10M   1% /dev
> tmpfs                 7.9G  2.2M  7.9G   1% /dev/shm
> /dev/md1              420G   31G  389G   8% /var/www/users
> /dev/mapper/a-a        17T   17T   51G 100% /var/www/users/sms

So you effectively have a full filesystem. Inode allocation
may be impossible as the filesystem approaches full as there
is not enough contiguous free space to allocate them in.

Also, you are probably using the inode32 allocator (i.e. no inode64
mount option), which means inodes can only be placed in the first
1TB of the filesystem, and that means those AGs are probably out of
space.

Given that you have 523GB AGs, that means inode will probably only be
put in AG 0, ad that's probably out of space. What does:

# xfs_db -r -c 'freesp -s -a 0' /dev/mapper/a-a

give you?

FWIW, This problem will come and go as you unlink files and change
the pattern of freespace...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

RE: free space problem

[Huszár Viktor Dénes]

Okay guys, we figured out what is the real problem with the xfs, I just need
your help now.

Currently our server has an 880448 number as icount, which we figured out
like this:

xfs_db -r -c sb -c p /dev/a/a | egrep icount\|ifree
icount = 880448
ifree = 0

although df -i sates this:

df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md0                5.3M    301K    5.0M    6% /
tmpfs                   2.0M       5    2.0M    1% /lib/init/rw
udev                    2.0M     475    2.0M    1% /dev
tmpfs                   2.0M       1    2.0M    1% /dev/shm
/dev/mapper/a-a          60M    860K     59M    2% /var/www/users

If we delete a file ifree is going to be 1. if we delete 200 files, ifree
becomes 200 so there is an obvious relationship here. If ifree is 0, we can
not upload anymore.

So the question is: how can we increase the icount without formatting the
partition?

Please help!! Thank you in advance,

Viktor

-----Original Message-----
From: Emmanuel Florac [mailto:eflorac@intellique.com] 
Sent: Monday, March 31, 2008 9:40 AM
To: Huszár Viktor Dénes; xfs@oss.sgi.com
Subject: Re: free space problem

Le Mon, 31 Mar 2008 02:31:16 +0200 vous écriviez:

> There is nothing extraordinary in it, you can see umount-mount and
> that it was mounted after all xfs activity (check, repair, db).

Then maybe you simply ran out of inodes. It's common if you have lots
of small files. There is a way to increase the number of inodes but I
don't remember it right now.

-- 
--------------------------------------------------
Emmanuel Florac               www.intellique.com   
--------------------------------------------------


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2986 (20080331) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3143 (20080529) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[Emmanuel Florac]

Le Thu, 29 May 2008 12:20:49 +0200
Huszár Viktor Dénes <hvd@dwo.hu> écrivait:

> So the question is: how can we increase the icount without formatting
> the partition?

Is it mounted with the inode64 option? 

-- 
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

Re: free space problem

[Emmanuel Florac]

Le Thu, 29 May 2008 12:29:25 +0200
Emmanuel Florac <eflorac@intellique.com> écrivait:

> Is it mounted with the inode64 option? 

You should try it then. You must unmount it and remount it for this to
take effect. Either add "inode64" to the option line in /etc/fstab, or
use mount -t xfs -o inode64 /some/device /some/mountpoint

-- 
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

RE: free space problem

[Huszár Viktor Dénes]

YES! Finally the problem is solved! Thank you Emmanuel and everyone else!
After adding inode64 to the mount option [only umount and mount worked, with
remount it didn't] it works. Although the icount and ifree numbers have not
changed, we can write to the disk. 

Hope this will help anyone who encounters this problem. In the xfs man and
debian docs we could not find anything about this inode64, so thank you once
again for the help!!!! 

Viktor

-----Original Message-----
From: Emmanuel Florac [mailto:eflorac@intellique.com] 
Sent: Thursday, May 29, 2008 12:55 PM
To: xfs@oss.sgi.com
Cc: Huszár Viktor Dénes
Subject: Re: free space problem

Le Thu, 29 May 2008 12:29:25 +0200
Emmanuel Florac <eflorac@intellique.com> écrivait:

> Is it mounted with the inode64 option? 

You should try it then. You must unmount it and remount it for this to
take effect. Either add "inode64" to the option line in /etc/fstab, or
use mount -t xfs -o inode64 /some/device /some/mountpoint

-- 
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3143 (20080529) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3143 (20080529) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[Dave Chinner]

On Thu, May 29, 2008 at 03:26:16PM +0200, Huszár Viktor Dénes wrote:
> YES! Finally the problem is solved! Thank you Emmanuel and everyone else!
> After adding inode64 to the mount option [only umount and mount worked, with
> remount it didn't] it works. Although the icount and ifree numbers have not
> changed, we can write to the disk. 
> 
> Hope this will help anyone who encounters this problem. In the xfs man and
> debian docs we could not find anything about this inode64, so thank you once
> again for the help!!!! 

I can think of two places off the top of my head where it is
documented:

Documentation/filesystems/xfs.txt in your local kernel source tree:

  inode64
        Indicates that XFS is allowed to create inodes at any location
        in the filesystem, including those which will result in inode
        numbers occupying more than 32 bits of significance.  This is
        provided for backwards compatibility, but causes problems for
        backup applications that cannot handle large inode numbers.

$ man 8 mount

  inode64

	Indicates that XFS is allowed to create inodes at any location in the
	filesystem,  including  those which will result in inode numbers occupying more
	than 32 bits of significance.  This is provided for backwards compatibility,
	but causes problems for backup applications that cannot handle large inode
	numbers.


Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

RE: free space problem

[Huszár Viktor Dénes]

Thank you, now I found it as well. I cant believe I missed this! Emmanuel :)
we solved the problem temporarily by increasing the free space to 100 GB,
however, we had no idea it has anything to do with the number of icount or
ifree.

Dave, thanks as well.

Vic

-----Original Message-----
From: Dave Chinner [mailto:david@fromorbit.com] 
Sent: Thursday, May 29, 2008 4:58 PM
To: Huszár Viktor Dénes
Cc: 'Emmanuel Florac'; xfs@oss.sgi.com
Subject: Re: free space problem

On Thu, May 29, 2008 at 03:26:16PM +0200, Huszár Viktor Dénes wrote:
> YES! Finally the problem is solved! Thank you Emmanuel and everyone else!
> After adding inode64 to the mount option [only umount and mount worked,
with
> remount it didn't] it works. Although the icount and ifree numbers have
not
> changed, we can write to the disk. 
> 
> Hope this will help anyone who encounters this problem. In the xfs man and
> debian docs we could not find anything about this inode64, so thank you
once
> again for the help!!!! 

I can think of two places off the top of my head where it is
documented:

Documentation/filesystems/xfs.txt in your local kernel source tree:

  inode64
        Indicates that XFS is allowed to create inodes at any location
        in the filesystem, including those which will result in inode
        numbers occupying more than 32 bits of significance.  This is
        provided for backwards compatibility, but causes problems for
        backup applications that cannot handle large inode numbers.

$ man 8 mount

  inode64

	Indicates that XFS is allowed to create inodes at any location in
the
	filesystem,  including  those which will result in inode numbers
occupying more
	than 32 bits of significance.  This is provided for backwards
compatibility,
	but causes problems for backup applications that cannot handle large
inode
	numbers.


Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3145 (20080529) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3145 (20080529) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: free space problem

[Emmanuel Florac]

Le Thu, 29 May 2008 15:26:16 +0200
Huszár Viktor Dénes <hvd@dwo.hu> écrivait:

> Hope this will help anyone who encounters this problem. In the xfs
> man and debian docs we could not find anything about this inode64, so
> thank you once again for the help!!!! 

I had this same problem 2 weeks ago, that's why I remember clearly what
to do :)

-- 
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------