[LU-1632] FID sequence numbers not working properly with filesystems formatted using 1.8?

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0, Lustre 2.1.4
• Affects Version/s: Lustre 2.3.0, Lustre 2.4.0, Lustre 2.1.2
• Labels: fid
• Environment: Lustre 2.1.2
• Severity: 3
• Assignee: Di Wang
• Reporter: [e-mail] (Inactive)

Description

On a 2.1 filesystem - server and client both running 2.1.2, and a filesystem created with Lustre 2.1.x, many files are created on the same client using the same FID sequence number. That's how I expect it to work.

With servers and clients running 2.1.2, but with a filesystem that was originally created with Lustre 1.8, only one file is created per sequence number before the client requests another one from the MDS. For example, for several consecutive files created on the same client, I get FIDs like this:

[0x33c0e251df8:0x1:0x0]
[0x33c0e254b37:0x1:0x0]
[0x33c0e257876:0x1:0x0]
[0x33c0e25a5b5:0x1:0x0]
[0x33c0e25d2f4:0x1:0x0]
[0x33c0e260033:0x1:0x0]

lctl get_param 'seq.cli-srv-nbp*.* shows a space of [0x0 - 0x0]:0:0 for the filesystems that were formatted under Lustre 1.8.

Is this the way it's supposed to work?

Thanks,
Jason

Issue Links

• is related to: LU-3318 mdc_set_lock_data() ASSERTION( old_inode->i_state & I_FREEING )

Comments

[Jodi Levi (Inactive)]

Landed to Master

[Di Wang]

http://review.whamcloud.com/#change,4606 patch for current master.

[Di Wang]

The patch has been landed to 2.1, and I will make a patch for 2.4 soon.

[Di Wang]

yes, 2.3 client needs this patch. hmm, the patch seems only land on 2.1 right now.

[Jay Lan (Inactive)]

I tried to forward port the 2.1 patch to 2.3, but it seems some of the routines involved got changed.

Is 2.3 client still need the patch?

[Di Wang]

DNE means Distributed NamespacE, with which you can have multiple Metadata targets, http://wiki.whamcloud.com/display/PUB/Remote+Directories+Solution+Architecture.

Yes, if you apply this patch on client side, you do not need erase the config log. it will work correctly even there are no lmv device.

[Jay Lan (Inactive)]

What is DNE?
Also, on filesystems we did not erase the config log when we upgraded and thus no lmv device. However, we will still do not see the lmv device but it would work correctly with this client side patch. Is my understanding correct? Thanks!

[Di Wang]

Yes, this patch, which is only on client side, should be enough to fix the problem. As Andreas said, LMV layer is only needed when you enable DNE on your system, which will not happen until 2.4.

[Andreas Dilger]

Jason, Di can answer authoritatively, but I believe the fix on the client should be enough to resolve the problem. The LMV layer is only needed on the client when DNE is enabled on the server. This means you have at least until 2.4 to regenerate the config.

[[e-mail] (Inactive)]

Would it be sufficient to use this patch (after it's been reviewed, of course) to fix this problem, at least until we can take the filesystem down to regenerate the client config logs? Might there be other unintended consequences of not having the lmv layer in place?

I ask because it's relatively easy to update the Lustre clients, versus taking each filesystem down.