PFL known issues tracking ticket
(LU-9349)
|
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.10.0 |
| Fix Version/s: | Lustre 2.10.0 |
| Type: | Technical task | Priority: | Critical |
| Reporter: | James Nunez (Inactive) | Assignee: | Zhenyu Xu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pfl | ||
| Issue Links: |
|
||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||
| Description |
|
Recent testing on master with files with multiple components show that several tests fail due to ‘lfs getstripe’ with the index or the stripe count flags return multiple lines of output. If this impacts the Lustre test suites, this could impact exiting tools that use ‘lfs getstripe’ and expect output of a single value. To demonstrate this, we have a file with three components: [root@eagle-48vm6 ]# lfs getstripe /lustre/scratch/d9.sanity/d2/d3
/lustre/scratch/d9.sanity/d2/d3
lcm_layout_gen: 0
lcm_entry_count: 3
lcme_id: N/A
lcme_flags: 0
lcme_extent.e_start: 0
lcme_extent.e_end: 2097152
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1
lcme_id: N/A
lcme_flags: 0
lcme_extent.e_start: 2097152
lcme_extent.e_end: 16777216
stripe_count: 2 stripe_size: 2097152 stripe_offset: -1
lcme_id: N/A
lcme_flags: 0
lcme_extent.e_start: 16777216
lcme_extent.e_end: EOF
stripe_count: 4 stripe_size: 4194304 stripe_offset: -1
[root@eagle-48vm6 ]# lfs getstripe -i /lustre/scratch/d9.sanity/d2/d3
-1
-1
-1
[root@eagle-48vm6 ]# lfs getstripe -c /lustre/scratch/d9.sanity/d2/d3
1
2
4
Andreas Dilger has commented on this issue:
The following tests fail due to expecting a single value from ‘lfs getstripe’. |
| Comments |
| Comment by Zhenyu Xu [ 21/Apr/17 ] |
|
The patch of |
| Comment by Andreas Dilger [ 21/Apr/17 ] |
|
On further reflection, I think that always returning the parameters from the last instantiated component makes more sense than returning the sum of all the components. For example, it doesn't make sense to return the sum of the stripe sizes, or the sum of the pools (what would that even be?), or the sum of the stripe indices. The only one item that is even practical is the sum of the stripe counts, but I think this exception would be confusing, and even then it isn't clearly the best option. Returning the stripe count (and size, pool) of the last instantiated component allows applications that don't know about PFL or are copying the file to a non-PFL filesystem to create a file layout that has (approximately) the same performance as the the (normally) largest part of the file, and what would be used if more data is being written to the file (at least until it grows into the next component). This would preserve the "use best layout based on file size" property of PFL even if the file has to be flattened to use a plain layout. |
| Comment by Andreas Dilger [ 04/May/17 ] |
|
Bobijam, can you please provide a fix for this issue. As mentioned above, I think when asking for a simple value that the result from the last instantiated component. |
| Comment by Gerrit Updater [ 04/May/17 ] |
|
Bobi Jam (bobijam@hotmail.com) uploaded a new patch: https://review.whamcloud.com/26947 |
| Comment by Gerrit Updater [ 16/May/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/26947/ |
[LU-9362]