On Tue, 2004-02-24 at 14:53, Mark Bergsma wrote:
> 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:
Did this used to work with 2.4? Smells like reiser (which has often had
this sort of problem - which they don't really care about) has had a bug
fix applied to 2.4 and not forward ported.
> 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.
Well surely the admin should check the filesystem is capable before
enabling it :-) Especially since exim cannot easily.
However maybe there should be a get-out for
f_files==0 && f_ffree==0
as there is obviously something screwy.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
