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-2901 Lustre <p>We meet 3 times on 3 differents lustre MDS ldiskfs filesystem<br/> a duplicate name file on a directory, for example:</p> <p>2012 Dec 4 10:59:22 bigfoot2 :</p> <p>cdep4-MDT0000 Starting fsck<br/> cdep4-MDT0000 Pass 1: Checking inodes, blocks, and sizes<br/> cdep4-MDT0000 Pass 2: Checking directory structure<br/> cdep4-MDT0000 Duplicate entry 'BDE_UCD.00000-00001' found.<br/> cdep4-MDT0000 Marking /ROOT/yack/group/USER/test9 (836767265) to be rebuilt.<br/> cdep4-MDT0000<br/> cdep4-MDT0000 Duplicate entry 'BDE_UCD.00000-00001' found.<br/> cdep4-MDT0000 Marking /ROOT/yack/group/USER/test9_pscc (838872002) to be rebuilt.<br/> cdep4-MDT0000<br/> cdep4-MDT0000 Pass 3: Checking directory connectivity<br/> cdep4-MDT0000 Pass 3A: optimizing directories<br/> cdep4-MDT0000 Entry 'BDE_UCD.00000-00001' in /ROOT/yack/group/USER/test9 (836767265) has a non-unique filename.<br/> cdep4-MDT0000 Rename to BDE_UCD.00000-0000~0? yes<br/> cdep4-MDT0000<br/> cdep4-MDT0000 Entry 'BDE_UCD.00000-00001' in /ROOT/yack/group/USER/test9_pscc (838872002) has a non-unique filename.<br/> cdep4-MDT0000 Rename to BDE_UCD.00000-0000~0? yes<br/> cdep4-MDT0000<br/> cdep4-MDT0000 Pass 4: Checking reference counts <br/> cdep4-MDT0000 Pass 5: Checking group summary information<br/> cdep4-MDT0000<br/> cdep4-MDT0000: ***** FILE SYSTEM WAS MODIFIED *****<br/> cdep4-MDT0000: 2872950/878051328 files (0.8% non-contiguous), 111956436/878047232 blocks</p> <p>In this case, running the ls command we can see the issue:</p> <p>total 0<br/> Fri Nov 30 16:20:22 + 0.00 ###############################################################################<br/> Fri Nov 30 16:20:22 + 0.00 ## Contenu du repertoire cache_dep /cea/cache_dep/yack/group/USER/test9_ ##<br/> Fri Nov 30 16:20:22 + 0.00 ## pscc ##<br/> Fri Nov 30 16:20:22 + 0.00 ###############################################################################<br/> total 331844<br/> <del>rw-r</del><del>r</del>- 1 USER f7 10240 Nov 30 16:19 BDE_DIVERS<br/> <del>rw-r</del>---- 1 USER f7 140615680 Nov 30 16:09 BDE_MAILLAGE<br/> <del>rw-r</del><del>r</del>- 1 USER f7 10240 Nov 30 16:20 BDE_POST1D<br/> <del>rw-r</del><del>r</del>- 1 USER f7 99563008 Nov 30 16:16 BDE_UCD.00000-00001<br/> <del>rw-r</del><del>r</del>- 1 USER f7 99563008 Nov 30 16:16 BDE_UCD.00000-00001</p> <p>Then running debugfs after the fsck we can see that both 2 files<br/> exist on 2 different inodes:</p> <p><span class="error">&#91;root@bigfoot2 ~&#93;</span># /usr/lib/lustre/debugfs /dev/mapper/da1vg0_mdt<br/> debugfs 1.42.3.wc3 (15-Aug-2012)<br/> debugfs: ls<br/> 2 (12) . 2 (12) .. 11 (20) lost+found 589299713 (16) CONFIGS<br/> 637534209 (16) OBJECTS 12 (20) lov_objid 13 (16) oi.16<br/> 14 (12) fld 15 (16) seq_srv 16 (16) seq_ctl 17 (20) capa_keys<br/> 627048449 (16) PENDING 643825665 (12) ROOT 18 (20) last_rcvd<br/> 700448769 (20) REM_OBJ_DIR 19 (3852) CATALOGS<br/> debugfs: cd ROOT/yack/group/USER<br/> debugfs: cd test9_pscc<br/> debugfs: ls<br/> 838872002 (28) . 643826507 (28) ..<br/> 838873362 (28) BDE_UCD.00000-0000~0 838875198 (48) BDE_UCD.00000-00001<br/> 838875615 (36) BDE_POST1D 838877439 (40) BDE_MAILLAGE<br/> 838877482 (36) BDE_DIVERS 838877492 (3852) BDE_PROT_LAG.00001-00001<br/> debugfs: <br/> debugfs: stat BDE_UCD.00000-0000~0<br/> Inode: 838873362 Type: regular Mode: 0644 Flags: 0x0<br/> Generation: 2475899703 Version: 0x0000002b:1ecd9699<br/> User: 3083 Group: 5214 Size: 0<br/> File ACL: 0 Directory ACL: 0<br/> Links: 1 Blockcount: 0<br/> Fragment: Address: 0 Number: 0 Size: 0<br/> ctime: 0x50b8cde4:00000000 &#8211; Fri Nov 30 16:16:52 2012<br/> atime: 0x50bf189a:00000000 &#8211; Wed Dec 5 10:49:14 2012<br/> mtime: 0x50b8cde4:00000000 &#8211; Fri Nov 30 16:16:52 2012<br/> crtime: 0x50b8cc66:aa4a5734 &#8211; Fri Nov 30 16:10:30 2012<br/> Size of extra inode fields: 28<br/> Extended attributes stored in inode body:<br/> lma = "00 00 00 00 00 00 00 00 71 be 71 17 02 00 00 00 4b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br/> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0<br/> 0 00 00 00 00 " (64)<br/> lma: fid=<span class="error">&#91;0x21771be71:0x4b:0x0&#93;</span><br/> lov = "d0 0b d1 0b 01 00 00 00 4b 00 00 00 00 00 00 00 71 be 71 17 02 00 00 00 00 00 40 00 03 00 00 00 99 9f<br/> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13 00 00 00 18 ad 00 0<br/> 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 02 00 00 c9 af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br/> 00 00 53 02 00 00 " (104)<br/> link = "df f1 ea 11 01 00 00 00 3d 00 00 00 00 00 00 00 39 41 6c 65 70 68 6f 4d 00 25 00 00 00 02 17 59 a0 d1<br/> 00 00 34 fb 00 00 00 00 42 44 45 5f 55 43 44 2e 30 30 30 30 30 2d 30 30 30<br/> 30 31 " (61)<br/> BLOCKS:</p> <p>debugfs: stat BDE_UCD.00000-00001<br/> Inode: 838875198 Type: regular Mode: 0644 Flags: 0x0<br/> Generation: 2475897856 Version: 0x0000002b:1ec71356<br/> User: 3083 Group: 5214 Size: 0<br/> File ACL: 0 Directory ACL: 0<br/> Links: 1 Blockcount: 0<br/> Fragment: Address: 0 Number: 0 Size: 0<br/> ctime: 0x50b8c8fd:00000000 &#8211; Fri Nov 30 15:55:57 2012<br/> atime: 0x50bf18a0:00000000 &#8211; Wed Dec 5 10:49:20 2012<br/> mtime: 0x50b8c8fd:00000000 &#8211; Fri Nov 30 15:55:57 2012<br/> crtime: 0x50b8c6c2:977f5a84 &#8211; Fri Nov 30 15:46:26 2012<br/> Size of extra inode fields: 28<br/> Extended attributes stored in inode body:<br/> lma = "00 00 00 00 00 00 00 00 ef 0a 4f 17 02 00 00 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br/> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0<br/> 0 00 00 00 00 " (64)<br/> lma: fid=<span class="error">&#91;0x2174f0aef:0x52:0x0&#93;</span><br/> lov = "d0 0b d1 0b 01 00 00 00 52 00 00 00 00 00 00 00 ef 0a 4f 17 02 00 00 00 00 00 40 00 03 00 00 00 59 27<br/> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c2 00 00 00 9b a6 00 0<br/> 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9 01 00 00 08 ac 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br/> 00 00 db 02 00 00 " (104)<br/> link = "df f1 ea 11 01 00 00 00 3d 00 00 00 00 00 00 00 39 41 6c 65 70 68 6f 4d 00 25 00 00 00 02 17 59 a0 d1<br/> 00 00 34 fb 00 00 00 00 42 44 45 5f 55 43 44 2e 30 30 30 30 30 2d 30 30 30<br/> 30 31 " (61)<br/> BLOCKS:</p> <p>Another trace can be found attached to this ticket.</p> <p>Is this a known issue?</p> LU-2901

Duplicate filename on the same ldiskfs directory on MDS

Bug Critical Resolved Fixed Lai Siyao Diego Moreno Mon, 4 Mar 2013 11:51:06 +0000 Tue, 20 Aug 2013 05:59:06 +0000 Tue, 20 Aug 2013 05:59:06 +0000 Lustre 2.3.0 Lustre 2.1.3 Lustre 2.1.6 Lustre 2.4.1 Lustre 2.1.6 Lustre 2.4.1 Lustre 2.5.0 0 21 <p>Lai</p> <p>Could you please comment on this one?</p> <p>Thanks</p> <p>Peter</p> <p>My understanding of this issue is:</p> <ul> <li>fsck found two dir entries with the same name, and renamed the second to a unique name.</li> <li>however `ls &lt;dir&gt;` still lists two files with the same name, and the file with the unique name is not shown. Could you confirm whether this is done on MDS (mount device with 'ldiskfs') or on client? BTW could you `ls -i ...` to list ino for all files also?</li> <li>while debugfs MDS device can see the correct result (fixed by fsck).</li> </ul> <p>Please correct me if I misunderstood, thanks.</p> <p>Could you list the version of e2fsprogs on your system?</p> <p>Do you know how file 'BDE_UCD.00000-00001' is created? What operations has been done on this file? Is it created multiple times?</p> <p>The e2fsprogs version is: 1.42.3.wc3. This issue is difficult to reproduce/trace as it raises up from time to time and it's only detected when lfsck is run once a month. It comes from an internal IO library doing lots of IOs.</p> <p>From my understanding lfsck is fine and the issue is as follows:</p> <ul class="alternate" type="square"> <li>On a periodic lfsck run we see there is a duplicate filename entry. We cancel the lfsck doing nothing.</li> <li>Then from a Lustre client, doing 'ls', we obviously see the same filename twice (lfsck is right!).</li> <li>We re-run lfsck renaming one of the duplicate filenames.</li> <li>Everything is fine again as there's no more duplicate filenames.</li> </ul> <p>The question is: how could a duplicate filename arrive?</p> <p>I forgot to mention that both files have the same name and size but different attributes (ctime, mtime) and fid.</p> <p>One possible cause is that on the second create, it fails to lookup by filename, so that file with the same name is created twice. But it's weird that this happens with the same name 'BDE_UCD.00000-00001' on two different directories: 'test9' and 'test9_pscc'. I've tested with the same directory structure, but nothing went wrong.</p> <p>I'll see is it possible to make a debug patch to catch such case, and print message when it happens.</p> <p>I'm afraid this is not a lustre specific bug, because even lustre code forgets check duplicate dir entry before inserting, ldiskfs (ext4) will complain and refuse insertion. And I can't think of a way to catch such error in lustre code.</p> <p>BTW in the attached trace file, I see such log messages:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2013/01/18 15:16:56 rbh-sherpa@yack40[8625/11]: SHERPA | GC of dep files disabled: not removing /cea/cache_dep/rep1/rep2/rep3/rep4/HDep-n=Temps_u=s.v=f0000000000000000-v=f3fcc4db02b7a7355 2013/01/18 23:52:58 rbh-sherpa@yack40[8625/9]: SHERPA | GC of dep files disabled: not removing /cea/cache_dep/rep1/rep2/rep3/rep4/HDep-n=Temps_u=s.v=f0000000000000000-v=f3fcc4db02b7a7355 </pre> </div></div> <p>Could you explain the meaning of this message?</p> <p>Hi Lai,</p> <p>One of our customers recently hit this bug as well. Unfortunately it is a secure site, so getting information is difficult. I thought perhaps it could have been a problem with the journal getting incorrectly replayed, but they have not had any reboots. We thought that perhaps the file had been created with an unprintable character in the name, but that is not the case. Hexdumps of the names are identical. </p> <p>ls -i shows both files, but has the same inode number. I think this is because it does an lstat by name. We printed out the dirents and those showed both files with different inode numbers. </p> <p>The duplicate files still exist. Is there anything else we can look at before we delete the hidden one? I have asked for more details as to how the file is created, or if they can reproduce it, but I'm not sure that it will be possible. </p> <p>Do you have any suggestions as to how to proceed? We are running Lustre 2.1.2.</p> <p>Thanks.</p> <p>Andreas, could you take a look and give some suggestion?</p> <p>I was able to reproduce it on a single client (which was also the MDT) using a modified version of the reproducer in <a href="https://jira.whamcloud.com/browse/LU-3439" title="User code creating multiple lockfiles with same name" class="issue-link" data-issue-key="LU-3439"><del>LU-3439</del></a>. I used the debug daemon to get full debugging information and have attached it to the ticket, along with the reproducer and debugfs stats of the two files with the same filename.</p> <p>Thanks.</p> <p>err I can't attach it, it's 20MB, but here is a link:<br/> <a href="https://woscloud.corp.ddn.com/v2/files/L2YwMWU5NWI5ZGViNGRjOThiMmUxMWZmZGMyMzFiYjE0NQ==/content/inline/lu-2901.tgz" class="external-link" target="_blank" rel="nofollow noopener">https://woscloud.corp.ddn.com/v2/files/L2YwMWU5NWI5ZGViNGRjOThiMmUxMWZmZGMyMzFiYjE0NQ==/content/inline/lu-2901.tgz</a></p> <p>Hi Lai,</p> <p>I think you meant to respond to this LU, so I am posting here. </p> <p>Here is what my directory looks like:<br/> ---------- 1 root root 5 Jun 5 09:31 test_file<br/> ---------- 1 root root 5 Jun 5 09:31 test_file</p> <p>with -i:<br/> 144115205322835997 ---------- 1 root root 5 Jun 5 09:31 test_file<br/> 144115205322835997 ---------- 1 root root 5 Jun 5 09:31 test_file</p> <p>Using debugfs on the MDT I can see that there is one with inode 45 and one with inode 25, the stat for them should both be in the tarball. </p> <p>To reproduce it I ran:<br/> rm * -f ; for x in `seq 1 8`; do ~/test &amp; done</p> <p>until I saw two files named test_file (or it ran out of files), and then I ran killall test.</p> <p>I wasn't sure if the files needed to be kept open to reproduce it. I just now reproduced it after adding close(fd) to the main loop, so it seems as if it's not necessary. </p> <p>I also modified the main loop to end after a certain number of iterations. I could reproduce it if the loop was run more than 1x, but not if it was only run once. </p> <p>Attached is an updated and improved version of the test, named duplicate_name.c.</p> <p>It seems that the race is only in the first time this link tries to be created, and all of the other loops are useless.</p> <p>I suspect the problem is some kind of locking problem (maybe pdirops?) during <tt>link()</tt> on the MDT not grabbing the right lock on the "test_file" name/hash properly. The original file can be created due to its unique name, then <tt>link()</tt> succeeds in linking to "test_file" in a few cases if there was a racy lookup on the client?</p> <p>Like Kit, I'm running this like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>rm $DIR/test_file*; for X in $(seq 8); do ./duplicate_name $DIR &amp; done; wait; ls $DIR </pre> </div></div> <p>The updated test exits immediately if it was able to create the link, and the remaining runs also exit after 10 loops. I'm able to reproduce this 100% of the time on master, sometimes getting as many as 4 links with the same name. It also works if the <tt>open(), write(), fchmod(), close()</tt> calls are removed, leaving only the <tt>link()</tt> call, and can be reproduced with only 2 threads (though not 100% of the time).</p> <p>I'm attaching a full debug log from a two-thread run, which has also been patched to change LDLM_DEBUG() to print the lock resources in a format similar to DFID so they are easier to find in the logs and also include the the name hash.</p> <p>I suspect the problem to be in pdirops, or the MDT's usage of it in link, since normal ext4 wouldn't ever allow this I think.</p> <p>Full debug log with improved LDLM_DEBUG() messages.</p> <p>Liang has confirmed that pdirops is firstly included from 2.3, and this is can be reproduced on 2.1, pdirops is not the culprit.</p> <p>I think I have understood what is happening here. The link handling in the MDT is fundamentally unsafe, because it is never checking whether the target name already exists or not. <tt>mdt_reint_link()</tt> is correctly looking up and locking the parent object and name hash, looking up and locking the source object, and calling the <tt>mdd_link()<del>&gt;...osd_index_ea_insert()</del>&gt;...ldiskfs_add_entry()</tt> but in ldiskfs there is no guarantee that the name being inserted is unique.</p> <p>The ldiskfs code depends on the original caller (normally the VFS) to have done a lookup and return <tt>-EEXIST</tt> in case of an existing target. It happens that <tt>add_dirent_to_buf()</tt> does return <tt>-EEXIST</tt> if it happens to find the name in the leaf block it is traversing to find an empty slot for the dirent, but if the name is <em>after</em> an empty slot large enough to hold the dirent this will not happen. In the current test case, the original name of the source file is <tt>test_file_XXXXXX</tt> and this longer name is unlinked by the first thread doing the <tt>link("test_name")</tt> operation. That leaves an empty slot in the directory leaf block large enough for the second thread to also insert <tt>"test_name"</tt> into the directory. The locking of the directory is not enough, since the name is not revalidated under the lock.</p> <p>Alex, I'm not sure at which level the name to be inserted should be checked? Is this something that should be handled at the MDD layer, or the OSD layer? It looks like ZFS is already checking that the name being inserted into the directory ZAP is unique, and this is also common for e.g. databases to allow checking that the inserted key is unique, so it makes sense that this be handled inside osd-ldiskfs. The <tt>add_dirent_to_buf()</tt> code is already doing this for some of the cases, but I am reluctant to patch ext4 further in this area. I'm also aware that you don't like extra "unnecessary" checks at the OSD level for operations that should be verified at the higher layers, so please provide some input on where you think this should be checked.</p> <p>I've pushed two patches for this bug.</p> <p><a href="http://review.whamcloud.com/6591" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6591</a><br/> A new sanity.sh test_31o case which can reproduce the problem. It is just a shell script, no need for a separate program. It reproduces 100% on ldiskfs with 8 threads, and not in several hundred runs on ZFS, which bears out the above analysis. It should be used as the basis for any fix, though the test case needs to be excluded when run against older server versions, like below (I didn't include this into the current test case so that it would run when developing the fix):</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">if</span> [ $(lustre_version_code $SINGLEMDS) -lt $(version_code 2.1.6) ] || [ $(lustre_version_code $SINGLEMDS) -ge $(version_code 2.2.0) -a $(lustre_version_code $SINGLEMDS) -lt $(version_code 2.4.1) ]; then skip <span class="code-quote">"Need MDS version at least 2.1.6 or 2.4.1"</span> <span class="code-keyword">return</span> 0 fi </pre> </div></div> <p><a href="http://review.whamcloud.com/6592" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6592</a><br/> The second patch cleans up the rest of the code to use the new DLDLMRES/PLDLMRES macros when printing out resource names, so that they appear in messages and logs in a consistent format. This also exposed a bug in the ll_md_blocking_ast() callback, which has been around since <a href="http://review.whamcloud.com/2271" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/2271</a> landed (<a href="https://jira.whamcloud.com/browse/LU-1198" title="Change DLM lock encoding to put FID version into lock res[1]" class="issue-link" data-issue-key="LU-1198"><del>LU-1198</del></a>), but is "not a bug yet" because it only affects unused fields in the FID and DLM resource so I didn't split it into a separate commit.</p> <p>VFS actually checks target for link: sys_linkat -&gt; lookup_create. But lustre client ll_lookup_nd(O_CREATE &amp;&amp; !O_OPEN) doesn't really lookup on server, but create a temp dentry and return, and let the real operation, eg. link/mknod later to check error like -EEXIST. But unfortunately MDS doesn't check this for link.</p> <p>Alex, I'm not sure at which level the name to be inserted should be checked? Is this something that should be handled at the MDD layer, or the OSD layer? It looks like ZFS is already checking that the name being inserted into the directory ZAP is unique, and this is also common for e.g. databases to allow checking that the inserted key is unique, so it makes sense that this be handled inside osd-ldiskfs. The add_dirent_to_buf() code is already doing this for some of the cases, but I am reluctant to patch ext4 further in this area. I'm also aware that you don't like extra "unnecessary" checks at the OSD level for operations that should be verified at the higher layers, so please provide some input on where you think this should be checked.</p> <p>yes, I agree it's better to be done in OSD, especially given ldiskfs does this partially. we were going to introduce -&gt;update() which would make -&gt;insert() returning -EEXIST well justified?</p> <p>hmm, if we just add yet another lookup in -&gt;insert(), then mdd_create() will be doing two lookups and that should affect performance?</p> <p>Yes, I was wondering about this also. At one point I thought it was just a dcache lookup, but it seems the dentry being used is totally fake.</p> <p>The most efficient way to do this would be to just scan the whole ldiskfs leaf block when doing the insert, since add_dirent_to_buf() is already scanning it looking for free space. It is most likely going to scan most of the used part of the block anyway, so this would add relatively little overhead. It would be good to structure this change so it is only done if being called by Lustre (e.g. if ldiskfs_dentry_param is passed). That gives us some hope of having it accepted upstream.</p> <p>probably we'd have to scan more than 1 block if they share same hash value? should happen too rare to affect performance though.</p> <p>IMHO a one-line check before mdo_link() in mdt_reint_link() could fix this: check return value of mdt_lookup_version_check() for target is -ENOENT, otherwise -EEXIST is returned. (it's the same as mdt_md_create()).</p> <p>Now this check is only missing for link operation, if this check should only be done in ldiskfs, other operations should follow this rule too.</p> <p>I updated the patch of <a href="http://review.whamcloud.com/#change,6591" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,6591</a> with the way I described above.</p> <p>back port to b2_1:<br/> <a href="http://review.whamcloud.com/#/c/6678" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6678</a></p> <p>This back port leaves out the first 2 files from the original patch as advised by Oleg.</p> <p>Hi,</p> <p>I think we need clarification regarding the various patches proposed in here. If I understand correctly, we have:</p> <ul class="alternate" type="square"> <li><a href="http://review.whamcloud.com/6591" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6591</a> : patch for master, adds a new test in sanity;</li> <li><a href="http://review.whamcloud.com/6592" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6592</a> : patch for master, code cleanup;</li> <li><a href="http://review.whamcloud.com/6678" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6678</a> : patch for b2_1, port of <a href="http://review.whamcloud.com/6591" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6591</a>.</li> </ul> <p>Does it mean that the patch that really fixes the issue is missing in b2_1?</p> <p>Thanks in advance,<br/> Sebastien.</p> <p>Sebastian,<br/> The 2nd patch in master, #6592, only changes log and error messages. It uses new macros that were defined in the master version of the first patch but were left out of the b2_1 back port. This makes it hard to back port the 2nd patch.</p> <p>Only the first patch, #6591, contains actual functional fixes so that was all that was back ported.</p> <p>Thanks for the clarification, Bob!</p> <p>backports to b2_4:<br/> <a href="http://review.whamcloud.com/7315" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7315</a><br/> <a href="http://review.whamcloud.com/7316" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7316</a></p> <p>Seems fixes have landed where needed</p> Related LU-3439 Development Rank 1|hzvk53: Rank (Obsolete) 6988 Severity