incorrect inode count on reiserfs

incorrect inode count on reiserfs

[Petr Sebor]

I have noticed this behavior when moving the inn2 news server to 
2.6.0-test11 kernel
from 2.4.23
(inn2 refuses to start because if free inode shortage)

2.6.0-test11:
df -i:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1                  0       0       0    -  /
/dev/sdb1                  0       0       0    -  /mnt/sdb1

while df shows:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            243208608  11069612 232138996   5% /
/dev/sdb1             36150172     32840  36117332   1% /mnt/sdb1

different reiserfs based machine with 2.4.23; this is where the inn2
used to work before, but the inode test was not failing because of the
'always-nonzero' inode count:

df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hde1            4294967295       0 4294967295    0% /
/dev/hdg1            4294967295       0 4294967295    0% /mnt/d2

df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hde1             77634256  77092844    541412 100% /
/dev/hdg1             38586912  19156508  19430404  50% /mnt/d2

another 2.6.0-test11 machine with ext2 reports inode counts correctly. 
my assumption is
that the problem is somehow reiserfs related, but my knowledge ends here.
all reiser fs's are of version 3.6

any ideas?

Petr

Re: incorrect inode count on reiserfs

[Nikita Danilov]

Petr Sebor writes:
 > I have noticed this behavior when moving the inn2 news server to 
 > 2.6.0-test11 kernel
 > from 2.4.23
 > (inn2 refuses to start because if free inode shortage)
 > 
 > 2.6.0-test11:
 > df -i:
 > 
 > Filesystem            Inodes   IUsed   IFree IUse% Mounted on
 > /dev/sda1                  0       0       0    -  /
 > /dev/sdb1                  0       0       0    -  /mnt/sdb1
 > 
 > while df shows:
 > Filesystem           1K-blocks      Used Available Use% Mounted on
 > /dev/sda1            243208608  11069612 232138996   5% /
 > /dev/sdb1             36150172     32840  36117332   1% /mnt/sdb1
 > 
 > different reiserfs based machine with 2.4.23; this is where the inn2
 > used to work before, but the inode test was not failing because of the
 > 'always-nonzero' inode count:
 > 
 > df -i
 > Filesystem            Inodes   IUsed   IFree IUse% Mounted on
 > /dev/hde1            4294967295       0 4294967295    0% /
 > /dev/hdg1            4294967295       0 4294967295    0% /mnt/d2
 > 
 > df
 > Filesystem           1K-blocks      Used Available Use% Mounted on
 > /dev/hde1             77634256  77092844    541412 100% /
 > /dev/hdg1             38586912  19156508  19430404  50% /mnt/d2
 > 
 > another 2.6.0-test11 machine with ext2 reports inode counts correctly. 
 > my assumption is
 > that the problem is somehow reiserfs related, but my knowledge ends here.
 > all reiser fs's are of version 3.6

reiserfs has no fixed predefined number of inodes on the file
system. Hence, field f_files of struct statfs (see man 2 statfs) is not
applicable to this file system. Man page explicitly says:

       Fields that are undefined for a particular file system are
       set  to  0.

Previous man page stated that file system should put -1 (4294967295)
into undefined fields. Reiserfs has been changed to conform to the
changed specification.

SuS simply says:

NAME

    fstatvfs, statvfs - get file system information

SYNOPSIS

    [XSI] #include <sys/statvfs.h>

    int fstatvfs(int fildes, struct statvfs *buf);
    int statvfs(const char *restrict path, struct statvfs *restrict buf);

DESCRIPTION

    [...]

    It is unspecified whether all members of the statvfs structure have
    meaningful values on all file systems.

 > 
 > any ideas?

inn2 should be fixed. :)

Fix would really be simple: ignore test results if ->f_files is 0 or
0xffffffff.

 > 
 > Petr
 > 

Nikita.

Re: incorrect inode count on reiserfs

[Petr Sebor]

Nikita Danilov wrote:

>reiserfs has no fixed predefined number of inodes on the file
>system. Hence, field f_files of struct statfs (see man 2 statfs) is not
>applicable to this file system. Man page explicitly says:
>
>       Fields that are undefined for a particular file system are
>       set  to  0.
>  
>
duh, I thought that f_files is applicable to reiserfs as well...

>Fix would really be simple: ignore test results if ->f_files is 0 or
>0xffffffff.
>  
>
ok, sorry for the noise... as for the inn2, I have disabled the free 
inode check in innwatch.ctl and it works well

thanks!
Petr

Re: incorrect inode count on reiserfs

[Andreas Schwab]

Nikita Danilov <Nikita@Namesys.COM> writes:

> inn2 should be fixed. :)
>
> Fix would really be simple: ignore test results if ->f_files is 0 or
> 0xffffffff.

That should better be (fsfilcnt_t)-1.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: incorrect inode count on reiserfs

[Erik Hensema]

Nikita Danilov (Nikita@Namesys.COM) wrote:
> Petr Sebor writes:
> > I have noticed this behavior when moving the inn2 news server to 
> > 2.6.0-test11 kernel
> > from 2.4.23
> > (inn2 refuses to start because if free inode shortage)

[...]

> reiserfs has no fixed predefined number of inodes on the file
> system. Hence, field f_files of struct statfs (see man 2 statfs) is not
> applicable to this file system. Man page explicitly says:
> 
>        Fields that are undefined for a particular file system are
>        set  to  0.
> 
> Previous man page stated that file system should put -1 (4294967295)
> into undefined fields. Reiserfs has been changed to conform to the
> changed specification.

[...]

> Fix would really be simple: ignore test results if ->f_files is 0 or
> 0xffffffff.

But innwatch checks for a out-of-inodes condition. How can it differentiate
between a undefined number of inodes (field set to 0) and a system that ran
out of inodes (field dropped to 0)?

A '4294967295 inodes should be enough for anyone'-situation is preferable I
think.

-- 
Erik Hensema <erik@hensema.net>

Re: incorrect inode count on reiserfs

[Nikita Danilov]

Erik Hensema writes:
 > Nikita Danilov (Nikita@Namesys.COM) wrote:
 > > Petr Sebor writes:
 > > > I have noticed this behavior when moving the inn2 news server to 
 > > > 2.6.0-test11 kernel
 > > > from 2.4.23
 > > > (inn2 refuses to start because if free inode shortage)
 > 
 > [...]
 > 
 > > reiserfs has no fixed predefined number of inodes on the file
 > > system. Hence, field f_files of struct statfs (see man 2 statfs) is not
 > > applicable to this file system. Man page explicitly says:
 > > 
 > >        Fields that are undefined for a particular file system are
 > >        set  to  0.
 > > 
 > > Previous man page stated that file system should put -1 (4294967295)
 > > into undefined fields. Reiserfs has been changed to conform to the
 > > changed specification.
 > 
 > [...]
 > 
 > > Fix would really be simple: ignore test results if ->f_files is 0 or
 > > 0xffffffff.
 > 
 > But innwatch checks for a out-of-inodes condition. How can it differentiate
 > between a undefined number of inodes (field set to 0) and a system that ran
 > out of inodes (field dropped to 0)?
 > 
 > A '4294967295 inodes should be enough for anyone'-situation is preferable I
 > think.

This is messy, because we have both statfs and statfs64 and this would
lead to the overflow detection problems.

I don't know what is the best solution here. statfs(2) is just not very
good interface. It was obviously designed to serve ffs/ufs/ext2 type
file systems only.

Looking at the magic in f_type field, is ugly, but should work.

 > 
 > -- 
 > Erik Hensema <erik@hensema.net>

Nikita.

Re: incorrect inode count on reiserfs

[Matthias Urlichs]

Hi, Erik Hensema wrote:

> But innwatch checks for a out-of-inodes condition. How can it differentiate
> between a undefined number of inodes (field set to 0) and a system that ran
> out of inodes (field dropped to 0)?
> 
Create a file. Watch that succeed. Check whether this succeeds, and that
the number of free inodes is still zero.
Delete the file. Check that the number of free inodes is _still_ zero.

Repeat a few times, with random sub-second delay if you're feeling
especially paranoid today, for added confidence.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
"The Establishment Clause, unlike the Free Exercise Clause, does not
 depend upon any showing of direct governmental compulsion and is violated
 by the enactment of laws which establish an official religion whether
 those laws operate directly to coerce nonobserving individuals or not."
          [U.S. Supreme Court, Wallace v. Jaffree (1985)]

Re: incorrect inode count on reiserfs

[Erik Hensema]

Matthias Urlichs (smurf@smurf.noris.de) wrote:
> Hi, Erik Hensema wrote:
> 
>> But innwatch checks for a out-of-inodes condition. How can it differentiate
>> between a undefined number of inodes (field set to 0) and a system that ran
>> out of inodes (field dropped to 0)?
>> 
> Create a file. Watch that succeed. Check whether this succeeds, and that
> the number of free inodes is still zero.
> Delete the file. Check that the number of free inodes is _still_ zero.
> 
> Repeat a few times, with random sub-second delay if you're feeling
> especially paranoid today, for added confidence.

So what hack is uglier? ;-)

-- 
Erik Hensema <erik@hensema.net>

Re: incorrect inode count on reiserfs

[Herbert Poetzl]

On Mon, Dec 08, 2003 at 05:24:02PM +0000, Erik Hensema wrote:
> Matthias Urlichs (smurf@smurf.noris.de) wrote:
> > Hi, Erik Hensema wrote:
> > 
> >> But innwatch checks for a out-of-inodes condition. How can it differentiate
> >> between a undefined number of inodes (field set to 0) and a system that ran
> >> out of inodes (field dropped to 0)?
> >> 
> > Create a file. Watch that succeed. Check whether this succeeds, and that
> > the number of free inodes is still zero.
> > Delete the file. Check that the number of free inodes is _still_ zero.
> > 
> > Repeat a few times, with random sub-second delay if you're feeling
> > especially paranoid today, for added confidence.
> 
> So what hack is uglier? ;-)

hmm, well, maybe the fact that an 'inode' filesystem
which ran out of inodes will not report a total of 
0 inodes could help against all this uglyness ...

best,
Herbert

> -- 
> Erik Hensema <erik@hensema.net>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/