From: DEGREMONT Aurelien <aurelien.degremont@cea.fr>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] HSM comments
Date: Mon, 03 Nov 2008 16:30:02 +0100 [thread overview]
Message-ID: <490F18FA.5040509@cea.fr> (raw)
In-Reply-To: <490B6B6B.1070401@sun.com>
Nathaniel Rutman a ?crit :
> 5.4 unlink
>
> 1. A client issues an unlink for a file to the MDT.
> 2. The MDT includes the "hsm_exists" bit in the changelog unlink entry
> 3. The policy engine determines if the file should be removed from HSM
> 4. Policy engine sends HSMunlink FID to coordinator via MDT ioctl
> 1. Yuck - we can't do direct ioctls on the MDT from a client
> node. We can only do ioctls on a file.
>
> maybe we need to implement a .lustre/device/XXX dir,
> where all MDT/OSTs are listed, and act as stub files for
> handling ioctls. or maybe policy engine
> talks to agent / tool directly
> for unlinks?
Can't we add an ioctl on /dev/obd or /mnt/lustre root dir ? or even on
.lustre/fid and passing the fid in ioctl args?
I'm not fond of .lustre/device/XXX dirs...
> 5. The coordinator sends a request to one of its agent for the
> corresponding removal.
> 6. The agent spawns the HSM tool to do this removal.
> 7. When HSM removal is complete, policy engine cancels changelog
> unlink record
> 1. How does agent/HSM tool signal to policy engine that HSM
> removal is complete?
> 8. In case of agent crash, unlink record will remain uncancelled in
> the changelog; policy engine should restart processing at the
> first uncancelled record.
>
>
> There's two open issues:
> - How for policy engine to tell coordinator to unlink an HSM object,
> when no corresponding object exists on the MDT for us to ioctl() on
> -which coordinator to talk to for CMD?
If we implement an ioctl like
ioctl(.lustre/fid, HSMUnlink, fid=0x0000121561), can the API find the
good MDT from the FID ? FLD can do this for an already removed file?)
> - How does HSMunlinkHelper return a signal to the policy engine that
> the removal is complete
> -if policy engine directly calls HSMunlinkHelper this is easy...
I think there is a more general issue concerning feedback for the
PolicyEngine. Surely the PolicyEngine will need information for other
request it sent to the Coordinator. We should think of a more general
mechanism to inform it of the success or failure of its requests.
Should the HSM (succesfull) event become changelog
events....(hsm_copyin/hsm_copyout/hsm_remove)? Can another program be
interested in such events?
Aur?lien
next prev parent reply other threads:[~2008-11-03 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4905F121.6000501@cea.fr>
2008-10-27 23:02 ` [Lustre-devel] HSM comments Nathaniel Rutman
2008-10-28 15:42 ` DEGREMONT Aurelien
2008-10-31 20:32 ` Nathaniel Rutman
2008-11-03 15:30 ` DEGREMONT Aurelien [this message]
2008-10-27 23:12 ` Andreas Dilger
[not found] ` <4907249E.60904@cea.fr>
2008-10-28 18:26 ` Andreas Dilger
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=490F18FA.5040509@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.