-----Original Message-----
From: James McTavish
Sent: Monday, December 08, 2003 10:04 AM
[ Snip ]
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hde2 490023 23988 440733 6% /
/dev/vg1/home 85980604 33240 85947364 1% /home
/dev/vg1/var 5242716 57268 5185448 2% /var
/dev/vg1/opt 1048540 32840 1015700 4% /opt
/dev/vg1/usr 10485436 1056264 9429172 11% /usr
/dev/vg1/tmp 524268 32840 491428 7% /tmp
none 127888 0 127888 0% /dev/shm
Which is plenty of space on /var and /tmp. However I did find an
mailing-list post from another person with the same problem and it
turned out he was fine for space, but out of inodes (but from what I
know reiserfs doesn't use inodes). But I checked the inodes anyway:
(A) Reiserfs *does* use inodes it just doesn't pre-allocate them; any disk
block can be an inode. In fact, Reiserfs' small file performance comes from
eliminating the *data* blocks (for small files), not the inodes!
(B) Per your "df", you have 0 inodes free. Courier checked, decided zero
was not enough, and refused the connection.
(C) Reiserfs' policy of reporting the fsinfo is (IMHO) flawed: under the
Unix semantics that we've been using for the past 30 odd years, it should
report *either* -1 *or* an approximation based on the number of available
*blocks* times the maximum number of inodes Reiser can stuff in one block.
I've seen indications that Hans Reiser thinks that -1 is correct, but some
docs based on BSD4.4 unwisely seem to state that zero should be returned for
undefined entries (which is unwise since 0 is a valid number of available
inodes, so unnecessary ambiguity results).
I mention this just to note that this *isn't* a Courier issue, it's a
Reiserfs one that can be accomodated by changes to Courier.
Malc.
9 messages in net.sourceforge.lists.courier-usersRE: [courier-users] 431 Mail system full
