Disk space on faculty/research clusters
Most of this page describes various storage provided by LCSR, which you can use. However you can use the same technology to set up your own file servers, or to allow files on your server or desktop to be available from other systems.
The underlying approach we use is NFS, a Network File System that is supported for Unix and Linux, and to some extent also MacOS and Windows. Specifically, we use NFS version 4 with Kerberos authentication. Version 4 with Kerberos allows incorporation of systems run by different system administrators, which may not always have consistent UID and GIDs, and may have varying levels of security.
We also recommend setting up the /net virtual file system. That allows you to access files on any system that permits it, without having to get your system administrator to add a mount. Thus is provides the illusion that file systems on all of our servers are part of a single, combined name space.
Systems run by LCSR already have the necessary software. For information on integrating your systems into our Kerberos infrastructure, see Setting up Kerberos and Related Services.
Storage available with Computer Science
Users' home directories are located on the LCSR NetApp, and on several petabyte Linux-based file servers. Users are given quotas on the NetApp in order to minimize their impact both on other users on the same qtree (NetApp's version of a partition) and the smooth functioning of the NetApp itself. Should you find your initial quota too small, you can request additional space (please give an estimate of what you need) in an email to "help". (Our guideline for max quotas is 5GB for faculty, 3GB for researchers.)
Should you need large amounts of space, there are several options:
Shared local filesystems
Most machines have some extra non quota disk space set aside in a partition called /freespace/local.You should note that this filesystems are not backed up. Also, please be a "good citizen" in your usage of these filesystems. Don't fill them up or leave large amounts of data there for long periods of time.
On aurora.cs.rutgers.edu only, there are additional extra local non quota storage under the name: /aurora.cs/local1 ... /aurora.cs/local9 and /aurora.cs/ssd that you can use for temporary storage. Note that this filesystems are not backed up. Also, please be a "good citizen" in your usage of these filesystems. Don't fill them up or leave large amounts of data there for long periods of time.
- LCSR's filer
LCSR has a raided (so any single disk failure will not cause data loss) filer with about 9 TB space available on it. The space is split into two separate temporary filesystems. Like the local shared filesystems, this space is not counted toward your disk quota and not backed up. Usage on the filer is a matter of public record. More details on the filer are contained in a warning file in the root of each filesystem called README.this-filesystem-is-not-backed-up. The filesystems are separated as follow:
- Project space on our NetApp
Larger amounts of space can be arranged for on our NetApp for individuals or groups needing backed up space. This space is generally subject to the same restore policy that our home directories on the NetApp are. (Essentially, we keep backups for up to two months and have a fall back position in case of hardware failure.) This space must be requested by the DCS faculty member working on the project. For details, see our page on project disk space.
- Purchase additional capacity for our NetApp
Home directory and project space are allocated from space provided by LCSR on our NetApp. If you need much larger space, you could actually purchase more capacity for our NetApp. The last time we estimated the cost, it ran about $15k for 1.4TB of user space, $21k for 4.2TB, up to $25k for 6TB. If you're interested in this, send an email to help@cs and we can get some quotes.
- Petabyte filers
CBIM currently has two 1 PB file servers, but reasonable amounts of space are available for other CS users. File storage can be requested through firstname.lastname@example.org.
- Sharing files between systems
If you want to make local files on your system available for other systems, see sharing files.
- Cloud storage
We don't currently mount cloud storage on our faculty or research systems. We provide a tool for dropbox on desktop systems. Here's what we currently know:
- There is a Dropbox client. It's a synchronization tool, which means that it copies all your files to a local file system, and keeps them in sync with the cloud copies. The client is installed on our desktop computers. I could be installed on servers by request.
- The University is in the process of arranging an unlimited capacity contract with box.com. Access to box.com is via webdav. Performance is good for copying large files, not good for operations creating lots of small files. When the arrangement is made public, we will install a script that automates setting up webdav. For systems you manage, install the davfs2 package. Then you can use mount -t davfs https://dav.box.com.
- The University has an arrangement with Google that includes Google Drive. Gnome supports this. To access files on Google Drive, go to the control center, then Internet Accounts. Once you set that up, your Google Drive appears in the file browser. You can access it from the command line through /run/user/UID/davfs, where UID is your numerical user ID. (You can use the "id" command if you don't know it.) In that directory you'll see all the external services mounted through Gnome. We don't have a good solution if you're not using Gnome. There are other tools available, but they don't look like anything we'd want to support on our public systems.
- If there are other cloud services you want to access, contact email@example.com. There are tools avaiable for many services, but many of them aren't things we'd want to make generally available.
- If you are using VMs or storage in Amazon or similar environments, we're willing to look at setting up links from systems here to them. There are Linux tools to access Amazon file systems and their competitors.
If you maintain your own disk space you would like to access, there are three options for access to your own filesystems: The first two options can also be used to access our file systems from home computers. For more information about sharing files between systeme you maintain, or making files available on LCSR computers, see sharing files.
LCSR has installed sshfs on our primary clusters. You can also install it on system you run, as well as home systems. sshfs allows you to mount file systems to which you have access on any computer where you can login via ssh. Performance is at least as good as an NFS mount, and often better. In most cases this is a better option than WebDAV. For details, see https://cs.rutgers.edu/resources/accessing-files-remotely.
LCSR now supports WebDAV access to many of our filesystems. If you like, you can register your disk space with our WebDAV server and access it using our deparmental credentials. You can read about our WebDAV service at https://cs.rutgers.edu/resources/accessing-files-remotely. To arrange for registration of your filesystem, send an email to help@cs.
On the faculty and research machines, we have enabled /net automounting. So if your hostname is "myhost", and you NFS export the filesystem "/my/directory/" to the faculty or research machines, you will be able to automount your files by connecting to "/net/myhost/my/directory".