Policies - Revision history

Gcormier at 02:33, 18 May 2026

2026-05-18T02:33:21Z

← Older revision		Revision as of 22:33, 17 May 2026
Line 133:		Line 133:
	As a matter of policy, the GACRC will not purchase any commercial software for the use of a single group or a small number of groups. Commercial software currently purchased and maintained by the GACRC are of general interest and applicability to the whole UGA research community. The GACRC will however install and maintain a group-purchased commercial software, which complies with the above comments on licenses and contracts.		As a matter of policy, the GACRC will not purchase any commercial software for the use of a single group or a small number of groups. Commercial software currently purchased and maintained by the GACRC are of general interest and applicability to the whole UGA research community. The GACRC will however install and maintain a group-purchased commercial software, which complies with the above comments on licenses and contracts.



			== AI Workflows and GPU Usage Expectations ==
			GACRC is seeing a significant increase in the use of AI-assisted tools and workflows, including code assistants, automated job generation, and model-serving frameworks. These patterns are placing increasing pressure on shared resources, particularly high-end GPUs and interactive systems. As a result, GACRC is issuing a policy update to clarify and reinforce expectations for shared GPU usage, interactive workflows, and AI-driven activity.

			'''1. Monitoring and Enforcement'''

			The GACRC actively monitors system usage to ensure fair access, system stability, and compliance with institutional policies. Patterns of concern include:

			* Long-running interactive GPU sessions with low or intermittent utilization
			* Persistent or service-like workloads running on shared compute nodes
			* Running of software on the login/head node, including remote development environments
			* Excessive or automated job submission that impacts scheduler performance
			* Large-scale filesystem activity that degrades shared storage performance

			If these patterns persist, the GACRC will take additional action, including applying stricter limits, modifying scheduling policies, terminating compute jobs, or temporarily or permanently removing user access to GACRC resources.

			'''2. GPU Usage and Interactive Work'''

			High-end GPUs (e.g., A100, H100) are scarce shared resources and are intended for scheduled batch workloads. '''Long-running or persistent interactive use of these GPUs is not permitted.''' Holding GPUs for extended periods—especially when usage is intermittent or low—reduces availability for other researchers and undermines the scheduling system. Interactive GPU sessions must be limited to short-duration development and debugging. Production workloads must be submitted through the batch scheduler. This policy statement does not apply if the GPU resources are buy-in compute nodes.

			'''3. Persistent and Service-Like Workloads'''

			Shared compute nodes are not designed to support persistent or service-like workloads. This includes model-serving endpoints, long-lived notebooks, AI assistants, and agent-based systems. '''Running such workloads on shared GPU resources is not permitted.''' Groups requiring persistent or always-on GPU-backed services should work with GACRC to identify appropriate alternatives. This policy statement does not apply if the GPU resources are buy-in compute nodes.

			'''4. Login Node Usage and Development Environments'''

			Login nodes are reserved for lightweight activities such as code editing, and job submission. '''Running persistent or resource-intensive processes on login nodes—including remote IDE backends such as VSCode, Cursor, or similar tools—is not permitted.''' Users who require interactive development environments should use [[OnDemand\|'''Open OnDemand''']] '''or other approved interactive compute options''', which provide a supported way to run these tools without impacting the shared login infrastructure.

			'''5. Automated and AI-Driven Workflows'''

			AI-assisted and automated workflows must be used in a controlled manner. Users are responsible for all activity executed under their accounts. Workflows that generate excessive job submissions, recursive execution patterns, or unintended system load are not acceptable.

			'''6. Data, Software, and Filesystem Use'''

			Users are responsible for ensuring that models and software are obtained from trusted sources and do not introduce security risks. Sensitive or restricted data must not be transmitted to external AI services in violation of institutional or sponsor requirements. AI tools that scan or index files must be limited to appropriate project directories. Large-scale scanning of shared filesystems may be restricted.

			'''Finally, a reminder of the Archnews memo of March 26, 2025 from USG Chancellor Perdue in which the following software restrictions were announced:'''

			“As part of this continued effort, Governor Kemp’s administration has updated the list of prohibited apps and websites. In addition to TikTok, WeChat, and Telegram, the following apps are now also disallowed from use on any state-owned and/or -issued devices, including mobile phones, laptops, and tablets:

			# RedNote (social media app)
			# DeepSeek (AI chatbot)
			# Webull (online stock trading)
			# Tiger Brokers (online stock trading)
			# Moomoo (investing app)
			# Lemon8 (social media app)

			'''Please work with the GACRC to find the most appropriate way to accomplish your research goals.'''

			We recognize that AI workflows are evolving rapidly. If your research requires capabilities that do not fit within these expectations, please contact the GACRC. We are committed to working with researchers to support these use cases in a sustainable way.

	==Security==		==Security==

Shtsai at 18:43, 6 May 2026

2026-05-06T18:43:16Z

← Older revision		Revision as of 14:43, 6 May 2026
Line 13:		Line 13:
	The computational resources of the Georgia Advanced Computing Resource Center are to be used in direct support of research programs at the University of Georgia. Support is also provided for classes that teach computational methods, and provide training for high performance computing. The GACRC reserves the right to restrict access to its resources for course work if such work is deemed to present a negative impact to authorized research activities.		The computational resources of the Georgia Advanced Computing Resource Center are to be used in direct support of research programs at the University of Georgia. Support is also provided for classes that teach computational methods, and provide training for high performance computing. The GACRC reserves the right to restrict access to its resources for course work if such work is deemed to present a negative impact to authorized research activities.

	GACRC policies supplement UGA’s Policies on the Use of Computers, found at:~~. http~~://~~eits~~.uga.edu/~~access_and_security~~/~~infosec/pols_regs/policies~~/~~aup~~		GACRC policies supplement UGA’s Policies on the Use of Computers, found at: [https://policy.uga.edu/policies#/programs/BJWfhwRra?group=Information%20Technology%20&bc=true&bcCurrent=Information%20Technology%20&bcItemType=programs&bc=true&bcCurrent=Acceptable%20Use%20Policy&bcGroup=Information%20Technology%20&bcItemType=programs UGA’s Policies on the Use of Computers]


Line 57:		Line 57:
	More information is found at the following EITS website:		More information is found at the following EITS website:

	~~http~~://~~eits~~.uga.edu~~/access_and_security/infosec/pols_regs~~/policies/~~passwords~~/		[https://policy.uga.edu/policies#/programs/HJe8T3sH6?group=Information%20Technology%20&bc=true&bcCurrent=Information%20Technology%20&bcItemType=programs&bc=true&bcCurrent=Password%20Policy&bcGroup=Information%20Technology%20&bcItemType=programs UGA Policy Website]


	==GACRC Storage Usage ==		==GACRC Storage Usage ==
Line 126:		Line 127:

	Any software that requires a signed license or contract, even if it is a click-through agreement, must absolutely be reviewed and handled by the Office of Legal Affairs before being signed by an appropriate signature authority. After the license or contract is accepted and the software is made available, GACRC users must fully comply and use the software in a way that does not violate any terms of the license or contract. Further information on licensing issues can be found at the following EITS website:		Any software that requires a signed license or contract, even if it is a click-through agreement, must absolutely be reviewed and handled by the Office of Legal Affairs before being signed by an appropriate signature authority. After the license or contract is accepted and the software is made available, GACRC users must fully comply and use the software in a way that does not violate any terms of the license or contract. Further information on licensing issues can be found at the following EITS website:
			<!--
	http://eits.uga.edu/access_and_security/infosec/pols_regs/policies/aup/eula		http://eits.uga.edu/access_and_security/infosec/pols_regs/policies/aup/eula
			-->

	As a matter of policy, the GACRC will not purchase any commercial software for the use of a single group or a small number of groups. Commercial software currently purchased and maintained by the GACRC are of general interest and applicability to the whole UGA research community. The GACRC will however install and maintain a group-purchased commercial software, which complies with the above comments on licenses and contracts.		As a matter of policy, the GACRC will not purchase any commercial software for the use of a single group or a small number of groups. Commercial software currently purchased and maintained by the GACRC are of general interest and applicability to the whole UGA research community. The GACRC will however install and maintain a group-purchased commercial software, which complies with the above comments on licenses and contracts.
Line 146:		Line 148:
	More information can be found at the following EITS website:		More information can be found at the following EITS website:

			[https://policy.uga.edu/policies#/programs/BySr6vy8a?q=%20Minimum%20Security%20Standards%20Policy&&limit=20&skip=0&bc=true&bcCurrent=Minimum%20Security%20Standards%20Policy&bcItemType=programs Minimum Security Standards Policy]
			<!--
	http://eits.uga.edu/access_and_security/infosec/protect_your_computer		http://eits.uga.edu/access_and_security/infosec/protect_your_computer
			-->
	===Suspiciously Behaving Software===		===Suspiciously Behaving Software===

Shtsai at 17:04, 4 March 2022

2022-03-04T17:04:02Z

← Older revision		Revision as of 13:04, 4 March 2022
Line 90:		Line 90:
	The HOME file system resides on a high-performance storage device and is used for long-term storage of files, typically programs and scripts, needed for analysis on the GACRC computing cluster.		The HOME file system resides on a high-performance storage device and is used for long-term storage of files, typically programs and scripts, needed for analysis on the GACRC computing cluster.

	All users have ~~100GB~~ allocated for their HOME usage~~. Groups may request a separate 100GB allocation for a directory under /usr/local/lab/, for shared use of common applications, libraries, and scripts~~.		All users have 200GB allocated for their HOME usage.

	HOME directories will have daily, weekly and up to 3 monthly snapshots kept on the same storage unit to protect against accidental file deletion. ~~Currently, the GACRC is not able to perform any backup of the~~ HOME ~~file system onto another~~ storage ~~device~~. Users are strongly encouraged to make their own copies of critical files, while accepting any risks associated with HOME usage~~. Appropriate communications will take place once a backup service is enabled~~.		HOME directories will have daily, weekly and up to 3 monthly snapshots kept on the same storage unit to protect against accidental file deletion. HOME directories will also be backed-up on a different storage unit to protect against filesystem or hardware issues.

			Users are strongly encouraged to make their own copies of critical files, while accepting any risks associated with HOME usage.

	Snapshot retention, data purge and quota allocation policies are subject to change based on available storage capacity, users’ demand, equipment condition and availability, as well as any other conditions that might affect the provision of the HOME service.		Snapshot retention, data purge and quota allocation policies are subject to change based on available storage capacity, users’ demand, equipment condition and availability, as well as any other conditions that might affect the provision of the HOME service.
Line 98:		Line 100:
	===Policy Statement for PROJECT File System===		===Policy Statement for PROJECT File System===

	The PROJECT ~~file system~~ resides on lower-performance/higher-capacity storage devices, accessible by all GACRC login and data transfer nodes. PROJECT will not be accessible on Sapelo2's compute nodes. This space is to be used by groups for storage of active projects using Sapelo2. PROJECT should not be seen as a long-term repository, as it is not designed as such. Once a project is completed, data should be moved from the PROJECT space to user-managed storage, freeing up capacity for the next active project.		The PROJECT filesystem resides on lower-performance/higher-capacity storage devices.

	~~Access to~~ the PROJECT ~~file system is~~ not ~~supported through NFS to a destination outside of the Boyd Data Center, or through the use of the Samba or CIFS protocols. Transfer protocols available through the data transfer~~ nodes ~~are secure ftp, scp, rsync, GridFTP, amongst others~~.		This filesystem is accessible only from the GACRC’s transfer (xfer) nodes. PROJECT will not be accessible on Sapelo2's compute nodes.

	~~More info~~ is ~~found at https://wiki~~.~~gacrc~~.~~uga.edu/wiki/Transferring_Files~~.		This filesystem is to be used by groups for storage of active projects using Sapelo2. PROJECT should not be seen as a long-term repository, as it is not designed as such. Once a project is completed, data should be moved from the PROJECT space to user-managed storage, freeing up capacity for the next active project.

	Each group can request a PROJECT volume with an initial 1TB allocation, accessible by all users ascribed to the group, where the sharing of files will be enabled. Users are encouraged to consider their PROJECT space as the primary area to transfer compute job ~~inputs/~~outputs. Additional space can be requested by a Faculty on behalf of his/her group~~, in increments of 1TB~~.		This filesystem is not for backing-up non-GACRC-related material, such as personal files (music, photos), office documents, and the like. If found, this material is subject to immediate deletion.

			Access to the PROJECT filesystem is not supported through NFS to a destination outside of the Boyd Data Center, or through the use of the Samba or CIFS protocols. Transfer protocols available through the data transfer nodes are secure ftp, scp, rsync, GridFTP, amongst others.

			Each group can request a PROJECT volume with an initial 1TB allocation, accessible by all users ascribed to the group, where the sharing of files will be enabled. Users are encouraged to consider their PROJECT space as the primary area to transfer compute job outputs. Additional space can be requested by a Faculty on behalf of his/her group.

	The GACRC reserves the right to establish a cost-recovery rate for PROJECT storage beyond the initial 1TB allocation. Appropriate communications will take place in such an event.		The GACRC reserves the right to establish a cost-recovery rate for PROJECT storage beyond the initial 1TB allocation. Appropriate communications will take place in such an event.

	PROJECT directories will have daily, weekly and ~~up to 3~~ monthly snapshots kept on the same storage unit to protect against accidental file deletion. ~~Currently, the GACRC is not able to perform any backup of the~~ PROJECT ~~file system onto another~~ storage ~~device~~. Users are strongly encouraged to make their own copies of critical files, while accepting any risks associated with PROJECT usage~~. Appropriate communications will take place once a backup service is enabled~~.		PROJECT directories will have daily, weekly and monthly snapshots kept on the same storage unit to protect against accidental file deletion. PROJECT directories will also be backed-up on a different storage unit to protect against filesystem or hardware issues.

			Users are strongly encouraged to make their own copies of critical files, while accepting any risks associated with PROJECT usage.

	Snapshot retention, data purge and quota allocation policies are subject to change based on available storage capacity, users’ demand, equipment condition and availability, as well as any other conditions that might affect the provision of the PROJECT service.		Snapshot retention, data purge and quota allocation policies are subject to change based on available storage capacity, users’ demand, equipment condition and availability, as well as any other conditions that might affect the provision of the PROJECT service.

Shtsai at 16:56, 4 March 2022

2022-03-04T16:56:56Z

← Older revision		Revision as of 12:56, 4 March 2022
Line 39:		Line 39:
	*A UGA Faculty must first establish a GACRC group account using the instructions provided on the GACRC website (http://gacrc.uga.edu/accounts). The UGA Faculty can choose or not to obtain a GACRC user account affiliated with his/her group account.		*A UGA Faculty must first establish a GACRC group account using the instructions provided on the GACRC website (http://gacrc.uga.edu/accounts). The UGA Faculty can choose or not to obtain a GACRC user account affiliated with his/her group account.

	*~~All directly affiliated persons wanting an account must apply for access to~~ the ~~GACRC~~ using the instructions provided on the GACRC website (http://gacrc.uga.edu/accounts). The applicant must authenticate to the form using his/her MyID. The applicant must specify to which group he/she belongs. Verification with the UGA Faculty responsible for the group’s account will be used in case identity or affiliation needs to be verified.		*User accounts will only be created at the request of a UGA Faculty member, using the instructions provided on the GACRC website (http://gacrc.uga.edu/accounts).

	*Upon acceptance of the application, the user will be notified via e-mail. The applicant’s UGA MyID and password will be used to log into the requested GACRC resources.		*Upon acceptance of the application, the user will be notified via e-mail. The applicant’s UGA MyID and password will be used to log into the requested GACRC resources.

Shtsai at 03:13, 4 March 2022

2022-03-04T03:13:18Z

← Older revision		Revision as of 23:13, 3 March 2022
Line 76:		Line 76:
	The SCRATCH file system resides on a high-performance storage device and is to be used uniquely for temporary storage of files in use by actively running compute jobs. Files are to be removed from SCRATCH when a job completes, e.g. can be copied to the PROJECT file system. The SCRATCH file system is not backed up in any way and no snapshots are taken. The SCRATCH filesystem is mounted under /scratch on all the compute nodes, login nodes and data transfer nodes.		The SCRATCH file system resides on a high-performance storage device and is to be used uniquely for temporary storage of files in use by actively running compute jobs. Files are to be removed from SCRATCH when a job completes, e.g. can be copied to the PROJECT file system. The SCRATCH file system is not backed up in any way and no snapshots are taken. The SCRATCH filesystem is mounted under /scratch on all the compute nodes, login nodes and data transfer nodes.

	Any file that is not accessed or modified by a compute job in a time period ~~no longer than~~ 30 days will be automatically deleted off the SCRATCH file system. Measures circumventing this policy will be monitored and actively discouraged.		Any file that is not accessed or modified by a compute job in a time period of at least 30 days will be automatically deleted off the SCRATCH file system. Measures circumventing this policy will be monitored and actively discouraged.

	There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.		There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.

Ben: We no longer produce the over30d file for every user, removing from wiki

2021-12-06T14:30:25Z

We no longer produce the over30d file for every user, removing from wiki

← Older revision		Revision as of 10:30, 6 December 2021
Line 79:		Line 79:

	There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.		There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.

	In order to help users identify old files in their /scratch directory, we generate one file per user, every morning. This file, namely '''/usr/local/var/lustre_stats/$USER.over30d.files.lst''' (where $USER refers to the user's UGA MyID), contains a list of all the files that this user has in his/her /scratch directory and that have not been accessed in over 30 days. This file provides the full path, the last accessed date, and the size of the files that have not been accessed in over 30 days. Because the /scratch filesystem only updates on-disk file access times every 5 days, the last accessed time reported in that list file is approximate and could be off by up to 5 days. The purging system understands this and will make sure the access time falls within the purge window before deleting the file.

	===Policy Statement for WORK File System===		===Policy Statement for WORK File System===
Line 211:		Line 209:

	More information on data management plans can be found [http://guides.libs.uga.edu/c.php?g=349946&p=2363161 here].		More information on data management plans can be found [http://guides.libs.uga.edu/c.php?g=349946&p=2363161 here].

Raj76: /* Policy Statement for SCRATCH File System */

2020-01-13T17:30:12Z

Policy Statement for SCRATCH File System

← Older revision		Revision as of 13:30, 13 January 2020
Line 80:		Line 80:
	There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.		There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.

	In order to help users identify old files in their /scratch directory, we generate one file per user, every morning. This file, namely /usr/local/var/lustre_stats/$USER.over30d.files.lst (where $USER refers to the user's UGA MyID), contains a list of all the files that this user has in his/her /scratch directory and that have not been accessed in over 30 days. This file provides the full path, the last accessed date, and the size of the files that have not been accessed in over 30 days. Because the /scratch filesystem only updates on-disk file access times every 5 days, the last accessed time reported in that list file is approximate and could be off by up to 5 days. The purging system understands this and will make sure the access time falls within the purge window before deleting the file.		In order to help users identify old files in their /scratch directory, we generate one file per user, every morning. This file, namely '''/usr/local/var/lustre_stats/$USER.over30d.files.lst''' (where $USER refers to the user's UGA MyID), contains a list of all the files that this user has in his/her /scratch directory and that have not been accessed in over 30 days. This file provides the full path, the last accessed date, and the size of the files that have not been accessed in over 30 days. Because the /scratch filesystem only updates on-disk file access times every 5 days, the last accessed time reported in that list file is approximate and could be off by up to 5 days. The purging system understands this and will make sure the access time falls within the purge window before deleting the file.

	===Policy Statement for WORK File System===		===Policy Statement for WORK File System===

Raj76: /* Policy Statement for SCRATCH File System */

2020-01-13T17:29:54Z

Policy Statement for SCRATCH File System

← Older revision		Revision as of 13:29, 13 January 2020
Line 79:		Line 79:

	There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.		There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.

			In order to help users identify old files in their /scratch directory, we generate one file per user, every morning. This file, namely /usr/local/var/lustre_stats/$USER.over30d.files.lst (where $USER refers to the user's UGA MyID), contains a list of all the files that this user has in his/her /scratch directory and that have not been accessed in over 30 days. This file provides the full path, the last accessed date, and the size of the files that have not been accessed in over 30 days. Because the /scratch filesystem only updates on-disk file access times every 5 days, the last accessed time reported in that list file is approximate and could be off by up to 5 days. The purging system understands this and will make sure the access time falls within the purge window before deleting the file.

	===Policy Statement for WORK File System===		===Policy Statement for WORK File System===

Shtsai: /* Policy Statement for WORK File System */

2019-01-31T16:52:14Z

Policy Statement for WORK File System

← Older revision		Revision as of 12:52, 31 January 2019
Line 82:		Line 82:
	===Policy Statement for WORK File System===		===Policy Statement for WORK File System===

	The WORK file system resides on a high-performance storage device and is to be used for storing files that are frequently used by the group for computation. The WORK file system is '''NOT''' subject to the 30 day purge policy. The filesystem usage is controlled using a quota on the size and number of files that can be stored in a lab group's WORK area. Initially each group is given a 500GB and 100,000-file quota. The WORK file system is not backed up in any way and no snapshots are taken. The WORK filesystem is mounted under /work on all the compute nodes, login nodes and data transfer nodes. Each lab group has a directory under the /work directory.		The WORK file system resides on a high-performance storage device and is to be used for storing files that are frequently used by the group for computation. The WORK file system is '''NOT''' subject to the 30-day purge policy. The filesystem usage is controlled using a quota on the size and number of files that can be stored in a lab group's WORK area. Initially each group is given a 500GB and 100,000-file quota. The WORK file system is not backed up in any way and no snapshots are taken. The WORK filesystem is mounted under /work on all the compute nodes, login nodes and data transfer nodes. Each lab group has a directory under the /work directory.

	The WORK file system is '''NOT''' subject to the 30 day purge policy. But if there is sufficient space consumption on the storage appliance, we reserve the right to ask users to clean up their WORK area. If the users do not respond in a timely fashion we will purge files beginning with the oldest ones. Please do not ~~user~~ WORK area to store files long term.		The WORK file system is '''NOT''' subject to the 30-day purge policy. But if there is sufficient space consumption on the storage appliance, we reserve the right to ask users to clean up their WORK area. If the users do not respond in a timely fashion we will purge files beginning with the oldest ones. Please do not use the WORK area to store files long term.

	===Policy Statement for HOME File System===		===Policy Statement for HOME File System===

Jerky at 22:43, 28 January 2019

2019-01-28T22:43:40Z

← Older revision		Revision as of 18:43, 28 January 2019
Line 78:		Line 78:
	Any file that is not accessed or modified by a compute job in a time period no longer than 30 days will be automatically deleted off the SCRATCH file system. Measures circumventing this policy will be monitored and actively discouraged.		Any file that is not accessed or modified by a compute job in a time period no longer than 30 days will be automatically deleted off the SCRATCH file system. Measures circumventing this policy will be monitored and actively discouraged.

	There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.		There is no storage size quota for SCRATCH usage. Space is only limited by the physical size of the scratch space being used. If usage across the entire file system is more than 80% of total capacity, the GACRC will take additional measures to reduce usage to a more suitable level. Amongst possible actions, the GACRC may request/force users to clean up their SCRATCH directories or reduce temporarily the 30 day limit to a lower limit.

	===Policy Statement for WORK File System===		===Policy Statement for WORK File System===

	The WORK file system resides on a high-performance storage device and is to be used for storing files that are frequently used by the group for computation. The WORK file system is '''NOT''' subject to the 30 day purge policy. The filesystem usage is controlled using a quota on the size and number of files that can be stored in a lab ~~groups~~ WORK area. Initially each group is given a 500GB and 100,000 ~~files~~ quota. The WORK file system is not backed up in any way and no snapshots are taken. The WORK filesystem is mounted under /work on all the compute nodes, login nodes and data transfer nodes. Each lab group has a directory under the /work directory.		The WORK file system resides on a high-performance storage device and is to be used for storing files that are frequently used by the group for computation. The WORK file system is '''NOT''' subject to the 30 day purge policy. The filesystem usage is controlled using a quota on the size and number of files that can be stored in a lab group's WORK area. Initially each group is given a 500GB and 100,000-file quota. The WORK file system is not backed up in any way and no snapshots are taken. The WORK filesystem is mounted under /work on all the compute nodes, login nodes and data transfer nodes. Each lab group has a directory under the /work directory.

	The WORK file system is '''NOT''' subject to the 30 day purge policy. But, if there is sufficient space consumption on the storage appliance we reserve the right to ask users to ~~cleanup~~ their WORK area. If the users do not respond in a timely fashion we will purge ~~starting from old~~ files. Please do not user WORK area to store files long term.		The WORK file system is '''NOT''' subject to the 30 day purge policy. But if there is sufficient space consumption on the storage appliance, we reserve the right to ask users to clean up their WORK area. If the users do not respond in a timely fashion we will purge files beginning with the oldest ones. Please do not user WORK area to store files long term.

	===Policy Statement for HOME File System===		===Policy Statement for HOME File System===