Zitat von Bernhard Schmidt <be...@birkenwald.de>:
Hi,It's not the number of inodes as it is common on ext2/ext3 but the percentage of space occupied by inodes which is dependant on the inode size, the number and the size of the volume. Check with xfs_info, on the filesystems we are using xfs on the percentage is 25% but it may be different on your side.Checked that, increased to 50%, no change. Someone on the XFS mailinglist believed it could be filesystem fragmentation after all. They need an aligned continous 16k block to allocate a new inode chunk, otherwise it will fail. I'm going to test that later.
This could be checked with "xfs_db -c frag -r /device"The second inode problem known with XFS is, that all inodes must be below 1TB if you are not using inode64 mount option. But this should not apply in your case :-)
Either way if you can not create any files in the spool area nothing Postfix can do about.True, I said that from the beginning. However I think this problem might be more common in the standard postfix installation than one might think. Dedicated small spool filesystems are common, XFS is a common filesystem, content-filtering with two instances/daemons is common. Those content-filtering setups always need at least one additional temporary file on the queue (incoming queue of the post-filter instance), otherwise they will deadlock. I'm not sure a reboot would help either, since a reboot does not usually clear files in the spool. Basically the only problem with postfix here is that I cannot have queue_minfree > 2GB to be on the safe side, so I don't know how to avoid this problem.
This problem can be avoided if the filesystem does not "lie" about it's capabilities to store files. But you are right that it might be needed some time in the future to check for more than 2GB free space if mails get bigger and bigger.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
