In <[EMAIL PROTECTED]>, on 03/19/03 at 01:43 PM, Matt Pavlovich <[EMAIL PROTECTED]> said:
>Block size is not a good measure, since users on the same system can be >on different slices with different block sizes. This would cause mass >confusion from a provisioning standpoint. ACK. The environment *is* variable. But the information about it is retrievable for each mount, hence can be converted and used in a uniform manner. As is done by several system utilities already anyway.... Bill Hacker >> On the face of it, 2GB seems like an unrealistically large quota for a >> Maildir *anyway*, and Sam is right w/r the fact that the compiler, its >> libs and such are limited in the largest binary number they can directly >> express for the particular function called..... at present.... >> >> BUT... >> >> The file system(s) have faced and handled this problem by a type of >> 'scaling' already - to wit, by adjusting block sizes to fit the media they >> are installed on. >> >> And AFAIK, IF there is to be a change...to maintain portability one can >> (must) get this information (512, 4096, 8192 blocksize etc.) from the >> system on any given platform... both as to the block size mapped and that >> available/used. 'df' and 'du do so now, and accept scaling parms (K or M) >> for human-readability convenience already. >> >> So...shifting to function calls which read the capacity and quotas in >> these 'block' units, vs directly in bytes should be possible... >> >> And not a half-bad idea for future as disks get larger and larger... (and >> users, bless their pointed little-heads, store more and more bloated, >> attachment-laden messages they will never have time to re-read)! >> >> Just my HK$ .02 worth... >> >> Bill Hacker >> >> >> In <[EMAIL PROTECTED]>, on 03/19/03 >> at 10:21 AM, Matt Pavlovich <[EMAIL PROTECTED]> said: >> >> >> Fred Ho writes: >> >> >> >> > In an effort to increase the quota to 3GB, the size is being reset to less >> >> > than 2 GB. Even hand changing the maildirsize file to the desired size, it >> >> > will be reset by Courier later on to < 2GB value. >> >> > >> >> > After some investigation, it may be due to the integer size limit. This >> >> > quota thing affects the maildirmake -q, and userdb. >> >> > >> >> > Is there any chances of Courier to support a larger quota size? >> >> >> >> Not on 32-bit machines. >> >> >If quota numbers were represented as number of kilobytes, this would >> >work. What about adding support for representing quotas like: >> >> >12M >> >300K >> >> >etc.. This will circumvent any integer limit problems.. just detect none >> >digit numbers in the users' quota field and parse for M, K, etc.. >> >> >Calculating overquota, etc would not be difficult either.. >> >> >> ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
