public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Amit Gud" <gud@eth.net>
To: "Pavel Machek" <pavel@ucw.cz>, "alan" <alan@clueserver.org>
Cc: "Fao, Sean" <Sean.Fao@dynextechnologies.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: Elastic Quota File System (EQFS)
Date: Fri, 25 Jun 2004 19:32:44 +0530	[thread overview]
Message-ID: <004e01c45abd$35f8c0b0$b18309ca@home> (raw)

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


             reply	other threads:[~2004-06-25 14:03 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-25 14:02 Amit Gud [this message]
2004-06-25 14:23 ` Elastic Quota File System (EQFS) Fao, Sean
2004-06-25 14:44 ` Horst von Brand
2004-06-25 16:25   ` Pavel Machek
2004-06-25 16:44     ` Alan
2004-06-25 17:35       ` Amit Gud
2004-06-25 20:22         ` Fao, Sean
2004-06-25 23:50           ` Kevin Fox
2004-06-26  4:03           ` Amit Gud
2004-06-26 21:36             ` Fao, Sean
2004-06-26 23:16               ` Stephen Wille Padnos
2004-06-27  1:44                 ` Fao, Sean
2004-06-28 13:43                 ` Rob Couto
2004-06-25 21:36         ` Pavel Machek
2004-06-25 17:07     ` Horst von Brand
2004-06-25 18:44       ` Amit Gud
2004-06-25 21:44       ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2004-06-23 15:53 Amit Gud
2004-06-23 17:53 ` Mark Watts
     [not found]   ` <1088016048.15211.10.camel@sage.kitchen>
2004-06-24  9:28     ` Amit Gud
2004-06-24 11:50       ` Olaf Dabrunz
2004-06-24 14:04         ` Sam Elstob
2004-06-24 13:51           ` Olaf Dabrunz
2004-06-24 14:17         ` Pavel Machek
2004-06-24 19:58           ` Fao, Sean
2004-06-24 20:28             ` Timothy Miller
2004-06-24 20:30             ` Timothy Miller
2004-06-24 21:30             ` Pavel Machek
2004-06-24 20:51               ` alan
2004-06-24 22:03                 ` Pavel Machek
2004-06-24 23:07                   ` alan
2004-06-25  0:15                     ` Pavel Machek
2004-06-25 11:57                       ` Fao, Sean
2004-06-25 12:07                       ` Josh Boyer
2004-06-25 19:34                         ` Jörn Engel
2004-06-25 17:37                       ` Timothy Miller
2004-06-25 18:44                         ` Amit Gud
2004-06-26 12:00                           ` Helge Hafting
2004-06-25 19:09                         ` Amit Gud
2004-06-30 13:02                         ` Olaf Dabrunz
2004-06-25  7:52                   ` Lionel Bouton
2004-06-27 18:18                     ` V13
2004-06-27 19:42                       ` Lionel Bouton
2004-06-28 15:34                         ` Amit Gud
2004-06-25  3:04       ` Bernd Eckenfels
2004-06-23 20:37 ` Rik van Riel
2004-06-23 15:48 gud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004e01c45abd$35f8c0b0$b18309ca@home' \
    --to=gud@eth.net \
    --cc=Sean.Fao@dynextechnologies.com \
    --cc=alan@clueserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox