Linux-kernel mailing list archive 1999-22,: Re: Quota file format proposal

# Re: Quota file format proposal

Jan Kara (jack@atrey.karlin.mff.cuni.cz)
Fri, 28 May 1999 11:01:04 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Pavel Machek: "Re: TTY_FLIPBUF_SIZE too low causing dataloss on too fast serial lines?"
- Previous message: Trond Myklebust: "Re: Possible NFS client 2.2.9 kernel bug"

> >>> 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/

- Next message: Pavel Machek: "Re: TTY_FLIPBUF_SIZE too low causing dataloss on too fast serial lines?"
- Previous message: Trond Myklebust: "Re: Possible NFS client 2.2.9 kernel bug"