[lustre-devel] Recommendation for hsm_restore for directories
degremoa at amazon.fr
Wed Dec 15 07:33:02 PST 2021
I've been already looking at this ticket and I'm not thinking at the exact same feature (even if not incompatible).
I think you're thinking at efficient way to backup/restore a Lustre filesystem. I'm more thinking at ways to plug a Lustre FS in front of an existing HSM backend. If the backend already exists, you need to accept its current data structure (usually file/dir/object based) and not a tarball or disk image.
But all of this is HSM_ARCHIVE oriented and I'm more thinking of HSM_RESTORE feature for directories. And restoring means detecting and blocking client accesses while the directory is restored (or mounted).
At the end, if the copytool is pushing that as a image and restoring a image it is up to copytool in my opinion.
The question for me is more what should be the way for Lustre to manage Directories if they start to be releasable. What does that mean in term of LDLM locking, internal states, etc… Do you have an idea for that? My research looking at current code did not give a clear path for that. Implementing something similar to what is done for file is not that easy either.
De : lustre-devel <lustre-devel-bounces at lists.lustre.org> au nom de Andreas Dilger via lustre-devel <lustre-devel at lists.lustre.org>
Répondre à : Andreas Dilger <adilger at whamcloud.com>
Date : mercredi 8 décembre 2021 à 22:10
À : "Degremont, Aurelien" <degremoa at amazon.fr>
Cc : "lustre-devel at lists.lustre.org" <lustre-devel at lists.lustre.org>
Objet : RE: [EXTERNAL] [lustre-devel] Recommendation for hsm_restore for directories
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Nov 24, 2021, at 10:33, Degremont, Aurelien via lustre-devel <lustre-devel at lists.lustre.org<mailto:lustre-devel at lists.lustre.org>> wrote:
I'm doing some early work toward implementing a directory/namespace support for Lustre/HSM. The idea would be to support something similar to hsm_restore/hsm_release but for directories.
My first thought was for the MDT to not grant LDLM lock for this directory and hold it, while the directory is getting restored by copytool, in a similar fashion than what is done for files. But the hard part here, is to have a way for copytool to access the directory while its access is actually prevented by the above locking.
Restoring a file is using this smart trick of restoring it in a different temporary file and using layout swap at the end to move data to the actual real file. It looks difficult to do the same thing here.
Do you have any recommendation on the right way to frame this directory access for copytools?
I've thought about this in the past, and IMHO the best way to handle a directory or directory tree would be to save the directory and/or whole tree in an ldiskfs image rather than a tarball. The reasoning for this is that in the future it would allows directly mounting the image for access by the MDT and/or client (Client Container Image), unlike a tarball that needs to be extracted each time before use.
There is some discussion about this in https://jira.whamcloud.com/browse/LU-13024
Lustre Principal Architect
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lustre-devel