Difference: Automount (1 vs. 7)

Revision 72018-07-11 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 105 to 105
 

A practical example of automount

Changed:
<
<
My home directory is /a/home/tanya/seligman. Thanks to NIS,
>
>
My home directory is /nevis/tanya/home/seligman. Thanks to NIS,
 this is my home directory no matter which Linux box I'm logged into. All of my various configuration files and scripts are available in my ~seligman directory; for example, ~/.zshrc is
Line: 114 to 114
 When I get a chance to do physics, I might simulate the ATLAS liquid-argon calorimeter using Geant4. My desktop Linux box is tanya. The source code for all that work is in
Changed:
<
<
/a/home/tanya/seligman/geant4 (or ~seligman/geant4,
>
>
/nevis/tanya/home/seligman/geant4 (or ~seligman/geant4,
 or simply ~/geant4 for me).

The ATLAS workgroup server is kolya, so I store my compiled binary files and libraries in

Changed:
<
<
/a/home/kolya/seligman/g4work. That way, when my programs
>
>
/nevis/kolya/home/seligman/g4work. That way, when my programs
 execute, their physical location is on the same computer that's running the programs. I prefer to compile and execute my programs on the server kolya, which is much faster than my desktop
Line: 129 to 129
 ssh kolya "at -f ~/geant4/calo/LArHits-0.5/cmd/electron.cmd now" When I generate big ROOT Tree files or any other form of output, I can
Changed:
<
<
store them in /a/data/kolya/seligman/LArHits, which has a lot of
>
>
store them in /nevis/kolya/data/seligman/LArHits, which has a lot of
 available disk space.

Note that these directory names are the same on every system in the Linux cluster: my own desktop tanya, the server kolya, the student desktop workstation eeyore, etc. You have access to all of my work through the same directory names.

Obviously, I don't type in all these long names every time I want to change directories. If you look at ~seligman/.myprofile, you'll see aliases that I've defined for these directory names. For example:


Changed:
<
<
setenv G4WORKDIR /a/home/kolya/seligman/g4work setenv LArDataDir /a/data/kolya/seligman/LArHits
>
>
setenv G4WORKDIR /nevis/kolya/home/seligman/g4work setenv LArDataDir /nevis/kolya/data/seligman/LArHits
 

However, all this fails if tanya goes down. Then

Changed:
<
<
the /a/home/tanya directory would be inaccessible, and I'd
>
>
the /nevis/tanya/home directory would be inaccessible, and I'd
 have problems logging onto other machines in the Linux cluster. As an alternative, I could keep my home directory on the server (i.e.,
Changed:
<
<
/a/home/kolya/seligman), since if the ATLAS server goes down
>
>
//nevis/kolya/home/seligman), since if the ATLAS server goes down
 I couldn't do any analysis work anyway.

Caveat

Revision 62017-01-18 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 8 to 8
 

The naming scheme for automount directories

Changed:
<
<
This section is first because I assume most users at Nevis know what "mounting a disk" means and have a vague sense what "automount" means. This section tells you what you really want to know: how to access files on other Nevis machines just by visiting a directory. The special directory names are:

/a/home/{computer-name}

This maps to the /home directory on the named computer. For example, if you access /a/home/tanya/seligman from your computer, you will see the contents of /home/seligman on tanya.

/a/share/{computer-name}

This maps to the /share directory on the named computer. For example, if you access /a/share/amsterdam/seligman from your computer, you will see the contents of /home/seligman on amsterdam.

/a/data/{computer-name}

This maps to the /data directory on the named computer. For example, if I access /a/data/kolya/seligman from my computer, I will see the contents of /data/seligman on kolya.

Not every computer has a /data partition. If you try to access /a/data/hypatia, you'll get an error message.

/a/scratch/{computer-name}

This maps to the /scratch directory on the named computer. Typically, only the login servers have a /scratch partition.

/a/tier3/{computer-name}

This maps to the /tier3 directory on the named computer. As of May 2010, only xenia has a /tier3 partition.

/a/file

This maps to the /file directory on the archive file server. For example, if I access /a/file/d0disk/d0/steinbru from my computer, I will see the contents of /file/d0disk/d0/steinbru on archive.

This is meant to be a way for long-time users to access files that were formerly on nevis1, a central Nevis server that no longer exists.

/a/mail/inbox

This maps to the /mail/inbox directory on the mail server. See the mail-related files page for more information.

/a/mail/folders

This maps to the /mail/folders directory on the mail server. See the mail-related files page for more information.
>
>
This section is first because I assume most users at Nevis know what "mounting a disk" means and have a vague sense what "automount" means. This section tells you what you really want to know: how to access files on other Nevis machines just by visiting a directory. The special directory names are:
 
Changed:
<
<

/a/apps/local

>
>

/nevis/{computer-name}/

This is perhaps the simpler way of accessing files on another machine. For example, if you want to access the /home directory on the computer tanya, you can use the path /nevis/tanya/home.

/a/{base-directory}/{computer-name}

This maps to /{base-directory} directory on the named computer. For example, if you access /a/home/tanya/seligman from your computer, you will see the contents of /home/seligman on tanya.

This automount syntax may be a bit confusing compared to the previous one. The idea is that you can conceptually think of all home directories (for example) as being linked together by a common purpose, while the computer they're on is less important.

Some common examples of this automount path:

/a/home/{computer-name}
/a/share/{computer-name}
/a/data/{computer-name}
/a/scratch/{computer-name}
/a/tier3/xenia
/a/mail/inbox
/a/file/d0disk/d0/steinbru

There are some special cases in the above example:

/a/file

This maps to the /file directory on the archive file server. For example, if I access /a/file/d0disk/d0/steinbru from my computer, I will see the contents of /file/d0disk/d0/steinbru on archive.

This is meant to be a way for long-time users to access files that were formerly on nevis1, a central Nevis server that no longer exists.

/a/mail/inbox/$USER

This is where your mail inbox is located. See the mail-related files page for more information.

/a/mail/folders/$USER

The location of your IMAP files. See the mail-related files page for more information.

/a/apps/local

 This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to /usr/nevis on your computer, so the contents of this directory always come from the applications server.

What does it mean to mount a disk?

Changed:
<
<
Suppose you're on one computer system. You want to see files located on another computer system. You can copy files from the other system using sftp or scp, but this is inefficient. It would be easier if you could somehow "attach" the disks or directories on the remote computer to your own. Then you can access those files directly, list the contents of the directories to see if anything changed, perhaps even create new files on the remote computer.

The way a UNIX machines attaches a disk or directory on a remote computer is called NFS. The UNIX command to attach a disk is mount. The syntax for referring to a directory on a remote computer is {computer-name}:{remote-directory}. So if you wanted access to the /home disk on my computer tanya, you'd want to mount tanya:/home.

After you've mounted my disk on your computer, you need some way to refer to it. You probably don't want to call it /home, because then you wouldn't be able to refer to a /home directory that already exists on your computer. Typically you have to mount a remote directory under some other name. In this example, let's pick a "local" name for tanya:/home of /tanya/home. So the mount command would be:

>
>
Suppose you're on one computer system. You want to see files located on another computer system. You can copy files from the other system using sftp or scp, but this is inefficient. It would be easier if you could somehow "attach" the disks or directories on the remote computer to your own. Then you can access those files directly, list the contents of the directories to see if anything changed, perhaps even create new files on the remote computer.

The way a UNIX machines attaches a disk or directory on a remote computer is called NFS. The UNIX command to attach a disk is mount. The syntax for referring to a directory on a remote computer is {computer-name}:{remote-directory}. So if you wanted access to the /home disk on my computer tanya, you'd want to mount tanya:/home.

After you've mounted my disk on your computer, you need some way to refer to it. You probably don't want to call it /home, because then you wouldn't be able to refer to a /home directory that already exists on your computer. Typically you have to mount a remote directory under some other name. In this example, let's pick a "local" name for tanya:/home of /tanya/home. So the mount command would be:

 
mount tanya:/home /tanya/home
If you could execute this command, then you could cd /tanya/home and see the files in /home on tanya.
Changed:
<
<
But if you tried to execute the above command, you probably got an error message because you're not running an account with administrative privileges. Even if you were, you have to make sure to create the directory /tanya/home on your machine before you execute the mount command. Once you were through accessing the directory, you'd have to remember to unmount it. And if you had to access many directories on many computers (which is common in a cluster), you'd have to remember all these details for each directory
>
>
But if you tried to execute the above command, you probably got an error message because you're not running an account with administrative privileges. Even if you were, you have to make sure to create the directory /tanya/home on your machine before you execute the mount command. Once you were through accessing the directory, you'd have to remember to unmount it. And if you had to access many directories on many computers (which is common in a cluster), you'd have to remember all these details for each directory
 you mounted.
Changed:
<
<
As you've already guessed, automount takes care of all these details for you.
>
>
As you've already guessed, automount takes care of all these details for you.
 

What does automount do?

Line: 123 to 89
 benjamin:/mail/inbox 4.1G 3.1G 1.0G 76% /a/mail/inbox library:/usr/nevis 17G 11G 5.0G 69% /a/apps/local
Changed:
<
<
The first three filesystems are partitions on my system. The last two are directories on remote computer systems that have been mounted on tanya by automount:
>
>
The first three filesystems are partitions on my system. The last two are directories on remote computer systems that have been mounted on tanya by automount:
 
  • benjamin:/mail/inbox was mounted when my mail program accessed the file /a/mail/inbox/seligman. The directory /a/mail/inbox is monitored by automount; when I accessed a file in that directory, a directory on the mail server was mounted on my computer.
Line: 137 to 101
 
Changed:
<
<
When you do your work, you can ignore all these links. Just access a directory using the automount naming scheme and let the system take care of the links for you.
>
>
When you do your work, you can ignore all these links. Just access a directory using the automount naming scheme and let the system take care of the links for you.
 

A practical example of automount

Line: 170 to 132
 store them in /a/data/kolya/seligman/LArHits, which has a lot of available disk space.
Changed:
<
<
Note that these directory names are the same on every system in the Linux cluster: my own desktop tanya, the server kolya, Mikhail Leltchouk's desktop client anna, etc. Mikhail has access to all of my work through the same directory names.

Obviously, I don't type in all these long names every time I want to change directories. If you look at ~seligman/.myprofile, you'll see aliases that I've defined for these directory names. For example:

>
>
Note that these directory names are the same on every system in the Linux cluster: my own desktop tanya, the server kolya, the student desktop workstation eeyore, etc. You have access to all of my work through the same directory names.

Obviously, I don't type in all these long names every time I want to change directories. If you look at ~seligman/.myprofile, you'll see aliases that I've defined for these directory names. For example:

 
setenv G4WORKDIR /a/home/kolya/seligman/g4work
setenv LArDataDir /a/data/kolya/seligman/LArHits

Line: 190 to 146
 alternative, I could keep my home directory on the server (i.e., /a/home/kolya/seligman), since if the ATLAS server goes down I couldn't do any analysis work anyway.
Added:
>
>

Caveat

For you to access a given partition or disk on a remote computer, that computer has to export that directory via its NFS service. For example, you can't access /nevis/tanya/etc, because the system tanya does not export that directory for mounting by other computers.

Revision 52015-09-29 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 6 to 6
 
Deleted:
<
<

IMPORTANT

If you refer to any path that begins with the text /.automount, you are automatically doing something wrong. If you write to a systems administrator and include such a directory path in your question, you will be sent to read this page without further comment. Correct automount paths always begin with /a not /.automount; use of the latter guarantees that your task will fail.

 

The naming scheme for automount directories

This section is first because I assume most users at Nevis know what

Line: 124 to 120
 /dev/hda5 486M 190M 271M 41% / /dev/hda6 2.7G 1014M 1.6G 38% /home /dev/hda7 972M 849M 72M 92% /usr
Changed:
<
<
franklin:/mail/inbox 4.1G 3.1G 1.0G 76% /.automount/a/franklin/mail/inbox karthur:/usr/local 17G 11G 5.0G 69% /.automount/a/karthur/usr/nevis
>
>
benjamin:/mail/inbox 4.1G 3.1G 1.0G 76% /a/mail/inbox library:/usr/nevis 17G 11G 5.0G 69% /a/apps/local
  The first three filesystems are partitions on my system. The last two are directories on remote computer systems that have been mounted on tanya by automount:
Changed:
<
<
  • franklin:/mail/inbox was mounted when my mail program accessed the file /a/mail/inbox/seligman. The directory /a/mail/inbox is monitored by automount; when I accessed a file in that directory, a directory on the mail was mounted on my computer.
>
>
  • benjamin:/mail/inbox was mounted when my mail program accessed the file /a/mail/inbox/seligman. The directory /a/mail/inbox is monitored by automount; when I accessed a file in that directory, a directory on the mail server was mounted on my computer.
 
Changed:
<
<
  • karthur:/usr/nevis was mounted when my system searched the directory /usr/nevis for programs. If you're running on a system in the Linux cluster, the directory defined in ${NevisAppBase} is linked via automount to a directory on the applications server:
>
>
  • library:/usr/nevis was mounted when my system searched the directory /usr/nevis for programs. If you're running on a system in the Linux cluster, the directory defined in ${NevisAppBase} is linked via automount to a directory on the applications server:
 
# ls -ld ${NevisAppBase}

Line: 141 to 137
 
Deleted:
<
<
You'll notice that the directory under which the remote system is mounted is /.automount. This is an automount convention; you should leave this directory alone (see the warning above). If you list the name of a directory that automount monitors, you can see the link:
# ls -ld /a/mail/inbox
lrwxrwxrwx    1 root   root  34 Jul 12 11:35 /a/mail/inbox -> /.automount/a/franklin/mail/inbox
 When you do your work, you can ignore all these links. Just access a directory using the automount naming scheme and let the system take care of the links for you.

Revision 42011-07-06 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 24 to 24
 computer, you will see the contents of /home/seligman on tanya.
Added:
>
>

/a/share/{computer-name}

This maps to the /share directory on the named computer. For example, if you access /a/share/amsterdam/seligman from your computer, you will see the contents of /home/seligman on amsterdam.
 

/a/data/{computer-name}

This maps to the /data directory on the named computer. For example, if I access /a/data/kolya/seligman from my computer, I will see the
Line: 32 to 38
 Not every computer has a /data partition. If you try to access /a/data/hypatia, you'll get an error message.
Changed:
<
<

/a/work/{computer-name}

This maps to the /work directory on the named computer. Typically, only the workgroup servers have a /work partition; usually this is an additional disk that was added to the server. As of May 2010, no servers export any /work partitions.
>
>

/a/scratch/{computer-name}

This maps to the /scratch directory on the named computer. Typically, only the login servers have a /scratch partition.
 

/a/tier3/{computer-name}

This maps to the /tier3 directory on the named computer. As
Line: 47 to 51
 /a/file/d0disk/d0/steinbru from my computer, I will see the contents of /file/d0disk/d0/steinbru on archive.
Changed:
<
<
This is meant to be a way for long-time users to access files that were formerly on nevis1, a central Nevis server that no longer exists.
>
>
This is meant to be a way for long-time users to access files that were formerly on nevis1, a central Nevis server that no longer exists.
 

/a/mail/inbox

This maps to the /mail/inbox directory on the mail server. See the mail-related files page for more information.

Revision 32010-07-08 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 38 to 38
 usually this is an additional disk that was added to the server. As of May 2010, no servers export any /work partitions.
Changed:
<
<

/a/teir3/{computer-name}

This maps to the /teir3 directory on the named computer. As of May 2010, only xenia has a /teir3 partition.
>
>

/a/tier3/{computer-name}

This maps to the /tier3 directory on the named computer. As of May 2010, only xenia has a /tier3 partition.
 

/a/file

This maps to the /file directory on the archive file server. For example, if I access
Line: 58 to 58
 server. See the mail-related files page for more information.

/a/apps/local

Changed:
<
<
This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to the directory defined in ${NevisAppBase} on your computer, so the contents of this directory always come from the applications server.
>
>
This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to /usr/nevis on your computer, so the contents of this directory always come from the applications server.
 

What does it mean to mount a disk?

Revision 22010-05-21 - WilliamSeligman

Line: 1 to 1
 
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

Line: 43 to 43
 of May 2010, only xenia has a /teir3 partition.

/a/file

Changed:
<
<
This maps to the /file directory on the archive file server. For example, if I access
>
>
This maps to the /file directory on the archive file server. For example, if I access
 /a/file/d0disk/d0/steinbru from my computer, I will see the contents of /file/d0disk/d0/steinbru on archive.
Line: 58 to 58
 server. See the mail-related files page for more information.

/a/apps/local

Changed:
<
<
This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to the directory defined in ${NevisAppBase} on your computer, so the contents of this directory always come from the applications server.
>
>
This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to the directory defined in ${NevisAppBase} on your computer, so the contents of this directory always come from the applications server.
 

What does it mean to mount a disk?

Revision 12010-05-21 - WilliamSeligman

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="LinuxCluster"

Nevis Linux Cluster - Automount

This page describes how automount is used at Nevis to link systems on the cluster.

IMPORTANT

If you refer to any path that begins with the text /.automount, you are automatically doing something wrong. If you write to a systems administrator and include such a directory path in your question, you will be sent to read this page without further comment. Correct automount paths always begin with /a not /.automount; use of the latter guarantees that your task will fail.

The naming scheme for automount directories

This section is first because I assume most users at Nevis know what "mounting a disk" means and have a vague sense what "automount" means. This section tells you what you really want to know: how to access files on other Nevis machines just by visiting a directory. The special directory names are:

/a/home/{computer-name}

This maps to the /home directory on the named computer. For example, if you access /a/home/tanya/seligman from your computer, you will see the contents of /home/seligman on tanya.

/a/data/{computer-name}

This maps to the /data directory on the named computer. For example, if I access /a/data/kolya/seligman from my computer, I will see the contents of /data/seligman on kolya.

Not every computer has a /data partition. If you try to access /a/data/hypatia, you'll get an error message.

/a/work/{computer-name}

This maps to the /work directory on the named computer. Typically, only the workgroup servers have a /work partition; usually this is an additional disk that was added to the server. As of May 2010, no servers export any /work partitions.

/a/teir3/{computer-name}

This maps to the /teir3 directory on the named computer. As of May 2010, only xenia has a /teir3 partition.

/a/file

This maps to the /file directory on the archive file server. For example, if I access /a/file/d0disk/d0/steinbru from my computer, I will see the contents of /file/d0disk/d0/steinbru on archive.

This is meant to be a way for long-time users to access files that were formerly on nevis1, a central Nevis server that no longer exists.

/a/mail/inbox

This maps to the /mail/inbox directory on the mail server. See the mail-related files page for more information.

/a/mail/folders

This maps to the /mail/folders directory on the mail server. See the mail-related files page for more information.

/a/apps/local

This maps to a Nevis application directory (e.g., /usr/nevis on the applications server. This is soft-linked to the directory defined in ${NevisAppBase} on your computer, so the contents of this directory always come from the applications server.

What does it mean to mount a disk?

Suppose you're on one computer system. You want to see files located on another computer system. You can copy files from the other system using sftp or scp, but this is inefficient. It would be easier if you could somehow "attach" the disks or directories on the remote computer to your own. Then you can access those files directly, list the contents of the directories to see if anything changed, perhaps even create new files on the remote computer.

The way a UNIX machines attaches a disk or directory on a remote computer is called NFS. The UNIX command to attach a disk is mount. The syntax for referring to a directory on a remote computer is {computer-name}:{remote-directory}. So if you wanted access to the /home disk on my computer tanya, you'd want to mount tanya:/home.

After you've mounted my disk on your computer, you need some way to refer to it. You probably don't want to call it /home, because then you wouldn't be able to refer to a /home directory that already exists on your computer. Typically you have to mount a remote directory under some other name. In this example, let's pick a "local" name for tanya:/home of /tanya/home. So the mount command would be:

mount tanya:/home /tanya/home
If you could execute this command, then you could cd /tanya/home and see the files in /home on tanya.

But if you tried to execute the above command, you probably got an error message because you're not running an account with administrative privileges. Even if you were, you have to make sure to create the directory /tanya/home on your machine before you execute the mount command. Once you were through accessing the directory, you'd have to remember to unmount it. And if you had to access many directories on many computers (which is common in a cluster), you'd have to remember all these details for each directory you mounted.

As you've already guessed, automount takes care of all these details for you.

What does automount do?

The name says it all: automount is a facility to automatically mount disks. If you go to a directory that's monitored by automount, it will determine which disk on a remote computer system you wish to see and mount it for you.

The df command lists the disks that are currently available on your system. On 12-Jul-2001, I typed df -h on my computer system tanya, and this was the output:

Filesystem             Size  Used Avail Use% Mounted on
/dev/hda5              486M  190M  271M  41% /
/dev/hda6              2.7G 1014M  1.6G  38% /home
/dev/hda7              972M  849M   72M  92% /usr
franklin:/mail/inbox   4.1G  3.1G  1.0G  76% /.automount/a/franklin/mail/inbox
karthur:/usr/local      17G   11G  5.0G  69% /.automount/a/karthur/usr/nevis
The first three filesystems are partitions on my system. The last two are directories on remote computer systems that have been mounted on tanya by automount:

  • franklin:/mail/inbox was mounted when my mail program accessed the file /a/mail/inbox/seligman. The directory /a/mail/inbox is monitored by automount; when I accessed a file in that directory, a directory on the mail was mounted on my computer.

  • karthur:/usr/nevis was mounted when my system searched the directory /usr/nevis for programs. If you're running on a system in the Linux cluster, the directory defined in ${NevisAppBase} is linked via automount to a directory on the applications server:

# ls -ld ${NevisAppBase}
lrwxrwxrwx    1 root   root  13 Jun 22  2000 /usr/nevis -> /a/apps/local

You'll notice that the directory under which the remote system is mounted is /.automount. This is an automount convention; you should leave this directory alone (see the warning above). If you list the name of a directory that automount monitors, you can see the link:

# ls -ld /a/mail/inbox
lrwxrwxrwx    1 root   root  34 Jul 12 11:35 /a/mail/inbox -> /.automount/a/franklin/mail/inbox

When you do your work, you can ignore all these links. Just access a directory using the automount naming scheme and let the system take care of the links for you.

A practical example of automount

My home directory is /a/home/tanya/seligman. Thanks to NIS, this is my home directory no matter which Linux box I'm logged into. All of my various configuration files and scripts are available in my ~seligman directory; for example, ~/.zshrc is the same for me on every Linux machine.

When I get a chance to do physics, I might simulate the ATLAS liquid-argon calorimeter using Geant4. My desktop Linux box is tanya. The source code for all that work is in /a/home/tanya/seligman/geant4 (or ~seligman/geant4, or simply ~/geant4 for me).

The ATLAS workgroup server is kolya, so I store my compiled binary files and libraries in /a/home/kolya/seligman/g4work. That way, when my programs execute, their physical location is on the same computer that's running the programs. I prefer to compile and execute my programs on the server kolya, which is much faster than my desktop tanya. I can run a job by logging onto kolya, or I can run it remotely via SSH:

ssh kolya "at -f ~/geant4/calo/LArHits-0.5/cmd/electron.cmd now"
When I generate big ROOT Tree files or any other form of output, I can store them in /a/data/kolya/seligman/LArHits, which has a lot of available disk space.

Note that these directory names are the same on every system in the Linux cluster: my own desktop tanya, the server kolya, Mikhail Leltchouk's desktop client anna, etc. Mikhail has access to all of my work through the same directory names.

Obviously, I don't type in all these long names every time I want to change directories. If you look at ~seligman/.myprofile, you'll see aliases that I've defined for these directory names. For example:

setenv G4WORKDIR /a/home/kolya/seligman/g4work
setenv LArDataDir /a/data/kolya/seligman/LArHits

However, all this fails if tanya goes down. Then the /a/home/tanya directory would be inaccessible, and I'd have problems logging onto other machines in the Linux cluster. As an alternative, I could keep my home directory on the server (i.e., /a/home/kolya/seligman), since if the ATLAS server goes down I couldn't do any analysis work anyway.

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback