DragonFly bugs List (threaded) for 2008-08
Re: panic: assertion: layer2->zone == zone in hammer_blockmap_free
:> I am going to need some additional information from you. Please sync
:> your filesystem and then do the following:
:> hammer -f <device> blockmap > textfile
:> hammer -f <device> -vvv show >> textfile
:> And gzip and upload that to leaf.
:Done as ~y0netan1/crash/blockmap.gz.
Excellent! This is great! Ok, here is the big-block blockmap entry:
4000000174800000 zone=9 app=8388608 free=8388480
Each big-block can hold 8MB (8388608 bytes). This one has 128 bytes
allocated out of it. From the B-Tree dump four inodes are allocated
out of that block, though, so it should have read 512 bytes
I already see a pattern, and I'm hoping it will lead to the bug.
The LO field is 0002xxxx == PFS#2. The tids are create:delete...
notice that one has a delete_tid of 0, which means it is live.
The others have a non-zero delete_tid, those have been deleted.
We get a nice ctime too... the ctime is in microseconds. First, here
are the inode records:
G------ ELM 14 R obj=0000000000000001 key=0000000000000000
lo=00020001 rt=01 ot=01 <<<< top 16 bits
of LO is the
tids 000000010848ffbb:0000000000000000 <<<<< create:delete
dataoff=9000000174dda260/128 crc=149d91f4 <<<< dataoff
size=0 nlinks=1 mode=01777 uflags=00000000
ctime=0004525a5174d38a pobjid=0000000000000000 obj_type=1
G------ ELM 15 R obj=0000000000000001 key=0000000000000000
lo=00020001 rt=01 ot=01
d tids 0000000108490171:0000000108490179 <<<< create:delete
size=0 nlinks=1 mode=00755 uflags=00000000
ctime=0004525b5cd8b43f pobjid=0000000000000000 obj_type=1
G------ ELM 22 R obj=0000000107e44a04 key=0000000000000000
lo=00020001 rt=01 ot=02
d tids 0000000108490169:0000000108490175
size=0 nlinks=2 mode=00644 uflags=00000000
ctime=0004525b4031d815 pobjid=0000000000000001 obj_type=2
G------ ELM 23 R obj=0000000107e44a05 key=0000000000000000
lo=00020001 rt=01 ot=07
d tids 000000010849016d:0000000108490175
size=3 nlinks=1 mode=00755 uflags=00000000
ctime=0004525b40e6eaf6 pobjid=0000000000000001 obj_type=7
The converted ctimes are:
Fri Jul 18 23:09:33 2008
Sat Jul 19 00:24:20 2008
Sat Jul 19 00:16:19 2008
Sat Jul 19 00:16:31 2008
So the inodes related to this broken freemap block were all created
on Jul 18th and 19th. They are all root inodes for PFS #2.
This is very good news. It's either related to the cross-device link
bug that we fixed, or its related to the PFS root inode creation or
I will try to cross reference the data offsets against the rest of
the dump to see if there are any more freemap discrepancies.