[LU-4389] If OST_SYNC causes inode update, client does not reflect change

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.0, Lustre 2.6.0
• Fix Version/s: Lustre 2.8.0
• Type: Bug
• Priority: Major
• Reporter: Nathaniel Clark
• Assignee: Zhenyu Xu
• Resolution: Fixed
• Labels: zfs
• Severity: 3

Description

This really only affects ZFS, because zfs does not update # of blocks until the blocks are flushed to disk, so after an OST_WRITE, the number of blocks only reflect the number on disk, but that number is updated after an OST_SYNC RPC (which returns the correct number of blocks, but is ignored by the client code).

Test: (on a ZFS backed setup)
1. client1$ dd if=/dev/zero of=/mnt/lustre/test oflag=sync bs=1M count=2
2. client1$ stat /mnt/lustre/test
3. client2$ stat /mnt/lustre/test OR clear locks on client1 and redo stat
4. See that the number of blocks is incorrect on client1 (client2 has correct value)

Comments

[Nathaniel Clark]

lustre/osc/osc_request.c::osc_sync_interpret() should be do attribute update similar to brw_interpret().

[Gerrit Updater]

Bobi Jam ([e-mail]) uploaded a new patch: http://review.whamcloud.com/12915
Subject: LU-4389 clio: update file attributes after sync
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b8a884c32992cb4253cd20a2188f9c615d715106

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/12915/
Subject: LU-4389 clio: update file attributes after sync
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 6dd64da78d85d62df96946d82418cc5b0760ff86

[Peter Jones]

Landed for 2.8