All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurelien Degremont <aurelien.degremont@cea.fr>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Quota and Lustre HSM
Date: Thu, 03 Jul 2008 18:03:20 +0200	[thread overview]
Message-ID: <486CF848.7090904@cea.fr> (raw)

Hello,

We got discussion with Andreas and Nathan concerning the best way to 
support quota with Lustre HSM.
I'd like to discuss and clarify what should be the correct behavior in 
this case.


1 - Current status

Here how the Lustre filesystem will behave with current quota system 
enabled and an active HSM binding.

1.1 Read on a purged file

  * User A reads a purged file with enough free quota

   o The file is copied back from the HSM.
   o User quota increases without new data created by user.

  * User A reads a purged file with no enough quota.

   o The file cannot be copied back from the HSM.
   o I/O failed (Same issue that when the FS is full with HSM support 
enabled).

1.2 Automatic space management

  * One of User A files is purged by the Space Manager, without actions 
from user A.

   o User quota decreases without reason from user point of view.

2 - Questions

Is that the expected behavior?
If not what should be changed?
What should be the correct behavior?
How this could be implemented?

3 - Possible solutions

* Not enough quota

When not enough quota is available for filling back a purged file when 
the user try to read it, a solution could be to trigger purges on the 
other user files.

But it could impossible to find purge candidates.

* Improve quota management

Another approach could be to not removed purged blocks from user quota. 
A purged file is still considering using as much space as its current 
size. This solves all the issues presented before.

HSM feature will track the purged window for each file anyway, so we can 
compute the purged window size. When the user quota is classically 
compute on a filesystem, we will just need to add it to the window size. 
(Could be a problem if the file was sparse).


-- 
Aurelien Degremont
CEA

                 reply	other threads:[~2008-07-03 16:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=486CF848.7090904@cea.fr \
    --to=aurelien.degremont@cea.fr \
    --cc=lustre-devel@lists.lustre.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.