[Lustre-devel] Lustre HSM - some talking points.

[Nathaniel Rutman <Nathan.Rutman@sun.com>]

Colin Ngam wrote:
> If these are all agreeable, lets start drawing up the Spec.
>
sure

>> Basic Object SAMQFS - HSM for Lustre status Events(check state)
>>
>> 1.  Lustre perform "sls" command on Object SAMQFS Client.
>>
>> PS - We can have both User level command and API capabilities.
>>
>>   well technically, Lustre calls with the following information
>>   1.  Luster FID
>>   2.  Luster Opaque Meta Data
>>   (BTW, that's Lustre, not Luster)
>>   OSAM ignores fid and just uses OSAM identifier
>
> Right, Fiber/Fibre :-)
>
> I am missing something here .. Stage-In is to get a file from archive 
> .. why do we need Item 2?  Or is 2 OSAM Identifier?  If so, great.  I 
> like it.
Yes, item 2 is archive-specific (e.g. OSAM) identifier.
>
> In this case, we should trust Lustre FID.  The OSAM ID is for a very 
> fast search - direct index.
Agreed, the Lustre FID will be the authoritative value.  OSAM would 
internally use the OSAM identifier for the fast lookup, then verify the 
Lustre FID matches.  If not, we would have to do a slow search for the 
Lustre FID...
>> Syncing Object SAMQFS with Lustre
>> ---------------------------------
>>
>> Lustre File Identifier and Object SAMQFS Identifier can get out of 
>> sync - shit
>> happens.  We need syncing capabilities.
>>
>>   Only if we stored enough information to mismatch :)  If Lustre asks
>>   for a FID, and it gets back the wrong file, it doesn't / can't
>>   know.  Unless we store the FID inside the file it gets back and we
>>   verify it.
> If you always call with Lustre ID and OSAM ID, if we find that the 
> Lustre ID does not match the OSAM ID, because perhaps we have done 
> OSAM recovery and we are using a different OSAM ID to hold the Lustre 
> ID now, we can search for the inode that match the Lustre ID, fetch 
> the file and also update Lustre with the new OSAM ID.
Perfect.  We will also need a way of modifying the Lustre FID stored in 
the archive for the ultimate disaster recovery, which is equivalent to 
"pre-populating" a Lustre FS with files from the archive.  We create an 
empty file, mark it as "in archive", add the OSAM fid, and need to set 
the archive's Lustre FID to match the new empty file.

>
>>
>>
>>
>> Object SAMQFS - Freeing space on tapes
>> --------------------------------------
>>
>> We will need a way to determine with Lustre - conclusively that an 
>> archive is
>> no longer needed.
>>
>>   If Lustre policy manager says "rm", then Lustre has no way to ever
>>   get that file back.  There's no time-machine like old versions of
>>   directories.  Would be a cool feature though.  Maybe archive says
>>   "ok" to the rm, but secretly holds on to the file for some time in a
>>   special "recently deleted" dir?
> No namespace - no dir.
>
> If Lustre removes the file, we can delay the scrub.  If Lustre can 
> come back with the Lustre ID and OSAM ID, if it has not been scrubbed, 
> you can get it back.
>
Let's not worry about this for V1.  Once a file is rm'ed from Lustre, no 
way to get back Lustre ID or OSAM ID.