[LU-4811] Interop 2.5<->2.6 failure on test suite sanity test_24u: error on ioctl 0x4008669a, no data availiable Created: 24/Mar/14  Updated: 31/Oct/14  Resolved: 01/Jun/14

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.5.1
Fix Version/s: Lustre 2.5.2

Type: Bug Priority: Blocker
Reporter: Maloo Assignee: Nathaniel Clark
Resolution: Fixed Votes: 0
Labels: None
Environment:

server: 2.5.1
client: lustre-master build # 1945


Issue Links:
Duplicate
duplicates LU-5139 Interop 2.5.1<->2.6 failure on test s... Closed
is duplicated by LU-5821 sanity test_24u 2.4-2.7 interop: erro... Resolved
is duplicated by LU-4814 Interop 2.5.1<->2.6 failure on test s... Closed
Related
is related to LU-3338 IOC_MDC_GETFILESTRIPE can abuse vmall... Resolved
Severity: 3
Rank (Obsolete): 13233

 Description   

This issue was created by maloo for sarah <sarah@whamcloud.com>

This issue relates to the following test suite run: http://maloo.whamcloud.com/test_sets/acaf508a-b240-11e3-a93f-52540035b04c.

The sub-test test_24u failed with the following error:

error() without useful message, please fix

== sanity test 24u: create stripe file == 12:37:21 (1395430641)
error on ioctl 0x4008669a for '/mnt/lustre/f24u.sanity' (3): No data available
write: Bad file descriptor


 Comments   
Comment by Sarah Liu [ 24/Mar/14 ]

Hit a lot similar error in the interop testing between 2.5.1 server and master client:

https://maloo.whamcloud.com/test_sets/acaf508a-b240-11e3-a93f-52540035b04c

== sanity test 27b: create and write to two stripe file == 12:49:00 (1395431340)
error on ioctl 0x4008669a for '/mnt/lustre/d27/f01' (3): No data available
error: setstripe: create stripe file '/mnt/lustre/d27/f01' failed
 sanity test_27b: @@@@@@ FAIL: setstripe failed 
Comment by Sarah Liu [ 25/Mar/14 ]

https://maloo.whamcloud.com/test_sets/2b16c06a-b242-11e3-a93f-52540035b04c

== sanity-benchmark test fsx: fsx == 17:01:05 (1395446465)
debug=0
error on ioctl 0x4008669a for '/mnt/lustre/f0.fsxfile' (3): No data available
error: setstripe: create stripe file '/mnt/lustre/f0.fsxfile' failed
Using: fsx -c 50 -p 1000 -S 2223 -P /tmp -l 3844216         -N 100000  /mnt/lustre/f0.fsxfile
Chance of close/open is 1 in 50
Seed set to 2223
trunc_hack: fstat: Numerical result out of range
no extend on truncate! not posix!
 sanity-benchmark test_fsx: @@@@@@ FAIL: fsx failed 
Comment by Peter Jones [ 26/Mar/14 ]

Nathaniel is looking into this one

Comment by Nathaniel Clark [ 27/Mar/14 ]

This was fixed on master as an addon to patch http://review.whamcloud.com/6339
see the last line of comment:

Also remove client eadatasize check in mdt xattr packing because
as said above client can handle -EOVERFLOW.

I believe this is what is tripping in this case.

http://review.whamcloud.com/9812

Comment by James A Simmons [ 04/Apr/14 ]

Your patch is less intrusive but I have to say back porting http://review.whamcloud.com/6339 is more desirable for us. The full patch from LU-3338 will also address the contention issues with vmalloc on the clients we see as well.

Comment by Nathaniel Clark [ 07/Apr/14 ]

Patch 6339 on LU-3338 is generally unrelated to this issue, it just happens to include the fix for this almost as an afterthought. It was infact added in rev 13 of that patch to fix an autotest issue.

Comment by James A Simmons [ 10/Apr/14 ]

You are right. I was thinking about the easy of cherry picking but that is not the case for the LU-3338 patch anyways. The LU-3338 patch uses linux apis instead of the cfs_ wrappers which needs to be fixed up for b2_5.
Just need to watch the order of landing.

Comment by Jodi Levi (Inactive) [ 10/Apr/14 ]

Test for Change, 9812 was retriggered just now.

Comment by Jodi Levi (Inactive) [ 21/Apr/14 ]

Test retriggered today.

Comment by Nathaniel Clark [ 22/Apr/14 ]

Since this issue is present in 2.5 and the patch 9812 is a back-ported form master to b2_5, I've changed the Affected and Fix version to the appropriate 2.5.x versions.

Comment by Peter Jones [ 01/Jun/14 ]

Landed for 2.5.2

Generated at Sat Feb 10 01:46:03 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.