Re: [lustre-discuss] Can't get zfs OST to mount on a freshly built server

[Götz Waschk]

On Wed, May 13, 2015 at 4:16 PM, Bob Ball  wrote:
> OK, so, I am seeing EXACTLY the issue reported at the end of LU-6452 8
> minutes after it was closed by Andreas Dilger.
> https://jira.hpdd.intel.com/browse/LU-6452
>
> There is no response.  Is there a solution?

Hi Bob,

I guess my answer is rather for the archive. I had the same problem. I
guess this information is for paying customers only and not found in
the release notes or on Jira.

> This is Lustre 2.7.0 with (now) zfs 0.6.4.1-1, which was current when the
> server was built.  I see a number of recent Emails about updates to Lustre
> sources against this zfs version, but is there a solution for the standard
> set of 2.7.0 Lustre rpms?  Or any solution that will get me un-stuck?


Your version of zfs is too new. The binary rpms of lustre 2.7.0 are
compatible with spl/zfs 0.6.3-1.2 only:
# modinfo zfs|grep version
version:0.6.3-1.2
srcversion: 9888DC55B2F55794F6B5D44
# modinfo osd_zfs|grep version
srcversion: D9F832C8E8804F08B693280
vermagic:   2.6.32-504.8.1.el6_lustre.x86_64 SMP mod_unload modversions


Regards, Götz Waschk
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] recovery MDT ".." directory entries (LU-5626)

[Martin Hecht]

Hi,

comments inline...

On 11/04/2015 01:34 PM, Patrick Farrell wrote:
> Our observation at the time was that lfsck did not add the fid to the .. 
> dentry unless there was already space in the appropriate location.  
Ok, I might have been wrong in this point and some manual mv by the
users was involved.


On 11/04/2015 04:24 PM, Chris Hunter wrote:
> Yes I believe you want to (manually) recover the directories from
> lost+found back to ROOT on the MDT before lfsck/oi_scrub runs. I don't
> think lfsck on the MDT will impact orphan objects on the OSTs.
With lfsck phase 2 introduced in lustre 2.6 the MDT-OST consistency is
checked and repaired. Chris, you wrote that you have upgraded to "lustre
2.x", so I don't know if you have lfsck II already.  And I'm not sure if
MDT entries in lost+found are ignored by lfsck. I just wanted to point
out that you might have to be careful here, but looking at the lustre
manual it turns out that you are right. The consistency checks are run
when lfsck type is set to "layout", which is a different thing than the
"namespace" check used to update the FIDs.


On 11/05/2015 01:29 AM, Dilger, Andreas wrote:
> Note that newer versions of LFSCK namespace checking (2.6 or 2.7, don't
> recall offhand) will be able to return such entries from lost+found back
> into the proper parent directory in the namespace, assuming they were
> created under 2.x.  Lustre stores an extra "link" xattr on each inode with
> the filename and parent directory FID for each link to the file (up to the
> available xattr space for each inode), so in case of directory corruption
> it would be possible to rebuild the directory structure just from the
> "link" xattrs on each file.
that's good to know. However, the files in this case were created with
1.8, so even if the current version after the upgrade has this "link"
xattr, it doesn't help to recover from LU-5626. But your script is
useful (it's pretty much the same as I did back then, but I didn't find
my quick hack it anymore...)
 
> In the meantime, I attached a script to LU-5626 that could be used to
> re-link files from lost+found into the right directory and filename based
> on the output from e2fsck.  It is a bit rough (needs manual editing of
> pathnames), but may be useful if someone has hit this problem.

best regards,
Martin



smime.p7s
Description: S/MIME Cryptographic Signature
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org