Messages in this thread | | | From | Nikita Danilov <> | Date | Mon, 8 Dec 2003 18:33:54 +0300 | Subject | Re: incorrect inode count on reiserfs |
| |
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. - 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/
| |