In <200003271501.JAA109752@tomcat.admin.navo.hpc.mil> Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil) wrote:
>> Offsets in a file are just "names". That's why you can write one block
>> at 1GB offset, without allocating 1GB of disk space. Is this overcommiting
>> of FS space? Just because the system lets you create a file which is
>> 1GB in *size* (but not in disk usage), it doesn't mean you have 1GB of
>> free disk space. And just because the system lets you malloc(1GB) of
>> address space, and even lets you successfully write at 1GB-1 offset,
>> it doesn't mean there's 1GB of free RAM or swap. Why are you treating
>> memory differently from disk space?
> It isn't being treated differently. A sparce file is still limited by
> the users disk quota (which measures what is actually used...) When the
> user exceeds quota the user is aborted. Just because one user reached quota
> limit, is no reason to abort all users of the disk, or even to abort a
> random user....
WRONG! There are NO quota for memory (sadly, but true) so THE ONLY correct
comparision is to filesystem WITHOUT QUOTAS. And then if you'll fill all disk
ALL users will suffer, not just offending one. Do we need quotas for memory ?
Perhaps. So far I've not seen such patches, unfortunatelly. It does not have
anything to do with overcommiting though.
> If there are no quotas on disk then the last process that attempts a write
> will get aborted - the random process... This is the same as for memory without
> quotas.
And this is THE ONLY comparable case.
> Disk quotas serve the same purpose that memory quotas do. They provide
> for equitibly sharing access while providing security to the space assigned
> can be used by the user/process that it was assigned to.
There is small difference: there are disk quotas, but there are NO memory
quotas :-( Per-user ones, not per-process ones I mean...
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:20 EST