dCache will use a namespace for storing filesystem information, which is independent of the local filesystem. However, to make the system more manageable, this namespace is mounted on the local machine via NFS. The mount-point is /pnfs and has the corresponding directory (/pnfs) mounted from the namespace. You may verify this with the df command:

[root@dcache-node] # df /pnfs
Filesystem           1K-blocks      Used Available Use% Mounted on
localhost:/pnfs      1099511627776      1024 1099511626752   1% /pnfs

Mounting the namespace means that you can view the file- and directory- metadata that dCache will see using standard commands, such as stat and ls. In addition, because the namespace is mounted with /pnfs as the local directory /pnfs, all absolute paths in dCache have a corresponding entry on the local filesystem. For example, to view the permissions for the directory /pnfs/fzk.de/data, the following command may be used:

[root@dcache-node] # ls -ld /pnfs/fzk.de/data
drwxr-xr-x  4 root root 512 May 23 18:04 /pnfs/fzk.de/data

An empty file may be created using the standard touch command. In the following example, a zero-length file is created, examined then removed, all using standard commands:

[root@dcache-node] # ls -l /pnfs/fzk.de/data/gks
total 0

Create an empty file
[root@dcache-node] # touch /pnfs/fzk.de/data/gks/empty-file
[root@dcache-node] # ls -l /pnfs/fzk.de/data/gks
total 0
-rw-r--r--  1 root root 0 Aug 25 18:04 empty-file
[root@dcache-node] # stat /pnfs/fzk.de/data/gks/empty-file
  File: `/pnfs/fzk.de/data/gks/empty-file'
  Size: 0               Blocks: 0          IO Block: 32768  regular empty file
Device: 12h/18d Inode: 1824520184  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-08-25 18:04:39.000000000 +0200
Modify: 2008-08-25 18:04:39.000000000 +0200
Change: 2008-08-25 18:04:39.000000000 +0200

Remove the empty file
[root@dcache-node] # rm /pnfs/fzk.de/data/gks/empty-file
rm: remove regular empty file `/pnfs/fzk.de/data/gks/empty-file'? y
[root@dcache-node] # ls -l /pnfs/fzk.de/data/gks
total 0

[root@dcache-node] # cp /bin/bash /pnfs/fzk.de/data/gks/data-1
cp: closing `/pnfs/fzk.de/data/gks/data-1': Input/output error

To test that the pools have been correctly configured, we will attempt to copy a modest sized file (the shell executable /bin/bash) from the local machine into dCache. In doing this, the data will be stored within one of the pools, a new entry in the namespace is created and the stored data is linked against this namespace entry.

Before doing this, we must ensure we can identify ourselves to the dCache instance using a grid-proxy certificate. To list the currently available grid-proxy certificates, use the voms-proxy-info command. The following output shows a typical result when no proxy certificate is available.

[user@ui-node] $ voms-proxy-info

Couldn't find a valid proxy.

To obtain a valid proxy-certificate, the voms-proxy-init command is used:

[user@ui-node] $ voms-proxy-init -voms gks
Enter GRID pass phrase:
Your identity: Your DN is here
Creating temporary proxy ................................................. Done
Contacting dgrid-voms.fzk.de:15025 [/O=GermanGrid/OU=FZK/CN=host/dgrid-voms.fzk.de] "gks" Done
Creating proxy .................................... Done
Your proxy is valid until Tue Aug 26 04:08:53 2008

Repeating the voms-proxy-info command will now provide information about the proxy certificate.

With the valid proxy certificate, data may be copied into the dCache instance using the GSIdCap protocol. The command dccp achieves this. In the following example, the file /bin/bash is copied as the file testbin-1 within the directory /pnfs/fzk.de/data/gks.

[user@ui-node] $ dccp /bin/bash gsidcap://dcache-node:22128/pnfs/fzk.de/data/gks/testbin-1

After the file has successfully completed, the file's metadata is stored in the namespace. This should be visable on the dCache node underneath the /pnfs directory:

[root@dcache-node] # stat /pnfs/fzk.de/data/gks/testbin-1
  File: `/pnfs/fzk.de/data/gks/testbin-1'
  Size: 616248          Blocks: 1204       IO Block: 32768  regular file
Device: 13h/19d Inode: 1813182462  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (609001/ UNKNOWN)   Gid: (48000/ UNKNOWN)
Access: 2008-09-01 17:37:55.000000000 +0200
Modify: 2008-09-01 17:37:55.000000000 +0200
Change: 2008-09-01 17:37:55.000000000 +0200

After copying the file back, you can check that the file has the same checksum value as the source file.

[user@ui-node] $ dccp gsidcap://dcache-node:22128/pnfs/fzk.de/data/gks/testbin-1 /tmp/test-1
[user@ui-node] $ md5sum /bin/bash /tmp/test-1
40d9419851ff06c83d161e40a7a24c3c  /bin/bash
40d9419851ff06c83d161e40a7a24c3c  /tmp/test-1

Try copying the file using GridFTP tool as testbin-2

The file may be deleted in a number of ways, the simplest is to remove the namespace entry:

[root@dcache-node] # rm /pnfs/fzk.de/data/gks/testbin-2

A file being removed from the namespace will trigger the removal of the file from whichever pool it is stored. This process is not instantaneous; under normal conditions, it may take upto a minute for the file on a pool to be removed. This delay is deliberate as it allows dCache to prioritise read operations over delete operations, so preventing file deletions from overly affecting read performance.