 |
 |
Renata Maria Dart wrote: > On Fri, 27 Apr 2007, Young, Charles C. wrote: > >> Hi Renata, >> >> Thanks! I have a stupid question of what is AFS and what is NFS in this context. Our work space is >> >> /afs/slac/g/atlas/work/<something> >> >> Where <something> can take you to one of several NFS servers, e.g. >> >> lrwxr-xr-x 1 YANGW root 27 Oct 18 2006 a -> /nfs/sulky51/atlaswork.u1/a/ >> lrwlrwxr-xr-x 1 gowdy root 25 Feb 13 2006 n -> /nfs/surrey14/atlas >> work/n/xr-xr-x 1 gowdy root 25 Feb 13 2006 c -> /nfs/surrey13/atlaswork/c/ >> >> Is it a worry if my batch job writes directly to one of these areas (rather than to local disk and copy at end of job)? Cheers. >> > > Hi Charlie, yes the same concerns apply to writing to nfs space. [...] BTW, this is an example where some reorganization and addition of some cloned volumes may save you a bottleneck later on. Currently, /afs/slac/g/atlas is the mount point for a 500MB RW volume and /afs/slac/g/atlas/work is the mount point for a 5GB RW volume. However, the only thing currently in /afs/slac/g/atlas/work are the one-letter symlinks to the various NFS servers hosting the actual Atlas users' work space. The path to users' work space is quite static, and ideally you'd like it to be entirely in RO, and possibly replicated, volumes. However that huge "work" volume is a tempting place to add lots of other highly volatile RW directories. A very actively written directory in this volume could slow down access to every Atlas user's work area. Moreover, it doesn't do you can't clone the work volume unless you also clone the top level g.atlas volume.