Le lun 06/10/2003 à 08:54, Tim Shimmin a écrit :
> Hi Marcel,
> On Sat, Oct 04, 2003 at 06:51:42PM +0200, Marcel de Riedmatten wrote:
> > Then try xfs_logprint (without -t ) but it segfault:
> xfs_logprint without -t prior to xfsprogs-2.5.10 couldn't handle v2 logs.
> >From xfsprogs/doc/CHANGES:
> xfsprogs-2.5.10 (30 September 2003)
> - Fix up xfs_logprint to handle version 2 logs for its
> operation output (previously core dumped on it).
Thanks, i thought i was uptodate but
$ xfs_logprint -V
xfs_logprint version 2.5.6
> I noticed that you are using version 2 logs with a striped size of 48
> 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 >>
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
> 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.
> > 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.
Marcel de Riedmatten
pgp key: CFE703CA http://ftp.dotforge.ch/pub/users/mdr/mdr.gpg.asc
Empreinte: 4687 F9CB D8E2 AC1A B806 F812 C048 0875 CFE7 03CA
Description: PGP signature