(C) Reiserfs' policy of reporting the fsinfo is (IMHO) flawed:
It's just doing what the spec says it should.
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.
The latter, maybe, but there's nothing special about -1 that would make applications magically work. If an application bothers to check for a specific minimum number of inodes, -1 is still not going to be enough inodes. The spec doesn't say anything about the magic value -1, so applications won't expect it.
I've seen indications that Hans Reiser thinks that -1 is correct
Probably the "correct" thing (as I did in the last patch I sent) would be to check the total number of inodes on the fs. If there are 0 total inodes, then skip the check for the free inodes. The FS doesn't have a staticly allocate set of inodes.
, 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).
"unwise" though it may be, it's the spec which defines the "Unix semantics that we've been using for the past 30 odd years". ;)
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
