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
