[Exim] check_spool_inodes / reiserfs / Linux 2.6 bug

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Mark Bergsma
Date:  
À: ph10
CC: mrten+exim, exim-users
Sujet: [Exim] check_spool_inodes / reiserfs / Linux 2.6 bug
During the past few days, we have upgraded several exim mailservers to
the new Linux 2.6 kernel. Afterwards, we noticed these servers stopped
accepting mail, stating in the logs that there were no free inodes left
in the spool directory.

Some investigation showed that, due to check_spool_inodes being set in
the configuration file, Exim does a statfs() on the spool directory and
finds that there are no inodes left. The mail servers showing this
behaviour are all using reiserfs. It appears that reiserfs in linux 2.6
always returns value 0 for the f_ffree, which makes Exim think that
there are no free inodes:

statfs("/var/spool/exim", {f_type="REISERFS_SUPER_MAGIC", f_bsize=4096,
f_blocks=1279959, f_bfree=1039640, f_files=0, f_ffree=0, f_namelen=255}) = 0
write(2, "exim: insufficient disc space\n", 30exim: insufficient disc space

However, according to the manpage for statfs(), value 0 means 'undefined':

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

Probably reiserfs doesn't have the concept of free inodes, hence returns
0. Other filesystems like ext2/3 return nonzero values.

I think this is a flaw in the design of the statfs() call, as there is
no way for it to state that there are no inodes left for filesystems
that do have this concept. However, I think this is a bug in Exim,
because it should regard 0 as a special value.

I do not know and I have not checked how statfs() behaves in this regard
on other unix systems, but I hope this is not yet another incompatibility...

--
Mark

mark@???