Hi Ewan,
I assume the space token usage issue still hasn't been solved?
Greig and I just got an email from David Smith which explains
precisely how this stuff works.
Essentially, dpm-listspaces ends up looking at the (memory cached copy
of the) u_space field for each space token in dpm_db.dpm_space_reserv.
This field is supposed to be set equal to the amount of *free* space
available in that token, and is updated both on each file request
starting (to an estimate of the size of the file transferred) and then
on completion of the file transfer (to the actual on-disk value of the
file size).
I think, therefore, that it should be possible to correctly set the
value of u_space by doing:
use cns_db
select sum(f.filesize),r.setname,f.status from Cns_file_metadata as f,
Cns_file_replica as r where f.fileid=r.fileid and r.status!='P' group
by r.setname,f.status;
to get the correct total on-disk size of the files for each space
token (= setname), and then doing some subtraction to arrive at the
value to set each u_space field to.
(You may want to do:
use dpm_db
select sum(requested_size),s_token from dpm_put_filereq where
(status=12288 or status=16384) group by s_token;
to check if there are any incoming /requests/ which are also reserving
space before setting u_space appropriately. If there are requests
which will take a long time to complete, you can include the size of
the returned values in your calculation for the total filesize in
u_space )
Regardless, after updating the value of u_space for the spacetokens,
you will need to restart the dpm daemon to get it to refresh its
in-memory accounting of space used, otherwise it will look like this
hasn't changed at all.
If you're not happy doing this, I can construct a tool which will
appropriately set the field values, in a bit.
I assume that you *have* restarted the dpm daemon since this problem
showed itself, just in case the db is actually correct?
Sam
2009/1/30 Ewan MacMahon <[log in to unmask]>:
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage
>> Hi Ewan, (and others)
>>
>> Can you try running this query?
>>
> Hi,
>
> I'm just getting back onto this after a few local distractions; running
> that
> query gives us:
>
> +--------------------------------------+---------------------+---------+
> -----------------+
> | Space Token | Token Desc. | # Files |
> Total Size (GB) |
> +--------------------------------------+---------------------+---------+
> -----------------+
> | | NULL | 74769 |
> 4704.223786 |
> | NULL | NULL | 10 |
> 0.000000 |
> | f1171e3a-a112-4069-b6b8-7f54a4a9c3c4 | ATLASDATADISK | 1797 |
> 504.630595 |
> | adfd9d4a-ac99-4c14-8a43-0365e0d6b1e8 | ATLASGROUPDISK | 1 |
> 0.000002 |
> | e957b434-b61c-48eb-9aa0-01dc58cd5b97 | ATLASLOCALGROUPDISK | 26139 |
> 784.871504 |
> | 00522908-91fb-4c5b-8816-b036d3b56a3d | ATLASMCDISK | 296222 |
> 8937.174374 |
> | 574944c4-0ddf-4eb4-b66c-0ffba12a28dc | ATLASPRODDISK | 3106 |
> 167.958198 |
> | 2be8239e-01e7-4197-9c9a-9e15fa403223 | ATLASUSERDISK | 25541 |
> 1106.292630 |
> +--------------------------------------+---------------------+---------+
> -----------------+
> 8 rows in set (5.04 sec)
>
> Which I think looks relatively sane (with the possible exception of the
> first row).
> dpm-listspaces, however, shows:
>
> # dpm-listspaces
>
> POOLS:
>
> dpmPart
> CAPACITY: 130.67T RESERVED: 47.28T UNAVAIL (free/used):
> 25.43T/0.00
> USED: 8.24T FREE: 49.71T (38.0%)
> Space Tokens: ATLASDATADISK, ATLASGROUPDISK, ATLASLOCALGROUPDISK,
> ATLASMCDISK, ATLASPRODDISK, ATLASUSERDISK
> Authorized FQANs: alice, atlas, babar, biomed, calice, camont, cdf,
> cedar, cms, dteam, dzero, esr, fusion, geant4,
> gridpp, hone, ilc, lhcb, magic, mice, minos,
> minos.vo.gridpp.ac.uk, na48, ngs, ngs.ac.uk, ops,
> oxg, pheno, planck, sixt,
> supernemo.vo.eu-egee.org,
> t2k, vo.southgrid.ac.uk, zeus
> Space Type: Any Retention Policy: Replica
> Number of file systems : 35 FS selection policy:
> maxfreespace
>
>
> SPACE RESERVATIONS:
>
> ATLASDATADISK ID=f1171e3a-a112-4069-b6b8-7f54a4a9c3c4
> CAPACITY: 16.49T RESERVED: 16.49T UNAVAIL (free): 0
> USED: 0.00 FREE: 16.49T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas/Role=production
> Pool: dpmPart
>
> ATLASGROUPDISK ID=adfd9d4a-ac99-4c14-8a43-0365e0d6b1e8
> CAPACITY: 2.20T RESERVED: 2.20T UNAVAIL (free): 0
> USED: 0.00 FREE: 2.20T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas/Role=production
> Pool: dpmPart
>
> ATLASLOCALGROUPDISK ID=e957b434-b61c-48eb-9aa0-01dc58cd5b97
> CAPACITY: 6.60T RESERVED: 6.60T UNAVAIL (free): 0
> USED: 0.00 FREE: 6.60T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas
> Pool: dpmPart
>
> ATLASMCDISK ID=00522908-91fb-4c5b-8816-b036d3b56a3d
> CAPACITY: 17.59T RESERVED: 17.59T UNAVAIL (free): 0
> USED: 0.00 FREE: 17.59T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas/Role=production
> Pool: dpmPart
>
> ATLASPRODDISK ID=574944c4-0ddf-4eb4-b66c-0ffba12a28dc
> CAPACITY: 2.20T RESERVED: 2.20T UNAVAIL (free): 0
> USED: 0.00 FREE: 2.20T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas/Role=production
> Pool: dpmPart
>
> ATLASUSERDISK ID=2be8239e-01e7-4197-9c9a-9e15fa403223
> CAPACITY: 2.20T RESERVED: 2.20T UNAVAIL (free): 0
> USED: 0.00 FREE: 2.20T (100.0%)
> Space Type: Any Retention: Replica Latency: Online
> Lifetime: Infinite
> Authorized FQANs: atlas
> Pool: dpmPart
>
> So it seems to have the correct space token descriptions, the correct
> 'actual' space
> tokens, but not be reporting the usage. Also; if the 'Total Size (GB)'
> column in the
> mysql output is total amount /used/ then is appears to add up to ~16Tb,
> whereas
> dpm-listspaces thinks the total usage is 8.24Tb. The 25Tb shown as
> 'unavailable' is,
> I think, correct - we've got some pools marked as readonly, and their
> free space
> adds to about that amount.
>
> Ewan
>
|
