Skip to content

[v7r2] recursiveSum option in DFC getDirectorySize#5057

Merged
atsareg merged 2 commits into
DIRACGrid:rel-v7r2from
chaen:rel-v7r2_FEAT_rawStorageUsage_cp
Mar 30, 2021
Merged

[v7r2] recursiveSum option in DFC getDirectorySize#5057
atsareg merged 2 commits into
DIRACGrid:rel-v7r2from
chaen:rel-v7r2_FEAT_rawStorageUsage_cp

Conversation

@chaen

@chaen chaen commented Mar 24, 2021

Copy link
Copy Markdown
Contributor

Replaces #5025

BEGINRELEASENOTES
*DMS
NEW: Allows to retrieve the non recursive size of a directory from the DFC
CHANGE: Factorize TornadoFileCatalogHandler and FileCatalogHander

ENDRELEASENOTES

@chaen

chaen commented Mar 24, 2021

Copy link
Copy Markdown
Contributor Author

@andresailer how can I force a rebuild of the doc ?

@andresailer

Copy link
Copy Markdown
Contributor

No idea for the PR builds

@chaen

chaen commented Mar 25, 2021

Copy link
Copy Markdown
Contributor Author

Turns out it is still WIP readthedocs/readthedocs.org#6524

@chaen chaen closed this Mar 25, 2021
@chaen chaen reopened this Mar 25, 2021
@atsareg

atsareg commented Mar 28, 2021

Copy link
Copy Markdown
Contributor

This looks OK to me, but the non-recursive option is only available for the implementation with stored procedures. Related to that I have 2 questions. 1. What is the real use case for the non-recursive directory size ? 2. If there is a real use case, then the other implementation can be also updated to provide non-recursive directory sizes, which should be easy to do.

@chaen

chaen commented Mar 29, 2021

Copy link
Copy Markdown
Contributor Author

The use case is the data popularity tools of LHCb. We want to know what is the non recursive size of a directory. So what we do is that we ask the size of a directory, and substract the size of all the sub directories. In the case of LHCb, this is fantastically stupid since what we store in the FC_DirectoryUsage table is exactly the non recursive size.
At the time when I designed the DFC managers for LHCb, we discussed at nauseam this table. I claimed that storing the non recursive sum was much better, and that the way it was originally done leads to deadlock and wrong accounting. I could not convince you of the problem (that's why the table of the original DFC still store recursive sum), and you said that there was absolutely no point in storing non recursive sums anyway (that's why I did not add the option here).
In any case, as we already discussed, there is way too much mess in the other managers. There are 3 or 4 managers for each, while only one actually works at the time I tested them. So it would be good to do some cleanup regardless. But I do not know which ones are really used

@atsareg

atsareg commented Mar 29, 2021

Copy link
Copy Markdown
Contributor

OK, I see, this is for a rather specific case of LHCb where files and directories are mixed and a specific data popularity evaluation is used. Then there is no urgency in fixing other managers accordingly.

@atsareg atsareg merged commit bff07ec into DIRACGrid:rel-v7r2 Mar 30, 2021
@chaen chaen deleted the rel-v7r2_FEAT_rawStorageUsage_cp branch August 11, 2022 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants