[LU-1238] record_lcfg() failed with ENOSPC Created: 20/Mar/12 Updated: 29/May/17 Resolved: 29/May/17 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.2.0, Lustre 2.3.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Jian Yu | Assignee: | WC Triage |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Lustre Tag: v2_2_0_0_RC1 OSSCOUNT=2 |
||
| Attachments: |
|
| Severity: | 3 |
| Rank (Obsolete): | 10883 |
| Description |
|
While running ost-pools test 5 with 2000 OSTs, after adding 2000 OSTs to one OST pool and then removing the OSTs from the pool, the test failed as follows: <~snip~> client-19-ib: Warning, OST lustre-OST041f_UUID still found in pool lustre.testpool client-19-ib: Warning, OST lustre-OST0420_UUID still found in pool lustre.testpool <~snip~> Console log on the combined MGS/MDS showed that: LustreError: 16312:0:(mgs_llog.c:752:record_lcfg()) failed -28 Maloo report: https://maloo.whamcloud.com/test_sets/a610c4b2-71cd-11e1-9716-5254004bbbd3 By running llog_reader on CONFIGS/lustre-MDT0000 file on the MGS/MDS node, I found there were 63293 records in that file and 1474 bits were not set. The last several records are: #64763 (224)marker 2043193 (flags=0x01, v2.2.0.0) lustre-MDT0000-mdtlov 'rem lustre.testpool.lustre-OST041d_UUID' Mon Mar 19 03:01:52 2012- The OST pool operations consumed most of the records and caused the record count reach to the following limitation: /* if it's the last idx in log file, then return -ENOSPC */
if (loghandle->lgh_last_idx >= LLOG_BITMAP_SIZE(llh) - 1)
RETURN(-ENOSPC);
/* (8192 - 88 - 8) * 8 = 64768 */
#define LLOG_BITMAP_SIZE(llh) ((llh->llh_hdr.lrh_len - \
llh->llh_bitmap_offset - \
sizeof(llh->llh_tail)) * 8)
Please find the attached lustre-MDT0000.log for the output of "llog_reader lustre-MDT0000" and see how to resolve this issue. |
| Comments |
| Comment by Andreas Dilger [ 10/Sep/12 ] |
|
Two problems are visible in this config log:
Alex has recently been reworking how config llogs are processed by the servers, and I wonder if we could simplify this for newer clients as well? Maybe we don't even need marker lines anymore, or we can figure a way not to need them. Similarly, newer servers do not need so many lines to configure their device stack, maybe clients could become more intelligent as well (i.e. given a record with OST+NIDs they can figure everything else out)? |
| Comment by Andreas Dilger [ 29/May/17 ] |
|
Close old ticket. |