<para><xref linkend="dbdoclet.50438219_55923"/></para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438219_76969"/></para>
+ <para><xref linkend="dbdoclet.l_getidentity"/></para>
</listitem>
<listitem>
<para><xref linkend="dbdoclet.50438219_38274"/></para>
<title><indexterm><primary>e2scan</primary></indexterm>
e2scan</title>
<para>The e2scan utility is an ext2 file system-modified inode scan program. The e2scan program uses libext2fs to find inodes with ctime or mtime newer than a given time and prints out their pathname. Use e2scan to efficiently generate lists of files that have been modified. The e2scan tool is included in the e2fsprogs package, located at:</para>
- <para><link xl:href="http://downloads.hpdd.intel.com/public/e2fsprogs/latest/">http://downloads.hpdd.intel.com/public/e2fsprogs/latest/</link></para>
+ <para><link xl:href="http://downloads.whamcloud.com/public/e2fsprogs/latest/">http://downloads.whamcloud.com/public/e2fsprogs/latest/</link></para>
<section remap="h5">
<title>Synopsis</title>
<screen>e2scan [options] [-f file] block_device</screen>
</informaltable>
</section>
</section>
- <section xml:id="dbdoclet.50438219_76969">
+ <section xml:id="dbdoclet.l_getidentity">
<title><indexterm><primary>l_getidentity</primary></indexterm>
l_getidentity</title>
- <para>The l_getidentity utility handles Lustre user / group cache upcall.</para>
+ <para>The l_getidentity tool normally handles Lustre user/group mapping
+ upcall.</para>
<section remap="h5">
<title>Synopsis</title>
- <screen>l_getidentity ${FSNAME}-MDT{xxxx} {uid}</screen>
+ <screen>l_getidentity { $FSNAME-MDT{xxxx}| -d} {uid}</screen>
</section>
<section remap="h5">
<title>Description</title>
- <para>The group upcall file contains the path to an executable file that is invoked to resolve
- a numeric UID to a group membership list. This utility opens
- <literal>/proc/fs/lustre/mdt/${FSNAME}-MDT{xxxx}/identity_info</literal> and writes the
- related <literal>identity_downcall_data</literal> structure (see <xref
- linkend="dbdoclet.50438291_33759"/>.) The data is persisted with <literal>lctl set_param
- mdt.${FSNAME}-MDT{xxxx}.identity_info</literal>.</para>
- <para>The l_getidentity utility is the reference implementation of the user or group cache upcall.</para>
+ <para>The <literal>l_getidentity</literal> utility is called from the
+ MDS to map a numeric UID value into the list of supplementary group
+ values for that UID, and writes this into the
+ <literal>mdt.*.identity_info</literal> parameter file. The list of
+ supplementary groups is cached in the kernel to avoid repeated
+ upcalls. See <xref linkend="dbdoclet.identity_upcall"/> for more
+ details.</para>
+ <para>The <literal>l_getidentity</literal> utility can also be run
+ directly for debugging purposes to ensure that the UID mapping for a
+ particular user is configured correctly, by using the
+ <literal>-d</literal> argument instead of the MDT name.
+ </para>
</section>
<section remap="h5">
<title>Options</title>
<para><xref linkend="dbdoclet.50438219_44971"/></para>
</section>
</section>
- <section xml:id="dbdoclet.50438219_44971">
+ <section xml:id="dbdoclet.50438219_44971" condition='l28'>
<title><indexterm><primary>ll_recover_lost_found_objs</primary></indexterm>
ll_recover_lost_found_objs</title>
- <para>The ll_recover_lost_found_objs utility helps recover Lustre OST objects (file data) from a lost and found directory and return them to their correct locations.</para>
- <note>
- <para>Running the ll_recover_lost_found_objs tool is not strictly necessary to bring an OST back online, it just avoids losing access to objects that were moved to the lost and found directory due to directory corruption.</para>
+ <para>The <literal>ll_recover_lost_found_objs</literal> utility was
+ used to help recover Lustre OST objects (file data) from the
+ <literal>lost+found</literal> directory of an OST and return them to
+ their correct locations based on information stored in the
+ <literal>trusted.fid</literal> extended attribute stored on every
+ OST object containing data.</para>
+ <note condition="l26"><para>This utility is not needed with Lustre 2.6
+ and later, and is removed in Lustre 2.8 since <literal>LFSCK</literal>
+ online scanning will automatically move objects from
+ <literal>lost+found</literal> to the proper place in the OST.</para>
+ </note>
+ <note condition='l25'>
+ <para>The <literal>ll_recover_lost_found_objs</literal> tool is not
+ strictly necessary to bring an OST back online, it just avoids losing
+ access to objects that were moved to the lost+found directory due to
+ directory corruption on the OST.</para>
</note>
<section remap="h5">
<title>Synopsis</title>
<title>Description</title>
<para>The first time Lustre modifies an object, it saves the MDS inode number and the objid as an extended attribute on the object, so in case of directory corruption of the OST, it is possible to recover the objects. Running e2fsck fixes the corrupted OST directory, but it puts all of the objects into a lost and found directory, where they are inaccessible to Lustre. Use the ll_recover_lost_found_objs utility to recover all (or at least most) objects from a lost and found directory and return them to the O/0/d* directories.</para>
<para>To use ll_recover_lost_found_objs, mount the file system locally (using the <literal>-t ldiskfs</literal>, or <literal>-t zfs</literal> command), run the utility and then unmount it again. The OST must not be mounted by Lustre when ll_recover_lost_found_objs is run.</para>
- <para condition="l26">This utility is not needed for 2.6 and later,
- since the <literal>LFSCK</literal> online scanning will move objects
- from <literal>lost+found</literal> to the proper place in the OST.</para>
</section>
<section remap="h5">
<title>Options</title>
<para> <literal>user_fid2path</literal></para>
</entry>
<entry>
- <para condition='l23'>Enable FID to path translation by regular
- users. Note: This option allows a potential security hole
- because it allows regular users direct access to a file by its
- File ID, bypassing POSIX path-based permission checks which
- could otherwise prevent the user from accessing a file in a
- directory that they do not have access to. Regular permission
- checks are still performed on the file itself, so the user
- cannot access a file to which they have no access rights.
- </para>
+ <para>Enable FID-to-path translation by regular users.
+ </para>
+ <note><para>This option allows a potential security hole because
+ it allows regular users direct access to a file by its Lustre
+ File ID. This bypasses POSIX path-based permission checks,
+ and could allow the user to access a file in a directory that
+ they do not have access to. Regular POSIX file mode and ACL
+ permission checks are still performed on the file itself, so
+ users cannot access a file to which they have no permission.
+ </para></note>
</entry>
</row>
<row>
<para> <literal>nouser_fid2path</literal></para>
</entry>
<entry>
- <para condition='l23'> Disable FID to path translation by
+ <para> Disable FID to path translation by
regular users. Root and processes with
<literal>CAP_DAC_READ_SEARCH</literal> can still perform FID
to path translation.
<para>The stats-collect utility contains scripts used to collect application profiling information from Lustre clients and servers.</para>
</section>
</section>
- <section remap="h3" condition='l29'>
+ <section remap="h3" condition='l29' xml:id="SystemConfigurationUtilities.fileset">
<title><indexterm><primary>fileset</primary></indexterm>Fileset Feature</title>
<para> With the fileset feature, Lustre now provides subdirectory mount
support. Subdirectory mounts, also referred to as filesets, allow a
git://git.whamcloud.com / doc / manual.git / blobdiff