On Mon, 2008-08-25 at 17:26 +0900, 심재훈 wrote:
> Hi, I am analyzing jfs and taking some modification on it, and I met a
> failure when jfs redid log records in fsck.
> So, I tried to find the reason why that fsck failure
> occurred.(Unrecognize log type error)
> and I found some strange code in lmWriteRecord. but I am not confident.
>
> In function lmWriteRecord(), I expect jfs copy data in system buffer to
> log buffer, But in moveData lable, jfs does not intialize *len*
> variable. So, if linelock->index is larger than 2, the variable *len* is
> added to previous *len* value.
It's initialized once at the top of the function, which I believe is
correct.
>
> 415 moveData:
> 416 ASSERT(linelock->index <= linelock->maxcnt);
> 417
> 418 lv = linelock->lv;
> 419 for (i = 0; i < linelock->index; i++, lv++) {
> 420 if (lv->length == 0)
> 421 continue;
> 422
> 423 /* is page full ? */
> 424 if (dstoffset >= LOGPSIZE - LOGPTLRSIZE) {
> 425 /* page become full: move on to next page */
> 426 lmNextPage(log);
> 427
> 428 bp = log->bp;
> 429 lp = (struct logpage *) bp->l_ldata;
> 430 dstoffset = LOGPHDRSIZE;
> 431 }
> 432
> 433 /*
> 434 * move log vector data
> 435 */
> 436 src = (u8 *) p + (lv->offset << l2linesize);
> 437 srclen = lv->length << l2linesize;
> * 438 len += srclen; <== here "len = srclen" isn't it?*
> 439 while (srclen > 0) {
> 440 freespace = (LOGPSIZE - LOGPTLRSIZE) - dstoffset;
> 441 nbytes = min(freespace, srclen);
> 442 dst = (caddr_t) lp + dstoffset;
> 443 memcpy(dst, src, nbytes);
> 444 dstoffset += nbytes;
>
>
> For example, if jfs writes log of xtlckTREE type, it splits into 2 log
> record. One is xtpage header, the other is xtpage entry.
No, it will write a single log record which contains both entries. It
writes both sets of data, and then writes the record descriptor at the
end. It's confusing, because the journal is read backwards. fsck will
read the descriptor, and then read the data entries in reverse order.
> So first record
> length is 32byte, and second is 4064 byte (in case all entry is
> modified.), then the log record has to write to log buffer with length
> 36 byte (32 + 4(for log vector descriptor)), 4068 byte (4064 + 4), I
> think. But jfs writes record with length 36 and 4104(4064 + 4 + 36). Why
> the second log record adds previous record length 32 ?
It's one record which contains both sets of data.
> Is it right?? I don't know why.. Somebody explain this to me.
The jfs_logdump utility may be helpful in looking at the log records.
Please feel free to send me anything from the log that looks corrupt,
and I'll take a look at it.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
