Skip to content

Update data-and-storage.md #127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lnakata wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −3
Open

Update data-and-storage.md #127

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions data-and-storage.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,11 +28,11 @@ To promote long term consistency, the S3DF directory structure provides immutabl

- Home directory permissions will be delegated to each user. By default, home folders will be readable by everyone, though you can change that by changing UNIX permissions on one or more of your folders. Everyone will be able to list `/sdf/home/<u>`.

- General purpose software will go under sw. Group specific software will go under `/sdf/group` and will be maintained by each group.
- General purpose software will go under /sdf/sw. Group specific software will go under `/sdf/group` and will be maintained by each group.

- Some groups may decide to logically hold all their information under `/sdf/group/<groupname>`. Such a structure may be implemented by each group via symlinks. The actual mount points and relative backup and archive policies will be based on the structure shown above.

?> __TODO__ Desktop/endpoint access to S3DF file systems will likely be via authenticated NFS v4. This is currently a topic of investigation as we wait for an updated WekaFS release.
?> __TODO__ Desktop/endpoint access to S3DF file systems will likely be via authenticated NFS v4. This is currently a topic of investigation for future implementation.


## Backup and Archiving
Expand All @@ -46,7 +46,7 @@ can be found at\

- The scratch spaces under `/sdf/scratch` and all directories named "nobackup" (located *anywhere* in an /sdf path) will not be backed up or archived. Please use as many "nobackup" subdirectory locations as required for any files that do not need backup. That can save significant tape and processing resources.

- A subset of users in some groups will be able to access the command line interface to HPSS for the purpose of archiving/retrieving data to/from tape. Unlike backups, which will be automatically performed by the storage team within SCS, archiving will be the responsibility of each group (contact SCS for assistance).
- Data administrators in some groups will be able to access the command line interface to HPSS for the purpose of archiving/retrieving data to/from tape. Unlike backups, which will be automatically performed by the storage team within SCS, archiving will be the responsibility of each group (contact SCS for assistance).

?> The current and target backup and archiving policies are summarized in this [reference section on data backup](reference.md#backup).

Expand Down