[LU-487] procfs stats file incorrectly records brw_read and brw_write values Created: 05/Jul/11 Updated: 12/Aug/11 Resolved: 12/Aug/11 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.1.0, Lustre 1.8.6 |
| Fix Version/s: | Lustre 2.1.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Richard Henwood (Inactive) | Assignee: | Richard Henwood (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Epic: | papercut |
| Rank (Obsolete): | 4929 |
| Description |
|
brw_read in llite client procfs stats file claims to measure in units of pages. For example: # cat /proc/fs/lustre/llite/lustre-ffff88000449a800/stats snapshot_time 1308264214.464257 secs.usecs dirty_pages_hits 1419716 samples [regs] dirty_pages_misses 833472 samples [regs] read_bytes 322963 samples [bytes] 1 2684356 154236888794 write_bytes 225001 samples [bytes] 0 125912 3323679002 brw_read 15285 samples [pages] 4096 4096 62607360 However, in ./lustre/llite/lloop.c the tallying of the LPROC_LL_BRW_WRITE/READ counter increments by the value of: page_count << PAGE_CACHE_SHIFT Using this value has the effect of not measure pages, but the total bytes of the pages. A simple fix maybe to remove the PAGE_CACHE_SHIFT. Or, rename '[pages]' to '[bytes]' in the output. |
| Comments |
| Comment by Andreas Dilger [ 06/Jul/11 ] |
|
Since the "read_bytes" and "write_bytes" entries already exist, it makes sense to remove the "<< PAGE_CACHE_SHIFT" and actually count in pages. It is also inconsistent that there is a brw_read stat, but not a brw_write stat... |
| Comment by Richard Henwood (Inactive) [ 06/Jul/11 ] |
|
Can I query: Since this tally call is in lloop.c, it is only used during loopback testing. If this is the case, the stats brw_ records are the number of partial page request that took place during testing. so: brw_ in it's current state of limited use. |
| Comment by Richard Henwood (Inactive) [ 06/Jul/11 ] |
|
So, to call out explicitly: It seems to me brw_ records can lead to miss-interpretation in their current state. How about omitting them entirely? |
| Comment by Richard Henwood (Inactive) [ 20/Jul/11 ] |
|
change available at: |
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Build Master (Inactive) [ 08/Aug/11 ] |
|
Integrated in Oleg Drokin : 6aea71f39238f370c02a2f293a01555cc653bd01
|
| Comment by Richard Henwood (Inactive) [ 12/Aug/11 ] |
|
Fix merged into Master. |