Messages in this thread | | | Date | Fri, 28 May 1999 11:01:04 +0200 | From | Jan Kara <> | Subject | Re: Quota file format proposal |
| |
> >>> Isn't it possible to code the uid/gid in the struct too, this > >>> way we dont have to write a 1GB(?) file for 2 users, one at > >>> UID0 and one at UID 131072... Since this struct is read into > >>> memory structs, some small handeling shouldn't really matter > >>> in performance... > > >> We won't write 1GB of data. We take advantage of sparse files so > >> there is almost no difference between storage of UIDS 1000, 1010 > >> and 1000, 10000... > > > Wouldn't it be a good idea at this point to switch to a more > > flexible format for the quota file? You are correct with the > > above remarks as long as userids stay 2 bytes long. For 4 byte > > userids we are above the limit for the current maximum file size > > of ext2 with respect to the quota file. > > SInce there are already systems for which the current 15-bit limit on > uid's is too small, any new quota file format will need to allow for > 31-bit uid's at least, as the kernel will need to change to using > larger uid's soon anyway. This might be arguable but better 31-bits than 26 :-).
> > What about using a hash table instead? > > The problem with a hash table is that it's very much dependant on the > size of the table as to where a particular record gets placed in the > file, and also works best with a fairly large proportion of unused > entries. Yes. But usage ~50% isn't so bad... I'll write hash table and benchmark it at least :-).
> I'd prefer to see a sorted file used for quotas, with the uid or gid > stored as part of the record structure in the file. If the records are > maintained in sorted order by uid or gid, then a binary search on the > file will quickly find any record therein, or confirm that a record > isn't present. <snip> > OK, it'll be slower than reserving an entry for every possible uid or > gid and thus being able to go straight to the relevant record, but on > the other hand, it can take up considerably less disc space since only > the records for uid's or gid's with access to that partition need be > stored in its quota file. It's not even much of a slowdown either. It won't be much slower that current implementation as it climbs tree. But this is hidden in ext2 implementation :-). I see the main problem in inserts and deletes. I agree they are not very often but spending 2 seconds on one insert seems too much to me :-). I'm searching the net for some interresting structures :-).
Honza.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |