...

Capacity to inode Ratio

Ratio: 1TB Quota to 7501,500,000 iNodes

An inode is a record that describes a file, directory, or link.  This information is stored in a dedicated flash pool on Taiga and is of a finite capacity.  To ensure that the inode pool does not run out of space before the capacity pools, this quota ratio is implemented.  So for example if your project has a 10TB quota on Taiga, it will also have a quota of 715.50 0 million inodes.  If you have any questions about this ratio please contact the storage team by opening a support ticket.  

...

Native mounts of Taiga using the Lustre client are greatly preferred for superior performance and increased stability, however sub-directories of Taiga can be mounted via NFS in cases where that is necessary.  The NFS service is accessed via the HA taiga-nfs.ncsa.illinois.edu endpoint.  The NFS endpoint is currently comprised of 4 servers that are directly connected to the 100GbE public-facing storage network and via redundant links to Taiga's HDR Infiniband core fabric.   If you need an NFS export please file a ticket with the STO: Taiga component flag and the storage team will assist in getting the exported provisioned.  

Taiga Allocation Access Guidelines

Access to data on Taiga is ultimately governed by normal POSIX permissions and more specifically so, group membership.  Some common scenario's are below:

Direct Investment

If you/your team has a direct investment on the Taiga system separate from a compute allocation, access to your area is governed by an LDAP group that was created during the allocation onboarding; this group name often (but not always) looks like taiga_prj_XXXXX.  Your group's PI (and whomever they've designated) are able to add you to the LDAP group that controls access to your allocation via NCSA's Identity Portal.  Once you are a member of this group, you should have access to the data from any system that mounts Taiga across the center and the path will be the same.

HPC System Project Directory Access

Many NCSA compute environments leverage Taiga for their project space.  For example, Delta's /projects  mount maps to the full path /taiga/nsf/delta/ .  Accessing data that is within compute environment project areas requires membership to the compute/system allocation for the system in question (be it Delta, HOLL-I, etc.).  The compute allocation PI should be able to get you added to that group which will gain you access to this data, an example of this LDAP group would be delta_XXXX.  Once in that group you should be able to access this data from all NCSA compute environments you have access to (via the full path) and on the system the allocation originates from via /projects/ .  

Radiant Allocation

Radiant allocations on Taiga live underneath the full path, /taiga/ncsa/radiant/  and are by default only available via NFS mount within Radiant instances associated with that allocation.  If access of this data outside of Radiant is needed, please speak with the storage team by opening a ticket with the STO: Taiga component flag and someone from the storage team will assist you with your needs.  

Data Recovery

Snapshots (Coming Soon)

...

Data on Taiga is not backed up; and is only a single copy.  It is recommended to back up critical data to an allocation on the Granite tape archive system or on another system on which you have an allocation.  

VM

Data Services Virtual Machines

Some groups may want/need to have virtual machines that can directly access their data on Taiga for things like: data serving, data portals, light data analysis/indexing, etc.  For these use cases groups should procure a Radiant allocation of the appropriate size to operate these services.  Radiant For VM attached storage, we recommend utilizing the Radiant openstack service. This is a separate service but will allow projects to have VMs to be able to handle their data pipeline/other requirementsis a scaleable way to give groups access to VM infrastructure that can access their data.