> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Gordon > Messmer > Sent: Monday, December 08, 2003 2:04 PM > To: [EMAIL PROTECTED] > Subject: Re: [courier-users] 431 Mail system full > > > Malcolm Weir wrote: > > > > (C) Reiserfs' policy of reporting the fsinfo is (IMHO) flawed: > > It's just doing what the spec says it should.
Maybe. > > 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. As a matter of fact, returning -1 *will* make *some* applications magically work, it *won't* break anything else, and it disambiguates the situation where you need inodes and you have zero, and you don't need them. You're forgetting the fact that casting -1 to an unsigned returns A Large Number... > > 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. That's just a kludge to get around a deficiency in the interface. And I'd note that the docs you refer to simply state that *undefined* values should return zero. It is entirely reasonable to argue that the number of available inodes on a Reiserfs is not "undefined", just unpredictable. However, it is possible to bound the range of possible available inodes as being at least more than the number of free blocks and less than the number of free blocks times the maximum number of inodes you can fit in a block. (You can certainly run out of inodes on Reiserfs systems... it just happens after you run out of data blocks). And if I were being even more pedantic, I'd note that the statfs/statvfs calls in question don't talk about inodes, just the number of files... I think, on balance, that Reiserfs would have been better advised to return (bfree+1) in all cases. That would break nothing, require no special handling, and fully conform to the wording of the docs. > > , 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". ;) No, it isn't. Loadable filesystems were a BSD innovation, and a fairly recent one (relatively speaking). Mid to late 1980s, or so, IIRC. Yet back to the very first "convenient timesharing system" in 1970 system calls returned -1 as an indicator of an invalid numeric value, and NULL as an indicator of an invalid pointer. Whoever wrote the docs for the Berkeley loadable filesystems missed that. Malc. ------------------------------------------------------- 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
