So.
The way DPM does it (hidden behind the API) (and thus, also the way
dpm-disk-to-dpns does it internally) is (in annotated SQL):
use cns_db;
select fileid, parent_fileid, name from Cns_file_replica join
Cns_file_metadata where sfn = FULLSFN ;
The dpns namespace is stored as a tree in the Cns_file_metadata table,
with parent_fileid entries pointing at the fileid for their, well,
parent.
The above query gives you the leaf of the dpns path as the "name"
returned. The FULLSFN is the full physical location for the file,
specified as fulldiskserverhostname:fullpathondiskserver
You can then recursively do
select parent_fileid, name from Cns_file_metadata where fileid =
parent_fileid-from-previous-query
to build up the full dpns path (which you then just need to add the
usual SE_HOST_NAME to do get the full thing.)
There actually are bits of code that do this floating around (some of
the DPM toolkit tools have functions that perform this filesystem
walk), so it's fairly easy to write a tool for it if people want one.
Sam
On 17 May 2010 13:17, <[log in to unmask]> wrote:
> Especially for Sam & Wahid...
>
> So Raul at Brunel asked me a question , for which i do not have an answer
> to.
> He is trying to drain a disk swerve and has two files left.
> He has the local disk server pathname for these files.
> How doe he get me the dpns pathname ( for just two files, not using
> dpm-disk-to-dpns script) so that atlas can mark these files as dead?
> This is a possibility for a new dpm-toolkit tool?
>
> Brian
|