https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1861 Lustre <p>This issue was created by maloo for Andreas Dilger &lt;adilger@whamcloud.com&gt;</p> <p>This issue relates to the following test suite run: <a href="https://maloo.whamcloud.com/test_sets/8b92f800-f77c-11e1-8b95-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/8b92f800-f77c-11e1-8b95-52540035b04c</a>.</p> <p>It seems that when e2fsck is run against an MDT that the file type of the files/directories/objects is not being set in the directory entry. This causes e2fsck to complain about every inode in the filesystem because the ldiskfs_dir_entry_2-&gt;file_type is being left unset.</p> <p>The sub-test test_8 failed with the following error in the test log:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Setting filetype for entry 'last_rcvd' in / (2) to 1. Setting filetype for entry 'fld' in / (2) to 1. Setting filetype for entry 'seq_ctl' in / (2) to 1. Setting filetype for entry 'seq_srv' in / (2) to 1. Setting filetype for entry 'capa_keys' in / (2) to 1. Setting filetype for entry 'ROOT' in / (2) to 2. Setting filetype for entry 'lov_objid' in / (2) to 1. Setting filetype for entry 'CATALOGS' in / (2) to 1. Setting filetype for entry '1' in /O/1/d1 (524327) to 1. Setting filetype for entry '2' in /O/1/d2 (524328) to 1. Setting filetype for entry '3' in /O/1/d3 (524329) to 1. Setting filetype for entry '4' in /O/1/d4 (524330) to 1. : : </pre> </div></div> LU-1861

osd-ldiskfs doesn't set object file type

Bug Blocker Resolved Fixed Mikhail Pershin Maloo Fri, 7 Sep 2012 18:02:47 +0000 Thu, 13 Dec 2012 12:49:40 +0000 Thu, 13 Dec 2012 12:49:40 +0000 Lustre 2.4.0 Lustre 2.4.0 0 7 <p>These files are not looking as OST files but MDS. Files in O/1/d&lt;n&gt; are llogs.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CMD: client-24vm3 umount -d /mnt/mds1 CMD: client-24vm3 e2fsck -fy /dev/lvm-MDS/P1 client-24vm3: e2fsck 1.42.3.wc3 (15-Aug-2012) </pre> </div></div> <p>Right, client-24vm3 is MDS. So bug is related to old master code. I am sure it is fixed in orion already.</p> <p>I just hit this in a new test on a newly-formatted MDT filesystem right after <tt>llmount.sh; llumount.sh</tt>. Note that it is not ALL of the files that are reporting problems, it seems only a subset of directory entries are missing the file type. Below is a full list on a newly-formatted and mounted filesystem:</p> <p><tt>noformat</tt><br/> e2fsck -f /dev/vg_sookie/lvmdt1 <br/> e2fsck 1.42.5.wc3 (15-Sep-2012)<br/> Pass 1: Checking inodes, blocks, and sizes<br/> Pass 2: Checking directory structure<br/> Setting filetype for entry 'last_rcvd' in / (2) to 1.<br/> Setting filetype for entry 'fld' in / (2) to 1.<br/> Setting filetype for entry 'seq_ctl' in / (2) to 1.<br/> Setting filetype for entry 'seq_srv' in / (2) to 1.<br/> Setting filetype for entry 'lov_objid' in / (2) to 1.<br/> Setting filetype for entry 'CATALOGS' in / (2) to 1.<br/> Setting filetype for entry '1' in /O/1/d1 (25027) to 1.<br/> Setting filetype for entry '2' in /O/1/d2 (25028) to 1.<br/> Setting filetype for entry '3' in /O/1/d3 (25029) to 1.<br/> Setting filetype for entry '4' in /O/1/d4 (50011) to 1.<br/> Setting filetype for entry '5' in /O/1/d5 (50012) to 1.<br/> Setting filetype for entry '6' in /O/1/d6 (50013) to 1.<br/> Setting filetype for entry '7' in /O/1/d7 (50014) to 1.<br/> Setting filetype for entry '8' in /O/1/d8 (50015) to 1.<br/> Setting filetype for entry '9' in /O/1/d9 (50016) to 1.<br/> Setting filetype for entry '10' in /O/1/d10 (50017) to 1.<br/> Setting filetype for entry '12' in /O/1/d12 (50019) to 1.<br/> Setting filetype for entry '14' in /O/1/d14 (50021) to 1.<br/> Pass 3: Checking directory connectivity<br/> Pass 4: Checking reference counts<br/> Pass 5: Checking group summary information</p> <p>testfs-MDT0000: ***** FILE SYSTEM WAS MODIFIED *****<br/> testfs-MDT0000: 209/100000 files (1.4% non-contiguous), 16988/50000 blocks<br/> <tt>noformat</tt></p> <p>I'm surprised that there are llogs already on a newly-formatted filesystem? It hasn't even done anything yet.</p> <p>Thanks for checking that, I will investigate that</p> <p>See this also on the OST though:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>testfs-OST0000: recovering journal Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Setting filetype for entry 'last_rcvd' in / (2) to 1. Setting filetype for entry 'health_check' in / (2) to 1. Setting filetype for entry 'LAST_GROUP' in / (2) to 1. Setting filetype for entry 'LAST_ID' in /O/0 (80) to 1. Setting filetype for entry '96' in /O/0/d0 (81) to 1. Setting filetype for entry '1' in /O/0/d1 (82) to 1. Setting filetype for entry '97' in /O/0/d1 (82) to 1. Setting filetype for entry '2' in /O/0/d2 (83) to 1. : : </pre> </div></div> <p>it's a bit strange this do not happen to MDS ? e.g. sanity/17m does not complain.</p> <p>I see this with test_17m regularly in my local testing. Note that test_17m is relatively new, and the original test failure predates when it was added.</p> <p>e2fsck complains about file_type in ldiskfs directory entry, which is not set properly by osd_compat_add_entry(), in fact it is not set at all.<br/> I am working on patch, the easiest way could be just set regular type unconditionally there, because all compatibility entries are regular files.</p> <p><a href="http://review.whamcloud.com/#change,4669" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,4669</a></p> <p>Landed for 2.4</p> Development Rank 1|hzv30f: Rank (Obsolete) 3987 Severity