<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>
<tbody>
<row>
<entry>
- <para> <literal>network up|down|tcp|elan|myrinet</literal></para>
+ <para> <literal>network up|down|tcp|elan</literal></para>
</entry>
<entry>
<para> Starts or stops LNet, or selects a network type for other <literal>lctl</literal> LNet commands.</para>
<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.
git://git.whamcloud.com / doc / manual.git / blobdiff