Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lmitiation due to the Input sandbox #3

Closed
ericvaandering opened this issue Oct 31, 2013 · 1 comment
Closed

Lmitiation due to the Input sandbox #3

ericvaandering opened this issue Oct 31, 2013 · 1 comment
Assignees

Comments

@ericvaandering
Copy link
Member

Original Savannah ticket 1704 reported by None on Tue Feb 15 07:44:12 2005.

The problem related to the input sandbox quota limit (8M) should be bypassed because executable and libreries are passed to a job via a tar.gz files with variable sizes..

Possible solution:
to implement in CRAB a piece of code to handle the copy of the tar.gz file in a specific SE used hardcoded by CRAB.

The SE can be eventually specified by the user.
Possible problem comes if different users use an executable
with the same name store it in the same location in the SE.

The problem can be solved with BOSS but it still not implemented.

The storage of the tar.gz. file on the SE does not mean that that the file has to registered on the replica catalog but it is necessary to match the information of the lfn with the pfn on the SE..

Output files should be also stored in SE and and eventually deleted at the end of a specified task.

The retrieve of the output and the deletion of the output
file from the SE is not stills implemented in BOSS.

@ghost ghost assigned ericvaandering Oct 31, 2013
@ericvaandering
Copy link
Member Author

Closed by spiga on Mon Feb 4 09:22:55 2008

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

No branches or pull requests

1 participant