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-4477 Lustre <p>Hi,</p> <p>On a customer site we have a file system originally formatted with Lustre 2.1. On this file system several changelog users were registered, and changelogs were working fine.</p> <p>Then this file system was upgraded to 2.4. But it broke changelogs usage, as no changelog user is registered anymore. Moreover, former changelog records are unreachable.</p> <p>As noted by Aurelien Degremont in his email (<a href="https://lists.01.org/pipermail/hpdd-discuss/2014-January/000713.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.01.org/pipermail/hpdd-discuss/2014-January/000713.html</a>), it seems to be due to changes in the llog interface in 2.4 (changelog_catalog and changelog_users file are now in root MDT directory, changelog_catalogs do not point to other files in OBJECTS/ directory anymore, etc).</p> <p>We would need a method to migrate the 'changelogs configuration' from 2.1 to 2.4.</p> <p>Thanks,<br/> Sebastien.</p> LU-4477

Changelogs not working anymore after upgrading from 2.1 to 2.4

Bug Major Resolved Duplicate Lai Siyao Sebastien Buisson Mon, 13 Jan 2014 15:40:24 +0000 Fri, 14 Feb 2014 10:27:35 +0000 Thu, 13 Feb 2014 14:49:14 +0000 Lustre 2.4.1 0 7 <p>Lai</p> <p>Could you please help with this one</p> <p>Thanks</p> <p>Peter</p> <p>Firstly I tried to add compatible code in 2.4 and master to keep back-compatible, but I realised that it complicated related code, and will be used only once. So a tool to migrate as you suggested should be better. And since this is seldom used, and to not complicate the utils, IMO we can just mount mdt device as ldiskfs and migrate changelogs directly, so the steps is as follows:<br/> 1. mount -t ldiskfs &lt;mdt-device&gt; /mnt/temp<br/> 2. cat /mnt/temp/CONFIGS/changelog_catalog &gt; /mnt/temp/changelog_catalog<br/> 3. mv /mnt/temp/CONFIGS/changelog_catalog /tmp/changelog_catalog.backup<br/> 4. remount mdt device</p> <p>You can do the same for 'changelog_users', which doesn't look to be necessary, though it will be cleaner to move it out of CONFIGS directory.</p> <p>I've already tried this trick and it does not work. <br/> It seems the llog structure has been changed too and it does not find the subcatalog. After restarting the MDT, it complains that it could not find some objects for the changelog_catalog.</p> <p>I tested 2.1 -&gt; master, which works for me, I'll test 2.4 later.</p> <p>I just tested 2.1 -&gt; 2.4, which works too. Could you upload your changelog_catalog file? I can do some test locally.</p> <p>Unfortunately, I've restarted a new Changelog flow for this filesystem as I really needed it. It is difficult for me to modify it now to check this.</p> <p>When I tried the same kind of tricks you are proposing, here the error log I got:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>192:llog_cat_id2handle()) foo-MDD0000: error opening log id 0x0:123815571:fc5c411af: rc = -2 795:cat_cancel_cb()) foo-MDD0000: cannot find handle for llog 0x0:123815571: -2 </pre> </div></div> <p>But the OBJECT file is there!</p> <p>If I do</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ mount -t ldiskfs /dev/sdd /mnt/foo $ cd /mnt/foo $ printf "%x\n" 123815571 7614693 $ ls -l OBJECTS/7614693\:f5c411af -rw-rw-rw 1 root root 6929088 Dec 16 16:52 OBJECTS/7614693:f5c411af </pre> </div></div> <p>So I do not understand why MDD layer is return rc = -2.<br/> That's why I thought the OBJECTS file directory has changed too.</p> <p>I'll reproduce it tomorrow and see what happens.</p> <p>Latest 2.4 and master branch can support this trick, but 2.4.1 not, I'll see which patch is missing.</p> <p>Commit 8d306c0617a89476b24a44eb0267f33e2f971ef2 <a href="http://review.whamcloud.com/7625" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7625</a> can fix this issue, which has been landed to 2.4.2, could you try it on your system?</p> <p>duplicate of lu-3934</p> <p>Lai, we should be able to try this in 4 weeks. Systems are currently in production and we cannot test this upgrade sooner.</p> Development Rank 1|hzwcpb: Rank (Obsolete) 12261 Severity