Hi Marcel,
> > >
> > I noticed that you are using version 2 logs with a striped size of 48
> > 4K-blocks
> > or 8*48=384 BBs (512 byte blocks).
> > I believe there is a bug in the code for log sunit which is not
> > a power of 2 in BBs.
> > xfs_log.c: log->l_stripemask = 1 << xfs_highbit32(mp->m_sb.sb_logsunit >>
> > BBSHIFT);
>
> ok i'll use 64k (128BBs) which is my stripsize. I am going to add lvm to
> the thing and alignement outside power of 2 will be hard if even
> possible anyway.
>
> >
> > I have a fix in my own code but it is mixed with some other v2 log changes.
> > I'm currently writing v2 log QA to test this stuff out.
> > I'll let you know when I check this stuff in.
>
> ok
>
> >
> > > xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c.
> > This error happens (great msg I think not:) if the tail of the log
> > is greater than the head. By greater I mean in terms of <block#, cycle#>.
> > (So if the cycle #s of the head/tail are the same then
> > the tail blk < head blk otherwise
> > the tail cycle# should be one less than the head cycle# since
> > the tail must be on the previous cycle.
> > And the tail should never be greater than the head.
> >
> > > xfs_logprint:
> > > data device: 0x801
> > > log device: 0x801 daddr: 1468006656 length: 261888
> > >
> > > log tail: 60416 head: 65279 state: <DIRTY>
> > >
> > >
> > > LOG REC AT LSN cycle 7 block 60416 (0x7, 0xec00)
> > > ============================================================================
> > > TRANS: tid:0xc45c87bc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70
> > >
> > It looks like the tail blk# (60416) is less than the head blk# (65279).
> > In which case it is likely that the cycle numbers are not the same like
> > they should be.
>
>
> I am not sure if this can be seen as consequence of the log alignment.
> Anyway i 'll try with 64k log alignement and see if i can repeat it.
>
I'm not certain either but it stood out to me.
And it is possible.
The use of l_stripemask is for setting log->l_curr_block with a roundup.
And l_curr_block is used in iclog->ic_header.h_lsn[1] which is used
to set the block# for where the next log record starts on disk
on the next log record write.
And the count for the size of the log record write is correctly rounded
up to the sb_logsunit boundary (no l_stripemask used here).
So this means, that in your case of logsunit of 384 BBs we would use:
- block# start on 256BB boundary (384 --> 256 (power of 2) with mask from
xfs_highbit32())
- block count in 384BB multiples (we use the right number here)
This could corrupt the log AFAICT.
Cheers,
Tim.
|