Policies

From T2B Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Policies concerning the usage of local computing resources

  • The following rules are put in place to allow a fair share of resources between the users. In case you violate these rules your account could be disabled.
  • In case you have specific needs concerning storage or CPU please contact the site administrators on T2bSupport.

User Interface policy

  • All user interfaces are running Scientific Linux 6.
  • The following machines are for light tasks, such as:
    • Crab submission
    • small interactive root processes
    • building code
    • debugging code
m0.iihe.ac.be, m1.iihe.ac.be, m2.iihe.ac.be, m3.iihe.ac.be
  • The following machines are available for CPU-intensive and long tasks
m5.iihe.ac.be, m6.iihe.ac.be, m7.iihe.ac.be, m8.iihe.ac.be and m9.iihe.ac.be

This policy is enforced. Processes taking more than 10 minutes CPU on M1->M3 will be killed by the operating system. This limit is set to 5 hours on M5->M8. On M9 the limit is set to 500 hours

Disk space usage policy

  • Users can have several locations to store their files/analysis code/final results/...
    • The /user partition on the UIs (m-machines) is limited to 500 GB per user.
      This space should be used as working environment, eg. to checkout code, store results,... It should not be used to store large datasets.
    • The /localgrid partition on the UIs (partition is mounted on the workernodes), with its quota shared with /user, so max(/localgrid + /user = 500 GB).
      This space serves as sandbox for input/output of jobs sent to the local batch queue.
    • The /pnfs area has a limit of 2TB per user.
      This area should contain the sometimes large dataset needed for physics analysis.
    • In case one needs more space, please contact the site admins here.
  • Semi-Automatic removal of old files on /pnfs is done every 3 months.
    • All files not accessed in 1 year need to be explicitely un-flagged by the user in order to keep them
    • All other files CAN be marked by the user for deletion
    • Several mails will be send to remind all users to do this.
    • These mails will be send in a span of ~1month, after which the admins will proceed to the deletion of all flagged files.
  • More information is found on the deletion page: http://mon.iihe.ac.be/OldPnfsFiles
    • If you need an account on this page, please ask the admins (grid_adminNOSPAM@listserv.vub.ac.be)

Back-up procedures of files

  • The is a local backup (snapshot mechanism) of the user home directories (for more detailed info, see Backup
    • This back-up is made every day and we can go back day by day till last week. This is to address e.g. user small mistaken deletions.
    • Users are strongly advised to not solely rely on this backup. Using a versioning system (SVN or CVS) should prevent accidental removal of files and allowas a user to go back to a previous file when the file was messed up. We don't maintain a CVS repository ourselves but the CMS one should be used, more info here
  • The entire user home directories are backed up every week in a physically separated hardware. This is to address catastrophe scenario.

Memory usage on the grid

  • To protect the grid, there is an upper memory limit per job of 2.0GB (this is larger than what is asked by CMS) for the physical and the virtual memory.
  • If your job exceeds this limit, it will be killed by the queueing system.
    • in you crab error log, you will find an error code 271
    • if you use direct submission, the reason will be clearly stated in your error log