[LU-2580] cp with FIEMAP support creates completely sparse file

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Affects Version/s: Lustre 2.3.0, Lustre 2.4.0
• Labels: LB
• Environment: SLES 11 SP2 (client), Lustre 2.1.2 RHEL6 (server)
• Severity: 2
• Assignee: Peter Jones
• Reporter: Kit Westneat (Inactive)

Description

We are seeing an issue at KIT where cp will occasionally use the FIEMAP extension to create a completely sparse file instead of actually copying the file. It seems to occur under a workload involving creating and deleting many files at once. It only involves a single client though, it's not a parallel workload.

Relevant strace from 'bad' cp:
ioctl(3, 0xc020660b, 0x7fff392c0950) = 0
ftruncate(4, 12853) = 0

strace from 'good' cp:
read(3, "#!/bin/bash -u\n\n#localisation\nex"..., 2097152) = 12853
write(4, "#!/bin/bash -u\n\n#localisation\nex"..., 12853) = 12853
read(3, "", 2097152) = 0

The strace didn't print the stat block information, but I'm assuming the st_blocks == 0 in the bad one. I will ask the customer to get a full strace -v to confirm, but it appears to be something similar to LU-417?

Issue Links

• is related to: LU-3219 FIEMAP does not sync data or return cached pages
• is related to: LU-417 block usage is reported as zero by stat call for tens of seconds after creating a file

Comments

[Cory Spitz]

This bug is still applicable to 2.1 when using cp built from coreutils 8.12, right? [I can't confirm that, but I think we're seeing this on 2.2] If so and since b2_1 is still the current maintenance branch, do we want to land a fix there?

[Peter Jones]

ok thanks for the update. That explains why we have been unable to reproduce this issue on the latest 2.4 code. I will close out this ticket.

[Kalpak Shah (Inactive)]

Update from KIT: With Lustre 2.3.0 on the client and patches 4477 and 4659 from LU-2367 and LU-2286, the issue cannot be reproduced.

LU-2367 fixes a race in unplugging the IO queue which can affect flush and fsync - and "cp" always calls FIEMAP with the SYNC flag set causing the cached extents to be flushed. LU-2286 fixes a bug where an extent does not get flushed to disk until the next write to the file occurs. So it does seem logical that the issue is not being reproduced with these 2 patches applied.

[Peter Jones]

Thanks Kalpak. With any patches applied?

[Kalpak Shah (Inactive)]

Peter, the clients are running Lustre 2.3 on SLES11 SP2.

[Peter Jones]

Could you please clarify as to what versions of Lustre (and any patches running) that are being used here? You mention that it is Lustre 2.1.2 servers but what version of Lustre is being used on the client?