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. > 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. Bernhard
