From: Wang Shilong Date: Tue, 22 Dec 2015 13:21:15 +0000 (-0500) Subject: LUDOC-319 fileset: add fileset doc X-Git-Tag: 2.9.0~11 X-Git-Url: https://git.whamcloud.com/?a=commitdiff_plain;h=dd59ee8e44b225609725522d65e0897617617c56;p=doc%2Fmanual.git LUDOC-319 fileset: add fileset doc LU-28 introduce fileset feature, this patch try to explain how to use Fileset feature for mount utility. Lustre-change: http://review.whamcloud.com/#/c/5007/ Signed-off-by: Wang Shilong Change-Id: I872a3bfea3d6c7a2cc9050ede0a576d72993d9df Reviewed-on: http://review.whamcloud.com/17701 Tested-by: Jenkins Reviewed-by: Andreas Dilger --- diff --git a/SystemConfigurationUtilities.xml b/SystemConfigurationUtilities.xml index b3c1fc7..aac3b92 100644 --- a/SystemConfigurationUtilities.xml +++ b/SystemConfigurationUtilities.xml @@ -1833,16 +1833,19 @@ mount.lustre - mgs_nid:/fsname + mgs_nid:/fsname[/subdir]   - Mounts the Lustre file system named fsname on the client - by contacting the Management Service at mgsspec on the pathname - given by directory. The format for mgsspec - is defined below. A mounted client file system appears in fstab(5) and is usable, - like any local file system, and provides a full POSIX standard-compliant - interface. + Mounts the Lustre file system named + fsname (optionally under subdirectory + subdir if specified) on the client by + contacting the Management Service at mgsspec on + the pathname given by directory. The format + for mgsspec is defined below. A mounted client + file system appears in fstab(5) and is usable, like any local file + system, and provides a full POSIX standard-compliant interface. + @@ -2089,8 +2092,15 @@ mount.lustre
Examples - Starts a client for the Lustre file system testfs at mount point /mnt/myfilesystem. The Management Service is running on a node reachable from this client via the cfs21@tcp0 NID. - mount -t lustre cfs21@tcp0:/testfs /mnt/myfilesystem + Starts a client for the Lustre file system + chipfs at mount point + /mnt/chip. The Management Service is running on + a node reachable from this client via the cfs21@tcp0 NID. + mount -t lustre cfs21@tcp0:/chipfs /mnt/chip + Similiar to the above example, but mounting a + subdirectory under chipfs as a fileset. + mount -t lustre cfs21@tcp0:/chipfs/v1_0 /mnt/chipv1_0 + Starts the Lustre metadata target service from /dev/sda1 on mount point /mnt/test/mdt. mount -t lustre /dev/sda1 /mnt/test/mdt Starts the testfs-MDT0000 service (using the disk label), but aborts the recovery process. @@ -2705,5 +2715,78 @@ lr_reader mds@tcp0:/lustre /mnt/client lustre rw,flock 0 0
+
+ <indexterm><primary>fileset</primary></indexterm>Fileset Feature + With the fileset feature, Lustre now provides subdirectory mount + support. Subdirectory mounts, also referred to as filesets, allow a + client to mount a child directory of a parent filesystem, thereby limiting + the filesystem namespace visibility on a specific client. A common use + case is for a client to use a subdirectory mount when there is a desire to + limit the visibility of the entire filesystem namesapce to aid in the + prevention of accidental file deletions outside of the subdirectory + mount. + It is important to note that invocation of the subdirectory mount is + voluntary by the client and not does prevent access to files that are + visibile in multiple subdirectory mounts via hard links. Furthermore, it + does not prevent the client from subsequently mounting the whole file + system without a subdirectory being specified. +
+ + <indexterm> + <primary>Lustre</primary> + <secondary>fileset</secondary> + </indexterm>Lustre fileset + + + + + + Lustre file system fileset feature + + +
+
+ Examples + The following example will mount the + chipfs filesystem on client1 and create a + subdirectory v1_1 within that filesystem. Client2 + will then mount only the v1_1 subdirectory as a + fileset, thereby limiting access to anything else in the + chipfs filesystem from client2. + client1# mount -t lustre mgs@tcp:/chipfs /mnt/chip +client1# mkdir /mnt/chip/v1_1 + client2# mount -t lustre mgs@tcp:/chipfs/v1_1 /mnt/chipv1_1 + You can check the created mounts in /etc/mtab. It should look like + the following: + client1 +mds@tcp0:/chipfs/ /mnt/chip lustre rw 0 0 + +client2 +mds@tcp0:/chipfs/v1_1 /mnt/chipv1_1 lustre rw 0 0 + Create a directory under the /mnt/chip mount, and get its FID + client1# mkdir /mnt/chip/v1_2 +client1# lfs path2fid /mnt/chip/v1_2 +[0x200000400:0x2:0x0] + + If you try resolve the FID of the /mnt/chip/v1_2 + path (as created in the example above) on client2, an error will be returned + as the FID can not be resolved on client2 since it is not part of the + mounted fileset on that client. Recall that the fileset on client2 mounted + the v1_1 subdirectory beneath the top level + chipfs filesystem. + + client2# lfs fid2path /mnt/chip/v1_2 [0x200000400:0x2:0x0] +fid2path: error on FID [0x200000400:0x2:0x0]: No such file or directory + Subdirectory mounts do not have the .lustre + pseudo directory, which prevents clients from opening or accessing files + only by FID. + client1# ls /mnt/chipfs/.lustre + fid lost+found + client2# ls /mnt/chipv1_1/.lustre + ls: cannot access /mnt/chipv1_1/.lustre: No such file or directory + +
+
diff --git a/figures/fileset.png b/figures/fileset.png new file mode 100644 index 0000000..3e860cf Binary files /dev/null and b/figures/fileset.png differ