Re: Elastic Quota File System (EQFS)

[Amit Gud]

Hi all,

>> > On one school server, theres 10MB quota. (Okay, its admins are
>> > BOFHs^H^H^H^H^HSISAL). Everyone tries to run mozilla there (because
>> > its installed as default!), and immediately fills his/her quota with
>> > cache files, leading to failed login next time (gnome just will not
>> > start if it can't write to ~).
>> >
>> > Imagine mozilla automatically marking cache files "elastic".
>> >
>> > That would solve the problem -- mozilla caches would go away when disk
>> > space was demanded, still mozilla's on-disk caching would be effective
>> > when there is enough disk space.

Also this is applicable to mailboxes - automize the marking of old mails of
the mailing list as elastic, whenever the threshold is reached, you might
either want to put those mails as compressed archive or simply delete it.
This has two advantages:
 - No email bounces for the reason of 'mailbox full' and
 - Optimized utlization of the mailbox

Yes, this can be done using scripts too, but what if you are to use other
users' space that they are not using? Of course script cannot do that! You
need to have some FS support or a libquota hack.


>>
>> How does Mozilla (or any process) react when its files are deleted from
>> under it?  Would the file remain until all the open processes close the
>> file or would it just "disappear"?
>
>Of course, if mozilla marked them "elastic" it should better be
>prepared for they disappearance. I'd disappear them with simple
>unlink(), so they'd physically survive as long as someone held them
>open.
>
>>  Would it delete entire directories or
>> just some of the files?  How does it choose?  (First up against the
delete
>> when the drive space fills...)
>
>Probably just some of the files... Or you could delete directory, too,
>if it was marked "elastic". What to delete first... probably file with
>oldest access time? Or random file, with chance of being selected
>proportional to file size?

One can either even mark the whole directory as elastic. When it comes to
taking action, I think I'II opt for random deletion of the files for not
being unfair to any particular user.

AG

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/