Afternoon

We have copied off all the files from an OST (lfs find identifies no files
on the OST) but the OST still has some left over files

eg.

    9.6G O/0/d22/1277942

when I get the FID of this file using zfsobj2fid it appears to get a
corrupt FID

    [0x200000a48:0x1e86e:0x1]

which then returns

bad FID format '[0x200000a48:0x1e86e:0x1]', should be [seq:oid:ver] (e.g.
[0x200000400:0x2:0x0])

fid2path: error on FID [0x200000a48:0x1e86e:0x1]: Invalid argument

when I check it with lfs fid2path

WTF?

Checking a few OST's this isn't isolated.  I've seen a few different
corruptions eg.

    [0x200000a48:0x1e86e:0x7]
    [0x200000a48:0x1e684:0x3]


Extra, quite a file files under the O/0/ directory didn't have trusted.fid
set... which seemed strange.

So a few questions.

    How did this file get orphaned?
    How did the FID type get corrupt?




I had to modify zfsobj2fid  to work with a mounted snapshot of the ZFS
volume

    # diff ../zfsobj2fid /sbin/zfsobj2fid
38c38
<     p = subprocess.Popen(["zdb", "-O", "-vvv", sys.argv[1], sys.argv[2]],
---
>     p = subprocess.Popen(["zdb", "-e", "-vvv", sys.argv[1], sys.argv[2]],




zfs: 0.7.5-1
lustre: 2.10.3



Stu.


-- 
Dr Stuart Midgley
sdm...@gmail.com
_______________________________________________
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Reply via email to