[lkml]   [1996]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposal: restrict link(2)
Date wrote:
>>> > I agree with Mr. VanDevender on this point. I personally have never
>>> >used Quota on Linux so maybe this idea is off, but how about adding the
>>> >smarts to the quota distribution? If this affects us, then it probably
>> [clip]
>>> How about this:
>>> Quota's can calculate usage by dividing the disk file by the
>>> user count. A 500 MB file can be shared by 5 people who each
>>> "pay" 100 MB.
>>Well, my initial reaction was "No way!", because this means that
>>you affect somebody else (the file owner) when you do something
>>(hard link their file with a name in your space), but in fact all you can do
>>is help them (by lowering their quota) so - maybe!
> The problem with this is that the Linux filing systems only support having
>one user as the owner of the file. All hard links to the file are just
>pointers to the Inode which contains the UID/GID of the file. This means that
>to support this feature you advocate would require changing all filing systems!
>>But this is still unsatisfactory aesthetically. From the point of view of
>>beauty and simplicity it seems to me that the owner of the original is the one
>>and only with it on his quota. To continue ...
> That is the way it must be with current filing systems because they have no
>way of storing any other data.
>Russell Coker

I thought about this (as much as I could without knowing quota
better) when I wrote it.

Why would you need more information in the inode? If quota
scans by inode and reads information from each inode, then you
need some kind of info in the inode.

But, if quota scans through the directories, then there is no
problem. Each link and what inode it points to is kept in a
database (actually files can be removed from the data base and
put in the summary as soon as all their links are counted,
because then the quota system can divide up the "points" and no
longer needs to track the file. For singly linked files, this
is almost every file.

(Which method is used?)

Actually, the change to the filesystem would NOT be all that
radical. Each inode would have a pointer to the first
link. Each directory entry would have a pointer to the next
directory entry on the list (if any). Thus the size of an inode
is increased by one pointer, and the size of a directory entry

--> This could speed up various parts of the filesystem layer,
and could provide better redundancy info for fsck. The standard
question "What file is this inode?" could be answered quickly
and easily.
Develop free apps?
Pascal, n.: A programming language named after a man who would
turn over in his grave if he knew about it.

 \ /
  Last update: 2005-03-22 13:38    [W:0.080 / U:8.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site