Bug #2114

hammer volume-add causes panic

Added by mcy over 2 years ago. Updated about 1 year ago.

Status:FeedbackStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hello,

I have troubles trying to add a volume to my HAMMER root filesystem on a fresh
install (DragonFly 2.10.1 i386, on an AMD Athlon 2000+ with 512 MB RAM). Maybe
I'm doing something wrong, but if so I don't see what. I created a new
partition table on the hard drive (ad2) with a DF slice (ad2s1), and a hammer
partition on it (ad2s1d). Then I just run hammer volume-add /dev/ad2s1d /, and
it panics.

If I add the volume to /boot/loader.conf and /etc/fstab, after a reboot I can
see it in hammer volume-list, but hammer info gives exactly the same results
as with only the first volume. hammer volume-del fails (device busy), but I can
safely remove the new volume from loader.conf and fstab (I also tried without
running volume-del, same thing).

It is fully reproducible, with this hard drive and with another one (and if I
remember well, I had the same problem when I played with HAMMER in a KVM
virtual machine some times ago).
The session log below shows how I reproduced the problem (with the same first
drive). It seems that something was initialised, because I had to erase the
beginning of the partition to re-add the volume.

Please tell me if I made a mistake somewhere, and if not what I can do to help
solving the bug. I attached the crash info and core files (I can provide the
full core dump if needed).

Cheers,

Matteo

16:38 root@vicious ~# fdisk ad2
******* Working on device /dev/ad2 *******
parameters extracted from device are:
cylinders=24696 heads=256 sectors/track=63 (16128 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=24696 heads=256 sectors/track=63 (16128 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165,(DragonFly/FreeBSD/NetBSD/386BSD)
start 63, size 398297025 (194480 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
16:39 root@vicious ~# disklabel ad2s1
# /dev/ad2s1:
#
# Informational fields calculated from the above
# All byte equivalent offsets must be aligned
#
# boot space: 1044992 bytes
# data space: 199147483 blocks # 194479.96 MB (203927023104 bytes)
#
# NOTE: If the partition data base looks odd it may be
# physically aligned instead of slice-aligned
#
diskid: 076febcf-c669-11e0-bb09-01138f237da1
label:
boot2 data base: 0x000000001000
partitions data base: 0x000000100200
partitions data stop: 0x002f7b0f7000
backup label: 0x002f7b0f7000
total size: 0x002f7b0f8200 # 194480.97 MB
alignment: 4096
display block size: 1024 # for partition display only

16 partitions:
# size offset fstype fsuuid
d: 199147480 0 HAMMER # 194479.961MB
d-stor_uuid: 5191beaf-c67a-11e0-9d47-01138f237da1
16:40 root@vicious ~# hammer volume-add /dev/ad2s1d /
hammer volume-add ioctl: Inappropriate file type or format
16:41 root@vicious ~# dd if=/dev/zero of=/dev/ad2s1d bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.037720 secs (27798965 bytes/sec)
16:42 root@vicious ~# hammer volume-add /dev/ad2s1d /

An error occurred: 79
panic: hammer_io_set_modlist: duplicate entry
Trace beginning at frame 0xcc2e37a0
panic(ffffffff,c07acd60,c06bfbbc,cc2e37d0,c1cadf30) at panic+0x101
panic(c06bfbbc,c1cadf30,0,c1cadf38,c9d69670) at panic+0x101
hammer_io_modify(cc2e3880,cc2e3814,c0533fbe,c1cadf38,1) at
hammer_io_modify+0x186
hammer_modify_volume(cc2e3a30,c1cadf30,c5b88094,4,cc2e3860) at
hammer_modify_volume+0x4a
hammer_ioc_volume_add(cc2e3a30,c9dd44e0,c97ca258,c1d9f950,c1d9f954) at
hammer_ioc_volume_add+0x49a
hammer_ioctl(c9dd44e0,c4306811,c97ca258,1,c7d91ba8) at hammer_ioctl+0xf41
hammer_vop_ioctl(cc2e3a98,c0725d48,c1d80e00,cc1c7498,cc2e3ae8) at
hammer_vop_ioctl+0x5e
vop_ioctl(c1d80e00,c1db8538,c4306811,c97ca258,1) at vop_ioctl+0x75
vn_ioctl(c7dcf1e8,c4306811,c97ca258,c7d91ba8,cc2e3cf0) at vn_ioctl+0x106
fo_ioctl(c7d91ba8,cc2e3cf0,430,c7dc0000,c7dc0000) at fo_ioctl+0x3c
mapped_ioctl(3,c4306811,bfbff280,0,cc2e3cf0) at mapped_ioctl+0x4ae
sys_ioctl(cc2e3cf0,cc2e3d00,c,c9743158,cc2e3cf0) at sys_ioctl+0x2e
syscall2(cc2e3d40) at syscall2+0x232
Xint0x80_syscall() at Xint0x80_syscall+0x36
Debugger("panic")
Stopped at Debugger+0x3f: movb $0,in_Debugger.4431

core.txt.0.gz (13 KB) mcy, 08/14/2011 08:46 PM

info.0 (501 Bytes) mcy, 08/14/2011 08:46 PM

History

#1 Updated by lhmwzy over 2 years ago

I have the same problem.

uname -a
DragonFly lhmwzy.org. 2.13-DEVELOPMENT DragonFly
2.13.0.34.g10c9b-DEVELOPMENT #0: Tue Oct 11 21:40:17 PDT 2011
:/usr/obj/build/justin/dragonfly/sys/X86_64_GENERIC
 x86_64
>
> 2011/8/15 Matteo Cypriani <>:
>> Hello,
>>
>> I have troubles trying to add a volume to my HAMMER root filesystem on a fresh
>> install (DragonFly 2.10.1 i386, on an AMD Athlon 2000+ with 512 MB RAM). Maybe
>> I'm doing something wrong, but if so I don't see what. I created a new
>> partition table on the hard drive (ad2) with a DF slice (ad2s1), and a hammer
>> partition on it (ad2s1d). Then I just run hammer volume-add /dev/ad2s1d /, and
>> it panics.
>>
>> If I add the volume to /boot/loader.conf and /etc/fstab, after a reboot I can
>> see it in hammer volume-list, but hammer info gives exactly the same results
>> as with only the first volume. hammer volume-del fails (device busy), but I can
>> safely remove the new volume from loader.conf and fstab (I also tried without
>> running volume-del, same thing).
>>
>> It is fully reproducible, with this hard drive and with another one (and if I
>> remember well, I had the same problem when I played with HAMMER in a KVM
>> virtual machine some times ago).
>> The session log below shows how I reproduced the problem (with the same first
>> drive). It seems that something was initialised, because I had to erase the
>> beginning of the partition to re-add the volume.
>>
>> Please tell me if I made a mistake somewhere, and if not what I can do to help
>> solving the bug. I attached the crash info and core files (I can provide the
>> full core dump if needed).
>>
>> Cheers,
>>
>>  Matteo
>>
>>
>> 16:38 root@vicious ~# fdisk ad2
>> ******* Working on device /dev/ad2 *******
>> parameters extracted from device are:
>> cylinders=24696 heads=256 sectors/track=63 (16128 blks/cyl)
>>
>> Figures below won't work with BIOS for partitions not in cyl 1
>> parameters to be used for BIOS calculations are:
>> cylinders=24696 heads=256 sectors/track=63 (16128 blks/cyl)
>>
>> Media sector size is 512
>> Warning: BIOS sector numbering starts with sector 1
>> Information from DOS bootblock is:
>> The data for partition 1 is:
>> sysid 165,(DragonFly/FreeBSD/NetBSD/386BSD)
>>    start 63, size 398297025 (194480 Meg), flag 80 (active)
>>        beg: cyl 0/ head 1/ sector 1;
>>        end: cyl 1023/ head 255/ sector 63
>> The data for partition 2 is:
>> <UNUSED>
>> The data for partition 3 is:
>> <UNUSED>
>> The data for partition 4 is:
>> <UNUSED>
>> 16:39 root@vicious ~# disklabel ad2s1
>> # /dev/ad2s1:
>> #
>> # Informational fields calculated from the above
>> # All byte equivalent offsets must be aligned
>> #
>> # boot space:    1044992 bytes
>> # data space:  199147483 blocks # 194479.96 MB (203927023104 bytes)
>> #
>> # NOTE: If the partition data base looks odd it may be
>> #       physically aligned instead of slice-aligned
>> #
>> diskid: 076febcf-c669-11e0-bb09-01138f237da1
>> label:
>> boot2 data base:      0x000000001000
>> partitions data base: 0x000000100200
>> partitions data stop: 0x002f7b0f7000
>> backup label:         0x002f7b0f7000
>> total size:           0x002f7b0f8200    # 194480.97 MB
>> alignment: 4096
>> display block size: 1024        # for partition display only
>>
>> 16 partitions:
>> #          size     offset    fstype   fsuuid
>>  d:  199147480          0    HAMMER    #  194479.961MB
>>  d-stor_uuid: 5191beaf-c67a-11e0-9d47-01138f237da1
>> 16:40 root@vicious ~# hammer volume-add /dev/ad2s1d /
>> hammer volume-add ioctl: Inappropriate file type or format
>> 16:41 root@vicious ~# dd if=/dev/zero of=/dev/ad2s1d bs=1M count=1
>> 1+0 records in
>> 1+0 records out
>> 1048576 bytes transferred in 0.037720 secs (27798965 bytes/sec)
>> 16:42 root@vicious ~# hammer volume-add /dev/ad2s1d /
>>
>> An error occurred: 79
>> panic: hammer_io_set_modlist: duplicate entry
>> Trace beginning at frame 0xcc2e37a0
>> panic(ffffffff,c07acd60,c06bfbbc,cc2e37d0,c1cadf30) at panic+0x101
>> panic(c06bfbbc,c1cadf30,0,c1cadf38,c9d69670) at panic+0x101
>> hammer_io_modify(cc2e3880,cc2e3814,c0533fbe,c1cadf38,1) at
>> hammer_io_modify+0x186
>> hammer_modify_volume(cc2e3a30,c1cadf30,c5b88094,4,cc2e3860) at
>> hammer_modify_volume+0x4a
>> hammer_ioc_volume_add(cc2e3a30,c9dd44e0,c97ca258,c1d9f950,c1d9f954) at
>> hammer_ioc_volume_add+0x49a
>> hammer_ioctl(c9dd44e0,c4306811,c97ca258,1,c7d91ba8) at hammer_ioctl+0xf41
>> hammer_vop_ioctl(cc2e3a98,c0725d48,c1d80e00,cc1c7498,cc2e3ae8) at
>> hammer_vop_ioctl+0x5e
>> vop_ioctl(c1d80e00,c1db8538,c4306811,c97ca258,1) at vop_ioctl+0x75
>> vn_ioctl(c7dcf1e8,c4306811,c97ca258,c7d91ba8,cc2e3cf0) at vn_ioctl+0x106
>> fo_ioctl(c7d91ba8,cc2e3cf0,430,c7dc0000,c7dc0000) at fo_ioctl+0x3c
>> mapped_ioctl(3,c4306811,bfbff280,0,cc2e3cf0) at mapped_ioctl+0x4ae
>> sys_ioctl(cc2e3cf0,cc2e3d00,c,c9743158,cc2e3cf0) at sys_ioctl+0x2e
>> syscall2(cc2e3d40) at syscall2+0x232
>> Xint0x80_syscall() at Xint0x80_syscall+0x36
>> Debugger("panic")
>> Stopped at   Debugger+0x3f: movb   $0,in_Debugger.4431
>>
>

#2 Updated by raitech almost 2 years ago

  • Description updated (diff)

The same issue here, with 3.0.2 on an Phenon II X4 B65, amd64 version of dflybsd.

In my tests, the vinum worked very well (much more then freebsd gvinum, which not worked at all...) in three partitions as a raid5 - yes, with a performance issue, ofcourse. I have put a hammer over my raid5, which orked smootlhy. But the real part of the test: extend the hammerfs by adding some other partition. Do not worked, failed but not paniced the kernel. When trying the same with a whole disk, kernel panic:

An error occurred: 79
panic: hammer_io_set_modlist: duplicate entry
cpuid = 2
Trace beginning at frame 0xffffffe12278c3b8
?y?() at ?y?+0x1fb 0xffffffff8049a84d
?y?() at ?y?+0x1fb 0xffffffff8049a84d
A?3L?_(H??8() at A?3L?_(H??8+0x1ed 0xffffffff8067cc03
??7@??tB@?? t<@??-t6I???pz?@???L???() at ??7@??tB@?? t<@??-t6I???pz?@???L???+0x6b 0xffffffff8067db07
?????t$I??$h?() at ?????t$I??$h?+0x469 0xffffffff80673eae
?I?D$H??-?I?D$8() at ?I?D$H??-?I?D$8+0xc42 0xffffffff8067f522
>??7!() at >??7!+0x58 0xffffffff80697e97
???() at ???+0x98 0xffffffff80517c04
B??H?;???!() at B??H?;???!+0xfd 0xffffffff80514e59
() at +0x46 0xffffffff804cb32e
u?J?|W?E??A??C?D????t ???H????() at u?J?|W?E??A??C?D????t ???H????+0x493 0xffffffff804cb7e5
() at +0x1c 0xffffffff804cb87e
() at +0x370 0xffffffff8075aae1
??$ ?() at ??$ ?+0xcb 0xffffffff8074446b
Debugger("panic")

yes, yes... I am a newbie in this things... but i have tried! :)

#3 Updated by raitech almost 2 years ago

after a kernel+world upgrade from 3.0.2 to 3.0.2.38.g8b6039 (by now, the head of DragonFly_RELEASE_3_0 branch), the panic has gone, but still not adding other volume to hammer fs. Both trys, one to add a HAMMER type partition and another to add a entire disk, returns the same error:

hammer: Unable to open <device name here> R+W

#4 Updated by raitech almost 2 years ago

Good news: it worked here!

No updates, no new kernel (3.0.2.38.g8b6039). It is just undocumented that the device path must be the complete one, not just the device name, as is with fdisk and gpt. And, also, that a device must be a dfly labeled partition as with MBR, or a GPT slice.

Tried with the same vinum raid5 (with three partitions, avg. of 12MB/s of I/O - not so bad...) as the root device, and added another partition in the same disk as a volume and an entire disk partitioned with one gpt slice - the later do not need to be labeled with disklabel (gpt does that?). With da0s2 labeled, these are a summary of the issued commands:

mymachine# ls -l /dev/serno
total 0
crw-r----- 1 root operator 28, 0x1e11000f May 8 21:28 5VP9CD50 <-- da1
...
crw-r----- 1 root operator 28, 0x1e110007 May 7 12:20 S15LJ50QA08727 <-- da0
...

mymachine# fdisk -i da0 <-- to create a new partition (da0s2) after instalation
mymachine# disklabel -w -r da0s2 auto
mymachine# disklabel -e da0s2

# /dev/da0s2:
...

16 partitions:
# size offset fstype fsuuid
a: 10485760 0 vinum # 10240.000MB
b: 10485760 10485760 vinum # 10240.000MB
d: 10485760 20971520 vinum # 10240.000MB
e: 15728640 31457280 HAMMER # 15360.000MB
a-stor_uuid: 50adb5ba-975e-11e1-a78c-f56d04008fa1
b-stor_uuid: 50adb5ce-975e-11e1-a78c-f56d04008fa1
d-stor_uuid: 50adb5dc-975e-11e1-a78c-f56d04008fa1
e-stor_uuid: 50adb5e6-975e-11e1-a78c-f56d04008fa1

mymachine# vinum create

# Vinum configuration
# Current configuration:
# drive d1 device /dev/da0s2a
# drive d2 device /dev/da0s2b
# drive d3 device /dev/da0s2d
# volume raid5
# plex name raid5.p0 org raid5 16200s vol raid5
# sd name raid5.p0.s0 drive d1 plex raid5.p0 len 18873000s driveoffset 265s plexoffset 0s
# sd name raid5.p0.s1 drive d2 plex raid5.p0 len 18873000s driveoffset 265s plexoffset 16200s
# sd name raid5.p0.s2 drive d3 plex raid5.p0 len 18873000s driveoffset 265s plexoffset 32400s

mymachine# newfs_hammer -L raid5_test /dev/vinum/vol/raid5
mymachine# mount_hammer /dev/vinum/vol/raid5 /mnt/test
mymachine# gpt create da1 <-- create GPT table
mymachine# gpt add da1 <-- use entire disk in one slice
mymachine# hammer volume-add /dev/serno/5VP9CD50.s0 /mnt/test
mymachine# hammer volume-add /dev/serno/S15LJ50QA08727.s2e /mnt/test
mymachine# hammer info
...
Volume identification
Label raid5_test
No. Volumes 3
FSID 6b5e5b20-974b-11e1-a259-f56d04008fa1
HAMMER Version 6
Big block information
Total 123102
Used 1255 (1.02%)
Reserved 844 (0.69%)
Free 121003 (98.29%)
Space information
No. Inodes 2
Total size 962G (1032654422016 bytes)
Used 9.8G (1.02%)
Reserved 6.6G (0.69%)
Free 945G (98.29%)
PFS information
PFS ID Mode Snaps Mounted on
0 MASTER 0 /mnt/test

mymachine# hammer volume-list /mnt/test
/dev/vinum/vol/raid5
/dev/serno/5VP9CD50.s0
/dev/serno/S15LJ50QA08727.s2e

Performance is not that good, but it is an testing environment, so it does not bore me. I have tried to remove the new volumes after putting a 10GB file in the raid5_test, and all went OK, no surprises. But always referencing the device as a fullpath, and with respect to /dev/serno for security of device name changing.

Noticed that it is very time expensive to remove a volume, even an 15GB partition. Maybe my raid5 volume is very slow ;)

#5 Updated by tuxillo about 1 year ago

  • Status changed from New to Feedback
  • Assignee deleted (0)

Hi all,

I've done a couple tests, using partitions within a slice.
In my case I've added/removed 4 disks to the HAMMER filesystem and only had a couple problems. A panic has been recently fixed (commit 0465e1d385953232678697cd5c17964cf45eaf49).

Please report back whether whether it works for you.

Cheers,
Antonio Huete

Also available in: Atom PDF