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.
> 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.. > > > > Regards, > > Bill Hacker -- Matt Pavlovich <[EMAIL PROTECTED]> Allegiance Telecom, Inc. ------------------------------------------------------- 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
