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-2069 Lustre <p>After upgrading our ZFS-backed servers to 2.3.51-2chaos, I'm unable to start the OST:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>LustreError: 6295:0:(fsfilt.c:122:fsfilt_get_ops()) Can't find fsfilt_osd-zfs interface LustreError: 6295:0:(filter.c:2324:filter_setup()) lstest-OST0181: filter_common_setup failed: -256. LustreError: 6295:0:(obd_config.c:572:class_setup()) setup lstest-OST0181 failed (-256) LustreError: 6295:0:(obd_config.c:1545:class_config_llog_handler()) MGC172.20.5.2@o2ib500: cfg command failed: rc = -256 Lustre: cmd=cf003 0:lstest-OST0181 1:dev 2:0 3:f LustreError: 15c-8: MGC172.20.5.2@o2ib500: The configuration from log 'lstest-OST0181' failed (-256). This may be the result of communication errors between this node and the MGS, a bad configuration, or other errors. See the syslog for more information. LustreError: 6183:0:(obd_mount.c:1212:server_start_targets()) failed to start server lstest-OST0181: -256 Lustre: lstest-OST0181: Unable to start target: -256 LustreError: 6183:0:(obd_config.c:619:class_cleanup()) Device 3 not setup Lustre: server umount lstest-OST0181 complete LustreError: 6183:0:(obd_mount.c:2332:lustre_fill_super()) Unable to mount (-256) </pre> </div></div> Lustre OSS: 2.3.51-2chaos LU-2069

Cannot start ZFS-backed OST: "Can't find fsfilt_osd-zfs interface"

Bug Major Resolved Fixed Mikhail Pershin Prakash Surya topsequoia Mon, 1 Oct 2012 21:24:11 +0000 Mon, 8 Oct 2012 01:25:32 +0000 Mon, 8 Oct 2012 01:25:32 +0000 Lustre 2.4.0 0 7 <p>This is because the code in master, unlike orion, still has the obdfilter module, in addition to the ofd module. One way to solve this (which we've done for testing on Hyperion) is to manually unload the obdfilter module, and modprobe the ofd module before mounting the OSTs. The test framework loads the modules explicitly, and has a "USE_OFD" environment variable that forces use of ofd, but that isn't helpful for direct mounting.</p> <p>I suspect it would also be possible to add something to /etc/modprobe.d/lustre.conf that would prefer installation of ofd over obdfilter, but I don't know offhand the details.</p> <p>The obdfilter module, along with its dependent code (lvfs, fsfilt, etc) will be removed from master shortly.</p> <p>Or Alex...</p> <p>Thanks, Andreas!</p> <p>Thanks for the workaround. I was able to bring up the server after a "rmmod obdfilter &amp;&amp; modprobe ofd".</p> <p>This could be fixed in a number of ways:</p> <ul class="alternate" type="square"> <li>easiest thing is to delete the obdfilter code, as soon as ofd testing is working well</li> <li>work out the recipie for /etc/modprobe.d/lustre.conf to force loading of ofd instead of ofd</li> <li>add an explicit modprobe line to mount.lustre when it detects zfs backends</li> </ul> <p>Since #1 is what we want to do anyway, I think that we should just avoid doing extra work to gracefully switch between obdfilter and ofd, and for those few sites that are testing ZFS outside of test-framework in the next week can do the explicit modprobe of ofd if needed. Also, with <a href="http://review.whamcloud.com/4148" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4148</a>, if --without-ldiskfs is given then the obdfilter code isn't built at all.</p> <p>I'm OK with that approach. Once we fix the build system it should be a non issue using the "--without-ldiskfs" option, which works for us.</p> <p>Patch 4148 landed to master</p> Development Rank 1|hzv4vb: Rank (Obsolete) 4322 Severity