[prev in list] [next in list] [prev in thread] [next in thread]
List: dragonfly-bugs
Subject: [DragonFlyBSD - Bug #2114] hammer volume-add causes panic
From: Raimundo Santos via Redmine <bugtracker-admin () leaf ! dragonflybsd ! org>
Date: 2012-05-09 16:30:23
Message-ID: redmine.journal-10824.20120509093023 () leaf ! dragonflybsd ! org
[Download RAW message or body]
Issue #2114 has been updated by Raimundo Santos.
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 ;)
----------------------------------------
Bug #2114: hammer volume-add causes panic
http://bugs.dragonflybsd.org/issues/2114
Author: Matteo Cypriani
Status: New
Priority: Normal
Assignee:
Category:
Target version:
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
--
You have received this notification because you have either subscribed to it, or are \
involved in it. To change your notification preferences, please click here: \
http://bugs.dragonflybsd.org/my/account
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic