UMIACS - User contributions [en]

FilesystemDataStorage

2024-12-03T17:17:32Z

Kcanha: /* UNIX Filesystem Storage Commands */

Filesystem [[Data Storage | (data) storage]] refers to all data that is stored physically at UMIACS, i.e., on hard drives either in servers in datacenters managed by [[HelpDesk | UMIACS staff]], or in UMIACS-supported workstations. The opposite of this is [[CloudDataStorage | cloud storage]] which is stored on third-party providers' data hosting platforms.

The below sections outline the different categories of filesystem storage available at UMIACS. Although technically filesystem storage by the above definition, UMIACS also hosts an [[OBJ | Object Store]] that is documented outside the scope of this page.

==Network Home Directory Filesystem Storage==
We provide network home directory filesystem storage to each of our users through [[NFShomes]] home directories.

This home directory can be accessed via either

/nfshomes/<username> (NFS)

or

\\isilondata.umiacs.umd.edu\nfshomes\<username> (CIFS)

and is backed up nightly using the Institute's [[TSM]] backup system. It also has [[Snapshots]] enabled for easy user restores.

Users are given a 30GB, non-expandable [[Quota]]. You will need to use either platform-specific filesystem storage, directly-attached filesystem storage, or other network-attached filesystem storage for increased space.

On user account closure, the account's NFShomes home directory goes into our [[Archives]].

==UNIX Filesystem Storage==
UNIX hosts use redundant, backed-up network file shares for user directories ([[#Network Home Directory Filesystem Storage |above section]]). Research data storage ([[#Network-Attached Filesystem Storage |below section]]) is also stored on redundant, possibly-backed-up network file shares and is generally available under /fs/

All UNIX hosts also have filesystem storage available for transitory use. These directories may be used to store temporary '''''COPIES''''' of data that is permanently stored elsewhere or as a staging point for output.

These directories may not, '''''under any circumstances''''', be used as permanent storage for unique, important data. They are not backed up or archived by UMIACS. UMIACS staff cannot recover damaged or deleted data from these directories and will not be responsible for data loss if they are misused. Additionally, on our [[SLURM]] compute clusters, these volumes may have an automated cleanup routine that will delete unmodified data after some number of days. You can check the page for the specific cluster you are using for more information.

Please note that '''/tmp''' in particular is at risk for data loss or corruption as that directory is regularly used by system processes and services for temporary storage.

These directories include:

- /tmp
- /scratch0, /scratch1, ... (/scratch#)
- any directory named in whole or in part "tmp", "temp", or "scratch".

==Windows and macOS Filesystem Storage==
Windows and macOS hosts at UMIACS store user directories on their primary internal drives (<tt>C:\Users</tt> for Windows, <tt>/Users</tt> for macOS). Supported, UMIACS-managed hosts automatically back up user data on these drives nightly using the Institute's [[TSM]] backup system. If you have a supported, UMIACS-managed host that has other internal or external hard drives attached to it, or other partitions on its primary internal drive, please be aware that these drives/partitions '''are not''' backed up. Laptops and non-standard hosts are not automatically backed up and should be manually backed up by their users.

On host decommission, user directories go into our [[Archives]].

==Direct-Attached Filesystem Storage==
Direct-attached filesystem storage refers to devices like USB flash drives and USB hard drives, which are very popular for easily expanding storage capacity on a host. However, these devices are significantly more vulnerable to data loss or theft than internal or networked data storage. In general, UMIACS discourages the use of direct-attached filesystem storage when any other option is available. Please note that these devices are prone to high rates of failure and additional steps should be taken to ensure that the data is backed up and that critical or confidential data is not lost or stolen.

Direct-attached filesystem storage is not backed up or archived by UMIACS.

==Network-Attached Filesystem Storage==
Some labs have network-attached filesystem storage space dedicated for datasets, models, and project storage. These shares are typically named in the form <tt>/fs/<lab>-<purpose></tt> (i.e., <tt>/fs/cml-models</tt> or <tt>/fs/vulcan-projects</tt>).

Network-attached filesystem storage may or may not be backed up and/or archived by UMIACS. Details of a specific share's retention policy should be stated along with the documentation of the share's access / usage policy. If you find documentation for a network-attached filesystem storage space in this wiki that does not state its retention policy, please [[HelpDesk | contact staff]].

===Network-Attached Filesystem Scratch Storage===
One specific sub-category of network-attached filesystem storage is network-attached filesystem scratch storage. These shares are named similarly to UNIX filesystem storage, but with the lab's name included (i.e., <tt>/fs/cbcb-scratch</tt> or <tt>/gammascratch</tt>), are intended for scratch/temporary storage, and are subject to the same policies as filesystem scratch/tmp directories, discussed above.

Network-attached filesystem scratch storage is not backed up or archived by UMIACS.

==UNIX Filesystem Storage Commands==
Below are a few different CLI commands that may prove useful for monitoring your filesystem storage usage and performance. For additional information, run <code>[command] --help</code> or <code>man [command]</code>

df - Shows descriptive file system information
<pre>
Usage: df [OPTION]... [FILE]...
Show information about the file system on which each FILE resides,
or all file systems by default.
</pre>
For example, to check how much space is available at a directory:
<pre>df -h ./</pre>

du - Shows disk usage of specific files. Use the -d flag for better depth control.
<pre>
Usage: du [OPTION]... [FILE]...
or: du [OPTION]... --files0-from=F
Summarize disk usage of each FILE, recursively for directories.
</pre>
For example, to check how much space each file in a directory takes up:
<pre>du -ah -d 1 ./</pre>

free - Shows current memory(RAM) usage. Use the -h flag for a human readable format.
<pre>
Usage:
free [options]
</pre>

quota - Shows quota information, this is useful for viewing per filesystem limits in places such as a home directory.
<pre>
quota: Usage: quota [-guqvswim] [-l | [-Q | -A]] [-F quotaformat]
quota [-qvswim] [-l | [-Q | -A]] [-F quotaformat] -u username ...
quota [-qvswim] [-l | [-Q | -A]] [-F quotaformat] -g groupname ...
quota [-qvswugQm] [-F quotaformat] -f filesystem ...
</pre>

iostat - Shows drive utilization, as well as other utilizations. Pair this with the <code>watch</code> command for regular updates.
<pre>
Usage: iostat [ options ] [ <interval> [ <count> ] ]
Options are:
[ -c ] [ -d ] [ -h ] [ -k | -m ] [ -N ] [ -t ] [ -V ] [ -x ] [ -y ] [ -z ]
[ -j { ID | LABEL | PATH | UUID | ... } ]
[ [ -T ] -g <group_name> ] [ -p [ <device> [,...] | ALL ] ]
[ <device> [...] | ALL ]
</pre>

VS Code

2024-07-01T19:08:38Z

Kcanha:

[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.

==Cluster Usage==
It can be convenient when using our [[SLURM]] computing clusters to open a connection to a [https://code.visualstudio.com/docs/remote/vscode-server VS Code Server] session on the submission node(s) that you have access to via VS Code's [https://code.visualstudio.com/docs/remote/ssh Remote - SSH extension]. Steps to set this up can be found [https://code.visualstudio.com/docs/remote/ssh#_installation here]. Use your UMIACS username and the [https://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name (FQDN)] of the submission node you want to connect to. Password authentication does not provide an option to save your password, so for convenience, you may want to set up an [[SSH/Keys | SSH key]].

For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].

===Best Practices===
Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of "best practices" that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.

====Use only as a code editor====
VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other processes on the submission node (both system-level and other users') slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.

The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as <code>mv</code>/<code>cp</code>/<code>rm</code> in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[Data_Transfer | here]] for larger data transfers between nodes.

====Do not open large files====
Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.

As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Either use a lighter-weight command-line based text editor such as [https://www.vim.org/ vim] or otherwise on the submission node itself, or first [[Data_Transfer | transfer]] the files that you would like to open to either a less-used remote machine or your local machine before opening them.

If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.

====Clean up when done====
If you are done using VS Code for an extended period of time (several hours / overnight), consider manually killing your server session on the submission node when exiting. By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect, keeping the VS Code Server processes on the submission node you were using alive, despite no longer actively being used.

This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Kill VS Code Server on Host...".

: [[File:VSCode-killremote1.png]]

Select the submission node you were using and click on it.

: [[File:VSCode-killremote2.png]]

Wait a few seconds and you should get a message confirming the command went through.

: [[File:VSCode-killremote3.png]]

The next time you connect to the same submission node, you will have a fresh VS Code session on it.

==Common Issues==
If you are having trouble ssh'ing to a submission node with VS Code, check if your home directory is full, try the following troubleshooting steps before contacting staff:

[https://wiki.umiacs.umd.edu/umiacs/index.php/Nexus#Access Remote connect to a server]

navigate to your home directory
<pre>cd ~</pre>
and check if it is full
<pre>df ./</pre>
If it is full (Available 0), you will need to delete some files to be able to ssh with VS Code