From jos at catnook.com Thu Jan 1 03:16:12 2009 From: jos at catnook.com (Jos Backus) Date: Thu Jan 1 03:16:18 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> Message-ID: <20090101031634.GD64075@lizzy.catnook.local> Hi Marcel, On Mon, Dec 29, 2008 at 10:11:03PM -0800, Marcel Moolenaar wrote: > I've seen this before: Erase the second sector on your > disk. You likely have a stale BSD disklabel there. Before I start erasing, does this look like something that can be erased safely? lizzy:~# dd if=/dev/ad0 count=1 skip=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.009828 secs (52096 bytes/sec) 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000030 10 00 00 00 15 ed 12 00 f0 03 00 00 b0 82 85 4a |...............J| 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 00 00 00 00 57 45 56 82 a8 07 08 00 00 20 00 00 |....WEV...... ..| 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 |...... .........| 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 |...o...... .....| 000000b0 01 00 00 00 b0 82 85 4a 00 00 00 00 00 00 00 00 |.......J........| 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 |...... .........| 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 |...o............| 000000e0 07 08 88 6f a0 82 c5 45 10 00 c0 04 00 08 00 00 |...o...E........| 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 Or do you mean /dev/ad0s1? (I thought disklabels generally sit inside fdisk partitions^Wslices.) lizzy:~# dd if=/dev/ad0s1 count=1 skip=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.016460 secs (31105 bytes/sec) 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000030 10 00 00 00 14 ed 12 00 f0 03 00 00 71 82 85 4a |............q..J| 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 00 00 00 00 57 45 56 82 68 07 08 00 00 20 00 00 |....WEV.h.... ..| 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 |...... .........| 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 |...o...... .....| 000000b0 01 00 00 00 71 82 85 4a 00 00 00 00 00 00 00 00 |....q..J........| 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 |...... .........| 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 |...o............| 000000e0 07 08 88 6f 61 82 c5 45 10 00 c0 04 00 08 00 00 |...oa..E........| 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000110 00 00 00 00 eb 0e 42 54 58 01 02 80 f6 0f 80 06 |......BTX.......| 00000120 00 20 00 00 fa 31 c0 8e d0 bc 00 18 8e c0 8e d8 |. ...1..........| 00000130 66 6a 02 66 9d bf 00 5e b9 00 19 f3 ab bb 22 95 |fj.f...^......".| 00000140 b9 10 00 bf 80 00 89 1d 47 47 ab 83 c3 04 e2 f6 |........GG......| 00000150 bf 00 5e be d2 95 ac 98 91 e3 1d ac 92 ad 93 ad |..^.............| 00000160 b6 08 d1 eb 73 0b 89 05 88 75 02 88 55 05 83 c0 |....s....u..U...| 00000170 04 8d 7d 08 e2 ec eb de c6 45 05 18 c6 45 08 10 |..}......E...E..| 00000180 c6 45 66 68 bb 20 28 e8 b8 00 0f 01 1e c6 95 0f |.Efh. (.........| 00000190 01 16 c0 95 0f 20 c0 40 0f 22 c0 ea 8c 90 08 00 |..... .@."......| 000001a0 31 c9 b1 10 8e d1 b1 38 0f 00 d9 ba 00 a0 00 00 |1......8........| 000001b0 36 0f b7 05 13 04 00 00 c1 e0 0a 2d 00 10 00 00 |6..........-....| 000001c0 29 d0 b1 33 51 50 68 02 02 00 00 6a 2b ff 35 0c |)..3QPh....j+.5.| 000001d0 90 00 00 51 51 51 51 52 b1 07 6a 00 e2 fc 61 07 |...QQQQR..j...a.| 000001e0 1f 0f a1 0f a9 cf fa bc 00 18 00 00 0f 20 c0 25 |............. .%| 000001f0 ff ff ff 7f 0f 22 c0 31 c9 0f 22 d9 0f 01 15 c0 |.....".1..".....| 00000200 Thanks and Happy New Year! Groetjes, -- Jos Backus jos at catnook.com From xcllnt at mac.com Sat Jan 3 16:30:12 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 16:30:19 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: <20090101031634.GD64075@lizzy.catnook.local> References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> <20090101031634.GD64075@lizzy.catnook.local> Message-ID: On Dec 31, 2008, at 7:16 PM, Jos Backus wrote: > Hi Marcel, > > On Mon, Dec 29, 2008 at 10:11:03PM -0800, Marcel Moolenaar wrote: >> I've seen this before: Erase the second sector on your >> disk. You likely have a stale BSD disklabel there. > > Before I start erasing, does this look like something that can be > erased > safely? > > lizzy:~# dd if=/dev/ad0 count=1 skip=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.009828 secs (52096 bytes/sec) > 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000030 10 00 00 00 15 ed 12 00 f0 03 00 00 b0 82 85 4a > |...............J| > 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000080 00 00 00 00 57 45 56 82 a8 07 08 00 00 20 00 00 > |....WEV...... ..| > 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 > |...... .........| > 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 > |...o...... .....| > 000000b0 01 00 00 00 b0 82 85 4a 00 00 00 00 00 00 00 00 > |.......J........| > 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 > |...... .........| > 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 > |...o............| > 000000e0 07 08 88 6f a0 82 c5 45 10 00 c0 04 00 08 00 00 > |...o...E........| > 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000200 > > Or do you mean /dev/ad0s1? (I thought disklabels generally sit > inside fdisk > partitions^Wslices.) > > lizzy:~# dd if=/dev/ad0s1 count=1 skip=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.016460 secs (31105 bytes/sec) > 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000030 10 00 00 00 14 ed 12 00 f0 03 00 00 71 82 85 4a > |............q..J| > 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000080 00 00 00 00 57 45 56 82 68 07 08 00 00 20 00 00 > |....WEV.h.... ..| > 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 > |...... .........| > 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 > |...o...... .....| > 000000b0 01 00 00 00 71 82 85 4a 00 00 00 00 00 00 00 00 > |....q..J........| > 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 > |...... .........| > 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 > |...o............| > 000000e0 07 08 88 6f 61 82 c5 45 10 00 c0 04 00 08 00 00 > |...oa..E........| > 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000110 00 00 00 00 eb 0e 42 54 58 01 02 80 f6 0f 80 06 > |......BTX.......| > 00000120 00 20 00 00 fa 31 c0 8e d0 bc 00 18 8e c0 8e d8 |. ... > 1..........| > 00000130 66 6a 02 66 9d bf 00 5e b9 00 19 f3 ab bb 22 95 | > fj.f...^......".| > 00000140 b9 10 00 bf 80 00 89 1d 47 47 ab 83 c3 04 e2 f6 > |........GG......| > 00000150 bf 00 5e be d2 95 ac 98 91 e3 1d ac 92 ad 93 ad > |..^.............| > 00000160 b6 08 d1 eb 73 0b 89 05 88 75 02 88 55 05 83 c0 > |....s....u..U...| > 00000170 04 8d 7d 08 e2 ec eb de c6 45 05 18 c6 45 08 10 > |..}......E...E..| > 00000180 c6 45 66 68 bb 20 28 e8 b8 00 0f 01 1e c6 95 0f |.Efh. > (.........| > 00000190 01 16 c0 95 0f 20 c0 40 0f 22 c0 ea 8c 90 08 00 > |..... .@."......| > 000001a0 31 c9 b1 10 8e d1 b1 38 0f 00 d9 ba 00 a0 00 00 | > 1......8........| > 000001b0 36 0f b7 05 13 04 00 00 c1 e0 0a 2d 00 10 00 00 | > 6..........-....| > 000001c0 29 d0 b1 33 51 50 68 02 02 00 00 6a 2b ff 35 0c |).. > 3QPh....j+.5.| > 000001d0 90 00 00 51 51 51 51 52 b1 07 6a 00 e2 fc 61 07 > |...QQQQR..j...a.| > 000001e0 1f 0f a1 0f a9 cf fa bc 00 18 00 00 0f 20 c0 25 > |............. .%| > 000001f0 ff ff ff 7f 0f 22 c0 31 c9 0f 22 d9 0f 01 15 c0 |.....". > 1..".....| > 00000200 > > Thanks and Happy New Year! Hi Jos, "dd if=/dev/zero of=/dev/ad0 count=1 oseek=1" is what you need. As you say, the BSD disklabel lives in the slice, so the one in sector 1 (counting from 0) is the stale one and the one preventing you from booting. Happy New Year to you (and Trish) too, -- Marcel Moolenaar xcllnt@mac.com From jos at catnook.com Sat Jan 3 21:57:41 2009 From: jos at catnook.com (Jos Backus) Date: Sat Jan 3 21:57:51 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> <20090101031634.GD64075@lizzy.catnook.local> Message-ID: <20090103215810.GA1527@lizzy.catnook.local> On Sat, Jan 03, 2009 at 08:30:08AM -0800, Marcel Moolenaar wrote: > "dd if=/dev/zero of=/dev/ad0 count=1 oseek=1" is what you > need. As you say, the BSD disklabel lives in the slice, > so the one in sector 1 (counting from 0) is the stale one > and the one preventing you from booting. lizzy:~# dd if=/dev/zero of=/dev/ad0 count=1 oseek=1 dd: /dev/ad0: Operation not permitted lizzy:~# sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 lizzy:~# dd if=/dev/zero of=/dev/ad0 count=1 oseek=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000164 secs (3121343 bytes/sec) lizzy:~# does the trick. Thanks Marcel! -- Jos Backus jos at catnook.com From bugmaster at FreeBSD.org Mon Jan 5 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:08:01 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200901051106.n05B6pkG002783@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 42 problems total. From mikej at paymentallianceintl.com Mon Jan 5 11:21:39 2009 From: mikej at paymentallianceintl.com (Michael Jung) Date: Mon Jan 5 11:21:45 2009 Subject: Encrypting raid5 volume with geli In-Reply-To: <917871cf0812270615j4f43ce0v497804ce5a71690f@mail.gmail.com> Message-ID: I've been on vacation and yes the new patch works fine. --mikej ________________________________ From: Ulf Lilleengen [mailto:ulf.lilleengen@gmail.com] Sent: Saturday, December 27, 2008 9:15 AM To: Michael Jung Cc: John-Mark Gurney; freebsd-geom@freebsd.org Subject: Re: Encrypting raid5 volume with geli On Fri, Dec 19, 2008 at 10:49 PM, Michael Jung wrote: FreeBSD 7.1-PRERELEASE #1: Fri Dec 19 09:04:23 EST 2008 With the new patch I can create UFS system and mount. I can also: (root@charon) /etc# geli init -P -K /root/test.key /dev/gvinum/test But when I try to attach it: (root@charon) /etc# geli attach -p -k /root/test.key /dev/gvinum/test (root@charon) /etc# mount /dev/gvinum/test.eli /mnt mount: /dev/gvinum/test.eli : Invalid argument (root@charon) /etc# Uhm, haven't you forgotten to do a newfs /dev/gvinum/test.eli before mounting it? It works fine for me when doing that first. -- Ulf Lilleengen CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From ivoras at freebsd.org Wed Jan 7 03:06:00 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jan 7 03:06:06 2009 Subject: performance problem with gstripe In-Reply-To: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> References: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> Message-ID: Joel Jacobson wrote: > i have a bit of a weird issue, which i suspect is a configuration > problem, and was looking for a little advice. i have an LSI JBOD box > with a bunch of SAS drives that i would like to gstripe together. each > drive individually seems to be able to do about 80 MB/sec streaming > write, and doing parallel dd's gives me the 160 MB/sec i would expect. > if i gstripe them together with a 256k stripe width, i only see 80 > MB/sec, though. How do you measure this? If with dd, what block size (bs) do you use? > > if, however, i newfs/mount it as ufs and then dd myself a big file, that > gets me about 120-130 MB/sec. > > why does mounting matter? I'd guess because of write caching that enables you to make use of multiple stripes at once, if your dd bs is smaller than 2*stripe size. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090107/510a15d9/signature.pgp From jjacobson at panasas.com Wed Jan 7 03:37:11 2009 From: jjacobson at panasas.com (Joel Jacobson) Date: Wed Jan 7 03:37:20 2009 Subject: performance problem with gstripe In-Reply-To: References: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> Message-ID: here's what i did: --------------------------- ca-sbox-2# foreach i (0 1) foreach? dd if=/dev/zero of=/dev/da$i bs=512k count=1024 & foreach? end [1] 5402 [2] 5403 ca-sbox-2# 1024+0 records in 1024+0 records out 536870912 bytes transferred in 4.262723 secs (125945532 bytes/sec) 1024+0 records in 1024+0 records out 536870912 bytes transferred in 4.272499 secs (125657357 bytes/sec) ca-sbox-2# gstripe create -s 262144 d0 /dev/da{0,1} ca-sbox-2# dd if=/dev/zero of=/dev/stripe/d0 bs=512k count=4096 4096+0 records in 4096+0 records out 2147483648 bytes transferred in 34.124683 secs (62930508 bytes/sec) ca-sbox-2# newfs /dev/stripe/d0 > /dev/null ca-sbox-2# mount /dev/stripe/d0 /mnt ca-sbox-2# dd if=/dev/zero of=/mnt/bigfile bs=512k count=4096 && /usr/ bin/time sync 4096+0 records in 4096+0 records out 2147483648 bytes transferred in 11.081184 secs (193795502 bytes/sec) 0.06 real 0.00 user 0.04 sys # sysctl kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.stripe.fast_failed: 0 kern.geom.stripe.maxmem: 13107200 kern.geom.stripe.fast: 1 kern.geom.stripe.debug: 0 ---------------------- - j On Jan 6, 2009, at 7:05 PM, Ivan Voras wrote: > Joel Jacobson wrote: >> i have a bit of a weird issue, which i suspect is a configuration >> problem, and was looking for a little advice. i have an LSI JBOD box >> with a bunch of SAS drives that i would like to gstripe together. >> each >> drive individually seems to be able to do about 80 MB/sec streaming >> write, and doing parallel dd's gives me the 160 MB/sec i would >> expect. >> if i gstripe them together with a 256k stripe width, i only see 80 >> MB/sec, though. > > How do you measure this? If with dd, what block size (bs) do you use? > >> >> if, however, i newfs/mount it as ufs and then dd myself a big file, >> that >> gets me about 120-130 MB/sec. >> >> why does mounting matter? > > I'd guess because of write caching that enables you to make use of > multiple stripes at once, if your dd bs is smaller than 2*stripe size. > From ivoras at freebsd.org Wed Jan 7 04:08:21 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jan 7 04:08:27 2009 Subject: performance problem with gstripe In-Reply-To: References: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> Message-ID: Joel Jacobson wrote: > here's what i did: > ca-sbox-2# dd if=/dev/zero of=/dev/stripe/d0 bs=512k count=4096 > 4096+0 records in > 4096+0 records out > 2147483648 bytes transferred in 34.124683 secs (62930508 bytes/sec) > ca-sbox-2# dd if=/dev/zero of=/mnt/bigfile bs=512k count=4096 && > /usr/bin/time sync > 4096+0 records in > 4096+0 records out > 2147483648 bytes transferred in 11.081184 secs (193795502 bytes/sec) Hmm ok, you might be hitting the MAXPHYS problem. Could you try and create your gstripe array with a stripe size of 64 kB and 32 kB and test on those ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090107/e5346e55/signature.pgp From jjacobson at panasas.com Wed Jan 7 16:44:02 2009 From: jjacobson at panasas.com (Joel Jacobson) Date: Wed Jan 7 16:44:08 2009 Subject: performance problem with gstripe In-Reply-To: References: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> Message-ID: still works badly at 64k, but works well if i use 32k (and have kern.geom.stripe.fast=1). that being said, i was only seeing 64k I/O through ufs when i was doing the 256k stripe, so im still not sure why this matters. i have a somewhat hidden agenda here, too, in that i have my own filesystem that suffers the same problem im seeing with dd. i figured there was something ufs does which i do not, and was trying to figure out what that might be. it works fine on 4.6.2 using ccd and a 256k stripe size [and i send 128k I/O requests, which is what i would prefer to see sent to the driver, rather than 64k]. - j On Jan 6, 2009, at 8:08 PM, Ivan Voras wrote: > Joel Jacobson wrote: >> here's what i did: > >> ca-sbox-2# dd if=/dev/zero of=/dev/stripe/d0 bs=512k count=4096 >> 4096+0 records in >> 4096+0 records out >> 2147483648 bytes transferred in 34.124683 secs (62930508 bytes/sec) > >> ca-sbox-2# dd if=/dev/zero of=/mnt/bigfile bs=512k count=4096 && >> /usr/bin/time sync >> 4096+0 records in >> 4096+0 records out >> 2147483648 bytes transferred in 11.081184 secs (193795502 bytes/sec) > > > Hmm ok, you might be hitting the MAXPHYS problem. Could you try and > create your gstripe array with a stripe size of 64 kB and 32 kB and > test > on those ? > From ivoras at freebsd.org Wed Jan 7 18:54:14 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jan 7 18:54:21 2009 Subject: performance problem with gstripe In-Reply-To: References: <4AD370A6-2226-442F-BD80-8CFD4045B094@panasas.com> Message-ID: Joel Jacobson wrote: > still works badly at 64k, but works well if i use 32k (and have > kern.geom.stripe.fast=1). that being said, i was only seeing 64k I/O > through ufs when i was doing the 256k stripe, so im still not sure why > this matters. You have robably stumbled on the group of problems collectively knows as "the MAXPHYS problem". This is what's happening: Many disk drivers in FreeBSD were first created when the controllers and the motherboards didn't support DMA larger than 64 kB. In addition to that there's a hard limit on IO request sizes set to 128 kB (the MAXPHYS kernel option) but which is not often reached. Thus, the maximum IO size that can reach a single drive is 64 kB and this limit is propagated in unclear ways back to UFS. If you have a stripe size larger or equal to then 64 kB then in no way can the IO request be split between two drives - you get the performance of a single drive. If the stripe size is smaller, the IO request can be split between the drives and you get better performance. All this discussion maps 1:1 to the "dd" utility accessing the raw device (/dev/something). In FreeBSD, raw device access is not buffered, so what the dd requests, the drive delivers, in exactly the same way it was requested, chopped into 64 kB pieces if needed. The reason why UFS is better is that it asynchronously fills a queue (bioq) with requests, which are sent to the device in the same way, asynchronously, so even if a single write cannot span multiple stripes, there will be many writes queued which can be done in parallel. This works upto a point, and still breaks down for high loads, large number of devices, really large stripe sizes etc. The problem is annoying but not serious if you know about it. It limits the sequential performance, but if you'd tried a random IO benchmark that can do parallel IO itself (try http://arctic.org/~dean/randomio/) on the device and uses small-ish block sizes, you'd probably find that you still get better performance. > i have a somewhat hidden agenda here, too, in that i have my own > filesystem that suffers the same problem im seeing with dd. i figured I'm interested in file systems so I'd be happy to test it for you. :) > there was something ufs does which i do not, and was trying to figure > out what that might be. it works fine on 4.6.2 using ccd and a 256k > stripe size [and i send 128k I/O requests, which is what i would prefer > to see sent to the driver, rather than 64k]. I don't know how CCD works - maybe it can queue IO in parallel? Maybe 4.x still had cached block devices (they were thrown out at some point in time but I don't know when - see http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html)? I think there were so many changes in between 4.x and 8-CURRENT that you'll need to find someone who has worked specifically on VFS to explain exactly what is going on. Contact me if you need pointers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090107/f34a99c2/signature.pgp From kgysmits at gmail.com Thu Jan 8 20:02:00 2009 From: kgysmits at gmail.com (Koen Smits) Date: Thu Jan 8 20:02:06 2009 Subject: mirror a GPT partition, what label? Message-ID: Hi, My new NAS will have the following disk layout: ad0 -> 2gb CF ad4 -> 1TB WD Green ad6 -> 1TB WD Green The CF will boot the rig, the 2 1TB disks will be mirrored with ZFS. No problem there, did it before. The problem lies in the swap space, which I want to place at the first gigabyte of the 1TB disks. The disks will use GPT layout. I want to gmirror the first 1GB partition on both disks. How should I accomplish this? Is it sufficient to label both partitions 'freebsd'? According to man 8 gpart 'freebsd' should not be used when using GPT. Any insight would be appreciated. -Koen From brooks at freebsd.org Thu Jan 8 20:37:33 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jan 8 20:37:47 2009 Subject: mirror a GPT partition, what label? In-Reply-To: References: Message-ID: <20090108202122.GA72107@lor.one-eyed-alien.net> On Thu, Jan 08, 2009 at 08:35:25PM +0100, Koen Smits wrote: > Hi, > > My new NAS will have the following disk layout: > ad0 -> 2gb CF > ad4 -> 1TB WD Green > ad6 -> 1TB WD Green > > The CF will boot the rig, the 2 1TB disks will be mirrored with ZFS. No > problem there, did it before. > The problem lies in the swap space, which I want to place at the first > gigabyte of the 1TB disks. The disks will use GPT layout. I want to gmirror > the first 1GB partition on both disks. How should I accomplish this? Is it > sufficient to label both partitions 'freebsd'? According to man 8 gpart > 'freebsd' should not be used when using GPT. Any insight would be > appreciated. gmirror shouldn't care what the underlying type is though using freebsd may confuse future tools that expect to find a bsdlabel on the partition. That being said, I'd be pretty surprised if mirroring your swap partition did anything other than causing pain and preventing coredumps. You can have quite a number of swap partitions so why not just add both and have twice as much (plus the chance to successfully produce a core dump if you need to debug something). -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090108/99b45a83/attachment.pgp From kgysmits at gmail.com Thu Jan 8 20:42:43 2009 From: kgysmits at gmail.com (Koen Smits) Date: Thu Jan 8 20:42:49 2009 Subject: mirror a GPT partition, what label? In-Reply-To: <20090108202122.GA72107@lor.one-eyed-alien.net> References: <20090108202122.GA72107@lor.one-eyed-alien.net> Message-ID: On Thu, Jan 8, 2009 at 21:21, Brooks Davis wrote: > On Thu, Jan 08, 2009 at 08:35:25PM +0100, Koen Smits wrote: > > Hi, > > > > My new NAS will have the following disk layout: > > ad0 -> 2gb CF > > ad4 -> 1TB WD Green > > ad6 -> 1TB WD Green > > > > The CF will boot the rig, the 2 1TB disks will be mirrored with ZFS. No > > problem there, did it before. > > The problem lies in the swap space, which I want to place at the first > > gigabyte of the 1TB disks. The disks will use GPT layout. I want to > gmirror > > the first 1GB partition on both disks. How should I accomplish this? Is > it > > sufficient to label both partitions 'freebsd'? According to man 8 gpart > > 'freebsd' should not be used when using GPT. Any insight would be > > appreciated. > > gmirror shouldn't care what the underlying type is though using freebsd > may confuse future tools that expect to find a bsdlabel on the partition. > That being said, I'd be pretty surprised if mirroring your swap > partition did anything other than causing pain and preventing coredumps. > You can have quite a number of swap partitions so why not just add both > and have twice as much (plus the chance to successfully produce a core > dump if you need to debug something). > > -- Brooks > Well, the theory was that if I lose a disk, the system wouldn't go flat on its face because the swap space suddenly disappeared. So there is no recommended procedure for using GPT partitions for gmirror/gstripe? From xcllnt at mac.com Thu Jan 8 21:06:45 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jan 8 21:06:52 2009 Subject: mirror a GPT partition, what label? In-Reply-To: References: Message-ID: <5D9E8EEA-AE0D-42F6-96A9-A9137C39C4FA@mac.com> On Jan 8, 2009, at 11:35 AM, Koen Smits wrote: > Hi, > > My new NAS will have the following disk layout: > ad0 -> 2gb CF > ad4 -> 1TB WD Green > ad6 -> 1TB WD Green > > The CF will boot the rig, the 2 1TB disks will be mirrored with ZFS. > No > problem there, did it before. > The problem lies in the swap space, which I want to place at the first > gigabyte of the 1TB disks. The disks will use GPT layout. I want to > gmirror > the first 1GB partition on both disks. How should I accomplish this? > Is it > sufficient to label both partitions 'freebsd'? According to man 8 > gpart > 'freebsd' should not be used when using GPT. Any insight would be > appreciated. Use "freebsd-swap" as the partition type. -- Marcel Moolenaar xcllnt@mac.com From kgysmits at gmail.com Thu Jan 8 22:18:20 2009 From: kgysmits at gmail.com (Koen Smits) Date: Thu Jan 8 22:18:28 2009 Subject: mirror a GPT partition, what label? In-Reply-To: <5D9E8EEA-AE0D-42F6-96A9-A9137C39C4FA@mac.com> References: <5D9E8EEA-AE0D-42F6-96A9-A9137C39C4FA@mac.com> Message-ID: Ok, let's give that a shot then. I still don't see the big picture here, but if it works I guess that's fine with me too. On Thu, Jan 8, 2009 at 22:06, Marcel Moolenaar wrote: > > On Jan 8, 2009, at 11:35 AM, Koen Smits wrote: > > Hi, >> >> My new NAS will have the following disk layout: >> ad0 -> 2gb CF >> ad4 -> 1TB WD Green >> ad6 -> 1TB WD Green >> >> The CF will boot the rig, the 2 1TB disks will be mirrored with ZFS. No >> problem there, did it before. >> The problem lies in the swap space, which I want to place at the first >> gigabyte of the 1TB disks. The disks will use GPT layout. I want to >> gmirror >> the first 1GB partition on both disks. How should I accomplish this? Is it >> sufficient to label both partitions 'freebsd'? According to man 8 gpart >> 'freebsd' should not be used when using GPT. Any insight would be >> appreciated. >> > > Use "freebsd-swap" as the partition type. > > -- > Marcel Moolenaar > xcllnt@mac.com > > > > From rabe at uugrn.org Sat Jan 10 13:19:14 2009 From: rabe at uugrn.org (Raphael Becker) Date: Sat Jan 10 13:19:21 2009 Subject: fsck order/parallel on /dev/ufs/* Message-ID: <20090110205810.GA11441@ma.sigsys.de> Hi *, fsck(8) tell me about how to fsck filesystems parallel on a "per drive" basis: In preen mode, after pass 1 completes, all remaining file systems are checked, in pass number order running one process per disk drive in par- allel for each pass number in increasing order. In other words: In preen mode all pass 1 partitions are checked sequen- tially. Next all pass 2 partitions are checked in parallel, one process per disk drive. Next all pass 3 partitions are checked in parallel, one process per disk drive. etc. The disk drive containing each file system is inferred from the shortest prefix of the device name that ends in a digit; the remaining characters are assumed to be the partition and slice designators. my /etc/fstab looks like this: /dev/ufs/ROOT / ufs rw 1 1 /dev/ufs/VAR /var ufs rw 2 2 /dev/ufs/USR /usr ufs rw 2 2 /dev/ufs/DATA2 /data ufs rw 2 2 /dev/ufs/SPACE /space ufs rw 2 2 /dev/ufs/MULTIMEDIA /data/multimedia ufs rw 2 2 /dev/ufs/HOME2 /home ufs rw 0 0 /dev/ufs/PRIVATE /private ufs rw 0 0 Some of the filesystems are on top of a partition/label, others are on top of a geli device, others may be md-devices etc. Is fsck able to find out the "real hardware"? Is fsck "geom-aware"? Regards Raphael PS: $ uname -srm FreeBSD 7.1-RELEASE i386 -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090110/7550650d/attachment.pgp From phk at phk.freebsd.dk Sat Jan 10 13:27:33 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat Jan 10 13:27:39 2009 Subject: fsck order/parallel on /dev/ufs/* In-Reply-To: Your message of "Sat, 10 Jan 2009 21:58:10 +0100." <20090110205810.GA11441@ma.sigsys.de> Message-ID: <95784.1231622850@critter.freebsd.dk> In message <20090110205810.GA11441@ma.sigsys.de>, Raphael Becker writes: >Is fsck able to find out the "real hardware"? Is fsck "geom-aware"? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bugmaster at FreeBSD.org Mon Jan 12 03:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:07:59 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200901121106.n0CB6pLJ091985@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 42 problems total. From rizzo at iet.unipi.it Tue Jan 13 04:34:53 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Jan 13 04:34:59 2009 Subject: geom 'taste' vs. manual creation ? Message-ID: <20090113122111.GA89189@onelab2.iet.unipi.it> geom(4) says: A geom which came into being as a result of a normal taste operation should self-destruct... Now I wonder: does the GEOM infrastructure record whether a geom has been created by a 'taste' call, or manually through a 'geom xxx create ..', or this info should be managed directly by the individual implementation ? cheers luigi From rizzo at iet.unipi.it Tue Jan 13 04:51:23 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Jan 13 04:51:29 2009 Subject: best common practice to handle variable provider names ? Message-ID: <20090113125631.GA90320@onelab2.iet.unipi.it> Hi, I would like some advice on the following issue. If i add some geom modules on my disks, the "device names" to be used in /etc/fstab change accordingly to which nodes are present. Is there a way to hide these changes so that /etc/fstab always (within reasonable) has the same entries no matter what geom nodes I am using ? E.g. right now I am playing with a disk scheduler module, so if the scheduler module is present I would like to use ad0-sched-s1, whereas I should fall back to ad0s1 if the scheduler is not loaded. How do I handle this with a single entry in /etc/fstab ? I don't think i can assign a NULL name to a geom class, right ? (or, maybe I can but then userland programs have a hard time indicating the provider they want to refer to) cheers luigi From ivoras at freebsd.org Tue Jan 13 05:10:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Jan 13 05:10:14 2009 Subject: geom 'taste' vs. manual creation ? In-Reply-To: <20090113122111.GA89189@onelab2.iet.unipi.it> References: <20090113122111.GA89189@onelab2.iet.unipi.it> Message-ID: Luigi Rizzo wrote: > geom(4) says: > > A geom which came into being as a result of a normal taste operation > should self-destruct... > > Now I wonder: > does the GEOM infrastructure record whether a geom has been created > by a 'taste' call, or manually through a 'geom xxx create ..', or > this info should be managed directly by the individual implementation ? I'm not sure if this is what you're asking, but when a new geom is created (for example by a complex / transformation GEOM class...), it is automatically tested again, so why would it be different now? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090113/02a36022/signature.pgp From vince at unsane.co.uk Tue Jan 13 05:41:15 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Tue Jan 13 05:41:22 2009 Subject: best common practice to handle variable provider names ? In-Reply-To: <20090113125631.GA90320@onelab2.iet.unipi.it> References: <20090113125631.GA90320@onelab2.iet.unipi.it> Message-ID: <496C99F8.4080307@unsane.co.uk> Luigi Rizzo wrote: > Hi, > I would like some advice on the following issue. > > If i add some geom modules on my disks, the "device names" to be used > in /etc/fstab change accordingly to which nodes are present. > > Is there a way to hide these changes so that /etc/fstab always > (within reasonable) has the same entries no matter what geom nodes > I am using ? > you could try using labels, I believe others have used them with some success although it sound like you may be doing more complex stuff than others i've seen using them. I have one mounted in my fstab: /dev/ufs/SCRATCH /usr/scratch ufs rw,noatime 2 2 which works for me (label was added using tunefs.) have a look at glabel(8) too see it it could do what you need. Vince > > E.g. right now I am playing with a disk scheduler module, so if the > scheduler module is present I would like to use ad0-sched-s1, whereas > I should fall back to ad0s1 if the scheduler is not loaded. > > How do I handle this with a single entry in /etc/fstab ? > I don't think i can assign a NULL name to a geom class, right ? > (or, maybe I can but then userland programs have a hard time > indicating the provider they want to refer to) > > cheers > luigi > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > From rizzo at iet.unipi.it Tue Jan 13 06:16:34 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Jan 13 06:16:41 2009 Subject: geom 'taste' vs. manual creation ? In-Reply-To: <20090113122111.GA89189@onelab2.iet.unipi.it> References: <20090113122111.GA89189@onelab2.iet.unipi.it> Message-ID: <20090113142143.GA92704@onelab2.iet.unipi.it> Ivan Voras said: > On Tue, Jan 13, 2009 at 01:21:11PM +0100, Luigi Rizzo wrote: > > geom(4) says: > > > > A geom which came into being as a result of a normal taste operation > > should self-destruct... > > > > Now I wonder: > > does the GEOM infrastructure record whether a geom has been created > > by a 'taste' call, or manually through a 'geom xxx create ..', or > > this info should be managed directly by the individual implementation ? > > I'm not sure if this is what you're asking, but when a new geom is > created (for example by a complex / transformation GEOM class...), it is > automatically tested again, so why would it be different now? i am looking at the module unloading (i.e.. destroy) case. I have a geom_sched module that uses the 'taste' method to automatically create instances to selected devices (listed in a kenv variable for what matters). The user can still manually issue "geom sched create ..." on other providers. When I unload the module, right now i call destroy() on all instances (including those created manually), but i wonder if the autodestruction should be limited to only the auto-created entities, as the manpage seems to suggest, and in this case whether there is any flag that records manual vs. automatic creation. cheers luigi From rizzo at iet.unipi.it Tue Jan 13 06:26:08 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Jan 13 06:26:15 2009 Subject: geom 'taste' vs. manual creation ? In-Reply-To: <29945.1231856558@critter.freebsd.dk> References: <20090113122111.GA89189@onelab2.iet.unipi.it> <29945.1231856558@critter.freebsd.dk> Message-ID: <20090113143116.GA93244@onelab2.iet.unipi.it> On Tue, Jan 13, 2009 at 02:22:38PM +0000, Poul-Henning Kamp wrote: > In message <20090113122111.GA89189@onelab2.iet.unipi.it>, Luigi Rizzo writes: > >geom(4) says: > > > > A geom which came into being as a result of a normal taste operation > > should self-destruct... > > > >Now I wonder: > >does the GEOM infrastructure record whether a geom has been created > >by a 'taste' call, or manually through a 'geom xxx create ..', or > >this info should be managed directly by the individual implementation ? > > No, there is no difference on how a geom is created. The above > statement indicates a level of magic that is not really there, all > the geoms get orphaned the same way. ok thanks luigi From phk at phk.freebsd.dk Tue Jan 13 06:41:32 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue Jan 13 06:41:39 2009 Subject: geom 'taste' vs. manual creation ? In-Reply-To: Your message of "Tue, 13 Jan 2009 13:21:11 +0100." <20090113122111.GA89189@onelab2.iet.unipi.it> Message-ID: <29945.1231856558@critter.freebsd.dk> In message <20090113122111.GA89189@onelab2.iet.unipi.it>, Luigi Rizzo writes: >geom(4) says: > > A geom which came into being as a result of a normal taste operation > should self-destruct... > >Now I wonder: >does the GEOM infrastructure record whether a geom has been created >by a 'taste' call, or manually through a 'geom xxx create ..', or >this info should be managed directly by the individual implementation ? No, there is no difference on how a geom is created. The above statement indicates a level of magic that is not really there, all the geoms get orphaned the same way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bjmccann at gmail.com Wed Jan 14 13:37:32 2009 From: bjmccann at gmail.com (Brian McCann) Date: Wed Jan 14 13:37:38 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> Message-ID: <2b5f066d0901141331n150db544ua4256f3485be522b@mail.gmail.com> On Wed, Jan 14, 2009 at 4:23 PM, Brian McCann wrote: > > Does anyone have any ideas here? I assumed gjournal would play nice > with any file system. But clearly not. After I clear the journal off > of /dev/gvinum/array1, I can do a newfs on it (/dev/gvinum/array1) > without the journal fine...so that tests that the RAID5 is ok. Anyone > havve any ideas? > > Thanks! > --Brian > I also just got the idea to try turning off write caching on the ata controller...no help. Just thought I'd drop that out there if that clues in on something. --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From bjmccann at gmail.com Wed Jan 14 13:52:09 2009 From: bjmccann at gmail.com (Brian McCann) Date: Wed Jan 14 13:52:18 2009 Subject: gvinum & gjournal Message-ID: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> Hi all. I'm cross-posting this since I figure I'll have better luck finding someone who's done this before... I'm building a system that has 4 1.5TB Seagate SATA drives in it. I've setup gvinum and made mirrors for my OS partitions, and a raid5 plex for a big data partition. I'm trying to get gjournal to run on the raid5 volume...but it's doing stuff that isn't expected. First, here's my gvinum config for the array: ---snip--- drive e0 device /dev/ad8s1g drive e1 device /dev/ad10s1g drive e2 device /dev/ad12s1g drive e3 device /dev/ad14s1g volume array1 plex org raid5 128k sd drive e0 sd drive e1 sd drive e2 sd drive e3 ---/snip--- Now...according to the handbook. the volume it creates is essentially a disk drive. So...I run the following gjournal commands to make the journal, and here's what I get: ---snip--- # gjournal label /dev/gvinum/array1 GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains data. GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains journal. GEOM_JOURNAL: Journal gvinum/plex/array1.p0 clean. GEOM_JOURNAL: BIO_FLUSH not supported by gvinum/plex/array1.p0. # gjournal list Geom name: gjournal 4267655417 ID: 4267655417 Providers: 1. Name: gvinum/plex/array1.p0.journal Mediasize: 4477282549248 (4.1T) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: gvinum/plex/array1.p0 Mediasize: 4478356291584 (4.1T) Sectorsize: 512 Mode: r1w1e1 Jend: 4478356291072 Jstart: 4477282549248 Role: Data,Journal --/snip--- So...why is it even touching the plex p0? I figured it would, just like on a disk, if I gave it da0, create da0.journal. Moving on, if I try to newfs the journal, which is now "gvinum/plex/array1.p0.journal", I get: ---snip--- # newfs -J /dev/gvinum/plex/array1.p0.journal /dev/gvinum/plex/array1.p0.journal: 4269869.4MB (8744692476 sectors) block size 16384, fragment size 2048 using 23236 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. newfs: can't read old UFS1 superblock: end of file from block device: No such file or directory ---/snip--- Followed by a panic and reboot: ---snip--- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d8d440 stack pointer = 0x28:0xd4e25c44 frame pointer = 0x28:0xd4e25cf4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 47 (gv_p array1.p0) trap number = 12 panic: page fault cpuid = 0 Uptime: 14m38s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort ---/snip--- Next...I destroyed/cleared/stoped/etc the journal to start fresh, made a new one...it created the same thing (gvinum/plex/array1.p0.journal)...I then rebooted, loaded the gjournal module, and I now see gvinum/array1.journal as the provider, and the provider inside plex is gone. I then run my newfs (newfs -J /dev/gvinum/array1.journal) , and I get ---snip--- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d8eec5 stack pointer = 0x28:0xd4e2ecbc frame pointer = 0x28:0xd4e2ecf4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 50 (gv_v array1) trap number = 12 panic: page fault cpuid = 0 Uptime: 8m18s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort ---/snip--- Does anyone have any ideas here? I assumed gjournal would play nice with any file system. But clearly not. After I clear the journal off of /dev/gvinum/array1, I can do a newfs on it (/dev/gvinum/array1) without the journal fine...so that tests that the RAID5 is ok. Anyone havve any ideas? Thanks! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From rizzo at iet.unipi.it Thu Jan 15 00:05:15 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 15 00:05:22 2009 Subject: recursion check in 'taste' functions ? In-Reply-To: <20090113122111.GA89189@onelab2.iet.unipi.it> References: <20090113122111.GA89189@onelab2.iet.unipi.it> Message-ID: <20090115081025.GA76218@onelab2.iet.unipi.it> Hi, I notice that the check to prevent recursion in the 'taste' function is always based on a string comparison, written in various forms, e.g., if (strcmp(pp->geom->class->name, mp->name) == 0) return (NULL); ... if (!strcmp(pp->geom->class->name, MBR_CLASS_NAME)) return (NULL); Wouldn't the following be more efficient (and perhaps correct) ? if (pp->geom->class == mp) return (NULL); This is because pp->geom->class is always initialized with a pointer to the class descriptor, and I guess it cannot be different... cheers luigi From ota at j.email.ne.jp Thu Jan 15 00:15:13 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Thu Jan 15 00:15:20 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> Message-ID: <20090115025645.21ad2185.ota@j.email.ne.jp> Try 'dd if=/dev/zero of=/dev/gvinum/array1 bs=1M count=10'. Zero clearing the head of disk helps sometimes. You may want to add a new disk or create a partition for the journaling area. Journaling on raid5 sounds overkill. Hiro On Wed, 14 Jan 2009 16:23:30 -0500 "Brian McCann" wrote: > Hi all. I'm cross-posting this since I figure I'll have better luck > finding someone who's done this before... > > I'm building a system that has 4 1.5TB Seagate SATA drives in it. > I've setup gvinum and made mirrors for my OS partitions, and a raid5 > plex for a big data partition. I'm trying to get gjournal to run on > the raid5 volume...but it's doing stuff that isn't expected. First, > here's my gvinum config for the array: > > ---snip--- > drive e0 device /dev/ad8s1g > drive e1 device /dev/ad10s1g > drive e2 device /dev/ad12s1g > drive e3 device /dev/ad14s1g > volume array1 > plex org raid5 128k > sd drive e0 > sd drive e1 > sd drive e2 > sd drive e3 > ---/snip--- > > Now...according to the handbook. the volume it creates is essentially > a disk drive. So...I run the following gjournal commands to make the > journal, and here's what I get: > > ---snip--- > # gjournal label /dev/gvinum/array1 > GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains data. > GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains journal. > GEOM_JOURNAL: Journal gvinum/plex/array1.p0 clean. > GEOM_JOURNAL: BIO_FLUSH not supported by gvinum/plex/array1.p0. > # gjournal list > Geom name: gjournal 4267655417 > ID: 4267655417 > Providers: > 1. Name: gvinum/plex/array1.p0.journal > Mediasize: 4477282549248 (4.1T) > Sectorsize: 512 > Mode: r0w0e0 > Consumers: > 1. Name: gvinum/plex/array1.p0 > Mediasize: 4478356291584 (4.1T) > Sectorsize: 512 > Mode: r1w1e1 > Jend: 4478356291072 > Jstart: 4477282549248 > Role: Data,Journal > --/snip--- > > So...why is it even touching the plex p0? I figured it would, just > like on a disk, if I gave it da0, create da0.journal. Moving on, if I > try to newfs the journal, which is now > "gvinum/plex/array1.p0.journal", I get: > > ---snip--- > # newfs -J /dev/gvinum/plex/array1.p0.journal > /dev/gvinum/plex/array1.p0.journal: 4269869.4MB (8744692476 sectors) block size > 16384, fragment size 2048 > using 23236 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. > newfs: can't read old UFS1 superblock: end of file from block device: > No such file or directory > ---/snip--- > > Followed by a panic and reboot: > > ---snip--- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0d8d440 > stack pointer = 0x28:0xd4e25c44 > frame pointer = 0x28:0xd4e25cf4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 47 (gv_p array1.p0) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 14m38s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort > ---/snip--- > > Next...I destroyed/cleared/stoped/etc the journal to start fresh, made > a new one...it created the same thing > (gvinum/plex/array1.p0.journal)...I then rebooted, loaded the gjournal > module, and I now see gvinum/array1.journal as the provider, and the > provider inside plex is gone. I then run my newfs (newfs -J > /dev/gvinum/array1.journal) , and I get > > ---snip--- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x1c > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0d8eec5 > stack pointer = 0x28:0xd4e2ecbc > frame pointer = 0x28:0xd4e2ecf4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 50 (gv_v array1) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 8m18s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort > > ---/snip--- > > Does anyone have any ideas here? I assumed gjournal would play nice > with any file system. But clearly not. After I clear the journal off > of /dev/gvinum/array1, I can do a newfs on it (/dev/gvinum/array1) > without the journal fine...so that tests that the RAID5 is ok. Anyone > havve any ideas? > > Thanks! > --Brian > > -- > _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ > Brian McCann > > "I don't have to take this abuse from you -- I've got hundreds of > people waiting to abuse me." > -- Bill Murray, "Ghostbusters" > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From ulf.lilleengen at gmail.com Thu Jan 15 00:33:47 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Thu Jan 15 00:33:54 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> Message-ID: <20090115093352.GB1821@carrot> On Wed, Jan 14, 2009 at 04:23:30PM -0500, Brian McCann wrote: > Hi all. I'm cross-posting this since I figure I'll have better luck > finding someone who's done this before... > > I'm building a system that has 4 1.5TB Seagate SATA drives in it. > I've setup gvinum and made mirrors for my OS partitions, and a raid5 > plex for a big data partition. I'm trying to get gjournal to run on > the raid5 volume...but it's doing stuff that isn't expected. First, > here's my gvinum config for the array: > > ---snip--- > drive e0 device /dev/ad8s1g > drive e1 device /dev/ad10s1g > drive e2 device /dev/ad12s1g > drive e3 device /dev/ad14s1g > volume array1 > plex org raid5 128k > sd drive e0 > sd drive e1 > sd drive e2 > sd drive e3 > ---/snip--- > > Now...according to the handbook. the volume it creates is essentially > a disk drive. So...I run the following gjournal commands to make the > journal, and here's what I get: > > ---snip--- > # gjournal label /dev/gvinum/array1 > GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains data. > GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains journal. > GEOM_JOURNAL: Journal gvinum/plex/array1.p0 clean. > GEOM_JOURNAL: BIO_FLUSH not supported by gvinum/plex/array1.p0. > # gjournal list > Geom name: gjournal 4267655417 > ID: 4267655417 > Providers: > 1. Name: gvinum/plex/array1.p0.journal > Mediasize: 4477282549248 (4.1T) > Sectorsize: 512 > Mode: r0w0e0 > Consumers: > 1. Name: gvinum/plex/array1.p0 > Mediasize: 4478356291584 (4.1T) > Sectorsize: 512 > Mode: r1w1e1 > Jend: 4478356291072 > Jstart: 4477282549248 > Role: Data,Journal > --/snip--- > > So...why is it even touching the plex p0? I figured it would, just > like on a disk, if I gave it da0, create da0.journal. Moving on, if I > try to newfs the journal, which is now > "gvinum/plex/array1.p0.journal", I get: > Hi, It think that it touches it because the .p0 contains the gjournal metadata in the same way that the volume does, so gjournal attaches to that before the volume. One problem is that gjournal attaches to the "wrong" provider, but it's also silly that the provider is exposed in the first place. A fix for this is in a newer version of gvinum (as the plex is not exposed) if you're willing to try. -- Ulf Lilleengen From bjmccann at gmail.com Thu Jan 15 04:10:40 2009 From: bjmccann at gmail.com (Brian McCann) Date: Thu Jan 15 04:10:52 2009 Subject: gvinum & gjournal In-Reply-To: <20090115025645.21ad2185.ota@j.email.ne.jp> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> Message-ID: <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> On Thu, Jan 15, 2009 at 2:56 AM, Yoshihiro Ota wrote: > Try 'dd if=/dev/zero of=/dev/gvinum/array1 bs=1M count=10'. > > Zero clearing the head of disk helps sometimes. > > You may want to add a new disk or create a partition for the journaling > area. Journaling on raid5 sounds overkill. > > Hiro Tried that...no help. Sorry...left that out of my original overview. I'm doing journaling so that I theoretically never have to fsck. It's a 4-drive Intel appliance, SS4200-EHW, so adding a disk for the journal is out of the question. It's only got 512MB ram ATM, (2GB max), so even fscking something that large (4.1T) could potentially fill up the RAM, not to mention it'd take hours. Thanks for the input though! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From bjmccann at gmail.com Thu Jan 15 04:14:27 2009 From: bjmccann at gmail.com (Brian McCann) Date: Thu Jan 15 04:14:35 2009 Subject: gvinum & gjournal In-Reply-To: <20090115093352.GB1821@carrot> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115093352.GB1821@carrot> Message-ID: <2b5f066d0901150414jc5dedecp83747bac1915057a@mail.gmail.com> On Thu, Jan 15, 2009 at 4:33 AM, Ulf Lilleengen wrote: > Hi, > > It think that it touches it because the .p0 contains the gjournal metadata in > the same way that the volume does, so gjournal attaches to that before the > volume. One problem is that gjournal attaches to the "wrong" provider, but > it's also silly that the provider is exposed in the first place. A fix for > this is in a newer version of gvinum (as the plex is not exposed) if you're > willing to try. > > -- > Ulf Lilleengen > At this point, I'm willing to try anything, but preferably something that's stable since this will be done to at least 15 identical devices and sent out to various places, so I won't have physical access to the machines if something were to go wrong. I looked into graid3 and booting off of a DOM/Flash card, but since I have 4 drives, that won't work since graid3 requires 2N+1 drives. The stuff I've found on graid5 seems to say that it's all still really experimental and has some bugs in it still. :( That said...if you've got it, I'll try it. :) Thanks, --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From ivoras at freebsd.org Thu Jan 15 05:22:37 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jan 15 05:22:45 2009 Subject: gvinum & gjournal In-Reply-To: <20090115093352.GB1821@carrot> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115093352.GB1821@carrot> Message-ID: Ulf Lilleengen wrote: > On Wed, Jan 14, 2009 at 04:23:30PM -0500, Brian McCann wrote: >> Hi all. I'm cross-posting this since I figure I'll have better luck >> finding someone who's done this before... >> >> I'm building a system that has 4 1.5TB Seagate SATA drives in it. >> I've setup gvinum and made mirrors for my OS partitions, and a raid5 >> plex for a big data partition. I'm trying to get gjournal to run on >> the raid5 volume...but it's doing stuff that isn't expected. First, >> here's my gvinum config for the array: >> >> ---snip--- >> drive e0 device /dev/ad8s1g >> drive e1 device /dev/ad10s1g >> drive e2 device /dev/ad12s1g >> drive e3 device /dev/ad14s1g >> volume array1 >> plex org raid5 128k >> sd drive e0 >> sd drive e1 >> sd drive e2 >> sd drive e3 >> ---/snip--- >> >> Now...according to the handbook. the volume it creates is essentially >> a disk drive. So...I run the following gjournal commands to make the >> journal, and here's what I get: >> >> ---snip--- >> # gjournal label /dev/gvinum/array1 >> GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains data. >> GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains journal. >> GEOM_JOURNAL: Journal gvinum/plex/array1.p0 clean. >> GEOM_JOURNAL: BIO_FLUSH not supported by gvinum/plex/array1.p0. >> # gjournal list >> Geom name: gjournal 4267655417 >> ID: 4267655417 >> Providers: >> 1. Name: gvinum/plex/array1.p0.journal >> Mediasize: 4477282549248 (4.1T) >> Sectorsize: 512 >> Mode: r0w0e0 >> Consumers: >> 1. Name: gvinum/plex/array1.p0 >> Mediasize: 4478356291584 (4.1T) >> Sectorsize: 512 >> Mode: r1w1e1 >> Jend: 4478356291072 >> Jstart: 4477282549248 >> Role: Data,Journal >> --/snip--- >> >> So...why is it even touching the plex p0? I figured it would, just >> like on a disk, if I gave it da0, create da0.journal. Moving on, if I >> try to newfs the journal, which is now >> "gvinum/plex/array1.p0.journal", I get: >> > Hi, > > It think that it touches it because the .p0 contains the gjournal metadata in > the same way that the volume does, so gjournal attaches to that before the > volume. One problem is that gjournal attaches to the "wrong" provider, but > it's also silly that the provider is exposed in the first place. A fix for > this is in a newer version of gvinum (as the plex is not exposed) if you're > willing to try. > A simpler fix is to use the "-h" - "hardcode provider name" switch to the "gjournal label" command (see the man page). But I agree, some fixes I saw you create for gvinum recently look important :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090115/7a8e9795/signature.pgp From ulf.lilleengen at gmail.com Thu Jan 15 08:32:42 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Thu Jan 15 08:32:54 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901150414jc5dedecp83747bac1915057a@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115093352.GB1821@carrot> <2b5f066d0901150414jc5dedecp83747bac1915057a@mail.gmail.com> Message-ID: <20090115173248.GA1234@carrot> On tor, jan 15, 2009 at 07:14:25am -0500, Brian McCann wrote: > On Thu, Jan 15, 2009 at 4:33 AM, Ulf Lilleengen > wrote: > > Hi, > > > > It think that it touches it because the .p0 contains the gjournal metadata in > > the same way that the volume does, so gjournal attaches to that before the > > volume. One problem is that gjournal attaches to the "wrong" provider, but > > it's also silly that the provider is exposed in the first place. A fix for > > this is in a newer version of gvinum (as the plex is not exposed) if you're > > willing to try. > > > > -- > > Ulf Lilleengen > > > > At this point, I'm willing to try anything, but preferably something > that's stable since this will be done to at least 15 identical devices > and sent out to various places, so I won't have physical access to the > machines if something were to go wrong. I looked into graid3 and > booting off of a DOM/Flash card, but since I have 4 drives, that won't > work since graid3 requires 2N+1 drives. The stuff I've found on > graid5 seems to say that it's all still really experimental and has > some bugs in it still. :( > Well, if you have the choice between and graid5 and gvinum I'd might go with graid5. It's not included in head(yet) but from what I've read on the mailinglist it seems to work (also included in FreeNAS). But I can't really say anything as I've not tried it much. If you want to try the gvinum version in progress (quite stable, although a few knits for advanced usage) can be found here: http://svn.freebsd.org/base/projects/gvinum Should work on both HEAD and RELENG_7. -- Ulf Lilleengen From ulf.lilleengen at gmail.com Thu Jan 15 08:57:00 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Thu Jan 15 08:57:12 2009 Subject: gvinum & gjournal In-Reply-To: References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115093352.GB1821@carrot> Message-ID: <20090115175704.GB1234@carrot> On Thu, Jan 15, 2009 at 02:22:13PM +0100, Ivan Voras wrote: > Ulf Lilleengen wrote: > > On Wed, Jan 14, 2009 at 04:23:30PM -0500, Brian McCann wrote: > >> Hi all. I'm cross-posting this since I figure I'll have better luck > >> finding someone who's done this before... > >> > >> I'm building a system that has 4 1.5TB Seagate SATA drives in it. > >> I've setup gvinum and made mirrors for my OS partitions, and a raid5 > >> plex for a big data partition. I'm trying to get gjournal to run on > >> the raid5 volume...but it's doing stuff that isn't expected. First, > >> here's my gvinum config for the array: > >> > >> ---snip--- > >> drive e0 device /dev/ad8s1g > >> drive e1 device /dev/ad10s1g > >> drive e2 device /dev/ad12s1g > >> drive e3 device /dev/ad14s1g > >> volume array1 > >> plex org raid5 128k > >> sd drive e0 > >> sd drive e1 > >> sd drive e2 > >> sd drive e3 > >> ---/snip--- > >> > >> Now...according to the handbook. the volume it creates is essentially > >> a disk drive. So...I run the following gjournal commands to make the > >> journal, and here's what I get: > >> > >> ---snip--- > >> # gjournal label /dev/gvinum/array1 > >> GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains data. > >> GEOM_JOURNAL: Journal 4267655417: gvinum/plex/array1.p0 contains journal. > >> GEOM_JOURNAL: Journal gvinum/plex/array1.p0 clean. > >> GEOM_JOURNAL: BIO_FLUSH not supported by gvinum/plex/array1.p0. > >> # gjournal list > >> Geom name: gjournal 4267655417 > >> ID: 4267655417 > >> Providers: > >> 1. Name: gvinum/plex/array1.p0.journal > >> Mediasize: 4477282549248 (4.1T) > >> Sectorsize: 512 > >> Mode: r0w0e0 > >> Consumers: > >> 1. Name: gvinum/plex/array1.p0 > >> Mediasize: 4478356291584 (4.1T) > >> Sectorsize: 512 > >> Mode: r1w1e1 > >> Jend: 4478356291072 > >> Jstart: 4477282549248 > >> Role: Data,Journal > >> --/snip--- > >> > >> So...why is it even touching the plex p0? I figured it would, just > >> like on a disk, if I gave it da0, create da0.journal. Moving on, if I > >> try to newfs the journal, which is now > >> "gvinum/plex/array1.p0.journal", I get: > >> > > Hi, > > > > It think that it touches it because the .p0 contains the gjournal metadata in > > the same way that the volume does, so gjournal attaches to that before the > > volume. One problem is that gjournal attaches to the "wrong" provider, but > > it's also silly that the provider is exposed in the first place. A fix for > > this is in a newer version of gvinum (as the plex is not exposed) if you're > > willing to try. > > > > A simpler fix is to use the "-h" - "hardcode provider name" switch to > the "gjournal label" command (see the man page). > Oh, nice feature. I recommend this then :) -- Ulf Lilleengen From rick-freebsd2008 at kiwi-computer.com Thu Jan 15 09:20:38 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Thu Jan 15 09:20:45 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> Message-ID: <20090115172036.GA54383@keira.kiwi-computer.com> On Thu, Jan 15, 2009 at 07:10:35AM -0500, Brian McCann wrote: > > I'm doing journaling so that I theoretically never have to fsck. It's You don't *have* to fsck with UFS2 either, if you're using soft updates. The only thing fsck does is free up space and inodes that are marked as used but are really not used. Since it can be done successfully in the background, I don't see much of a problem (yes it will take hours, so schedule the checks at times when you have the least I/O traffic). As far as RAM, so long as you have swap it should be fine, just adding extra time to the checks. Again you only need to run fsck if the filesystem was dirty during a reboot or crash and you need to reclaim space. I like to schedule my fscks on busy systems for 12-36 hours delay after startup. That way you don't run them after every reboot if you're experiencing problems and I like to schedule them when no one is using the system. -- Rick C. Petty From lev at serebryakov.spb.ru Thu Jan 15 23:47:47 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Thu Jan 15 23:47:54 2009 Subject: gvinum & gjournal In-Reply-To: <20090115172036.GA54383@keira.kiwi-computer.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> <20090115172036.GA54383@keira.kiwi-computer.com> Message-ID: <529173009.20090116103229@serebryakov.spb.ru> Hello, Rick. You wrote 15 ?????? 2009 ?., 20:20:36: > You don't *have* to fsck with UFS2 either, if you're using soft updates. > The only thing fsck does is free up space and inodes that are marked as > used but are really not used. Since it can be done successfully in the > background, I don't see much of a problem (yes it will take hours, so > schedule the checks at times when you have the least I/O traffic). background fsck on 2Tb (RAID-5 on 5x500Gb drives) in same time as raid5 rebuilding (due to same reasons as fsck: dirty reboot) is pain in ass, really. It finishes never. I was need to stop RAID5 rebuilding, umount filesystem, run fsck by hands (with lots of questions about strange softupdate inconsistences) TWICE and rebuild RAID5 after that. Only thing I lost is 6 or 7 files which were "in flight" at time of crash. So, yes, it is safe for information (nobody expect to have files in flight to be safe in case of crash, of course) but it does not work automagically after reboot... I'm thinking about gjournal, but it KILLS performance in case of fast RAID array without additional super-fast (SSD?) place for journal :( -- // Black Lion AKA Lev Serebryakov From gavin at FreeBSD.org Fri Jan 16 01:27:45 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Jan 16 01:27:56 2009 Subject: misc/130528: gjournal fsck during boot Message-ID: <200901160927.n0G9RhnY056264@freefall.freebsd.org> Synopsis: gjournal fsck during boot Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Fri Jan 16 09:26:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). I don't know if this could be a simple config error, could you show us what your fstab and rc.conf look like? http://www.freebsd.org/cgi/query-pr.cgi?pr=130528 From bjmccann at gmail.com Fri Jan 16 06:45:45 2009 From: bjmccann at gmail.com (Brian McCann) Date: Fri Jan 16 06:45:51 2009 Subject: gvinum & gjournal In-Reply-To: <20090115172036.GA54383@keira.kiwi-computer.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> <20090115172036.GA54383@keira.kiwi-computer.com> Message-ID: <2b5f066d0901160645n81c0296j1e714056da74c88e@mail.gmail.com> On Thu, Jan 15, 2009 at 12:20 PM, Rick C. Petty wrote: > On Thu, Jan 15, 2009 at 07:10:35AM -0500, Brian McCann wrote: >> >> I'm doing journaling so that I theoretically never have to fsck. It's > > You don't *have* to fsck with UFS2 either, if you're using soft updates. > The only thing fsck does is free up space and inodes that are marked as > used but are really not used. Since it can be done successfully in the > background, I don't see much of a problem (yes it will take hours, so > schedule the checks at times when you have the least I/O traffic). As far > as RAM, so long as you have swap it should be fine, just adding extra time > to the checks. Again you only need to run fsck if the filesystem was dirty > during a reboot or crash and you need to reclaim space. I like to schedule > my fscks on busy systems for 12-36 hours delay after startup. That way you > don't run them after every reboot if you're experiencing problems and I > like to schedule them when no one is using the system. > > -- Rick C. Petty > The only time I ever run fsck's is when the system is shutdown dirty (and just about on every reboot, on the large arrays anyway, it almost never background fsck's the array...it insists on doing it before the rest of the system boots/loads). I've already got a few servers here with UFS2 that occasionally crash or hang for various reasons and reboot...and with large file systems (like 2 roughly 200GB arrays), the system takes almost 1 hour to come back to life. I was really hoping UFS2 would have solved this old problem...but it still pops it's head back up now and then. :( Thanks! -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From bjmccann at gmail.com Fri Jan 16 06:49:34 2009 From: bjmccann at gmail.com (Brian McCann) Date: Fri Jan 16 06:49:41 2009 Subject: gvinum & gjournal In-Reply-To: <529173009.20090116103229@serebryakov.spb.ru> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> <20090115172036.GA54383@keira.kiwi-computer.com> <529173009.20090116103229@serebryakov.spb.ru> Message-ID: <2b5f066d0901160649g6801221bp137582074db011f6@mail.gmail.com> 2009/1/16 Lev Serebryakov : > Hello, Rick. > You wrote 15 ?????? 2009 ?., 20:20:36: > >> You don't *have* to fsck with UFS2 either, if you're using soft updates. >> The only thing fsck does is free up space and inodes that are marked as >> used but are really not used. Since it can be done successfully in the >> background, I don't see much of a problem (yes it will take hours, so >> schedule the checks at times when you have the least I/O traffic). > background fsck on 2Tb (RAID-5 on 5x500Gb drives) in same time as > raid5 rebuilding (due to same reasons as fsck: dirty reboot) is pain > in ass, really. It finishes never. I was need to stop RAID5 > rebuilding, umount filesystem, run fsck by hands (with lots of > questions about strange softupdate inconsistences) TWICE and rebuild > RAID5 after that. Only thing I lost is 6 or 7 files which were "in > flight" at time of crash. So, yes, it is safe for information (nobody > expect to have files in flight to be safe in case of crash, of > course) but it does not work automagically after reboot... > > I'm thinking about gjournal, but it KILLS performance in case of > fast RAID array without additional super-fast (SSD?) place for journal > :( > > > -- > // Black Lion AKA Lev Serebryakov > > I've got 4 servers at about 9TB and 12TB on 3Ware hardware RAID5 with gjournal...it is a bit slower, but not too bad. I'm more concerned with reliability then data loss. I was hoping the onboard RAID controller in this Intel SS4200 would be decent, but it won't make an array larger then 2TB...at least, I haven't been able to figure out how to get it to do it. --Brian _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From rick-freebsd2008 at kiwi-computer.com Fri Jan 16 11:12:29 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Fri Jan 16 11:12:35 2009 Subject: gvinum & gjournal In-Reply-To: <2b5f066d0901160645n81c0296j1e714056da74c88e@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> <20090115172036.GA54383@keira.kiwi-computer.com> <2b5f066d0901160645n81c0296j1e714056da74c88e@mail.gmail.com> Message-ID: <20090116191227.GA67515@keira.kiwi-computer.com> On Fri, Jan 16, 2009 at 09:45:44AM -0500, Brian McCann wrote: > > The only time I ever run fsck's is when the system is shutdown dirty > (and just about on every reboot, on the large arrays anyway, it almost > never background fsck's the array...it insists on doing it before the > rest of the system boots/loads). That's strange, I've not seen that before. Are you using softupdates and UFS2? FreeBSD 6.0 or later? I have had numerous crashes for various reasons and the filesystems are almost always dirty when I restart (or why would I restart?) but I have never seen it try to foreground fsck anything except root. If this is happening in your case, it would be nice to diagnose and fix that problem instead of working around it. > I've already got a few servers here > with UFS2 that occasionally crash or hang for various reasons and > reboot...and with large file systems (like 2 roughly 200GB arrays), > the system takes almost 1 hour to come back to life. I was really > hoping UFS2 would have solved this old problem...but it still pops > it's head back up now and then. :( I've had numerous crashes with several filesystems on the order of 200-500 GB each and although the background fsck can take some time, I've never had it forcibly happen in the foreground. Can you paste your /etc/rc.conf ? Also the time it takes to fsck is proportional to the filesystem size, number of inodes, and number of files/directories to check. When I make larger filesystems, I tend to reduce the number of inodes which greatly reduces fsck times. With lots of little files, it's usually a good idea to split filesystems into smaller, manageable pieces. Think about dump/restore times. Sure you can make a 16TB filesystem that can support trillions of files, but you can't expect it to perform well even in normal usage. UFS2 has some other limitations which prevents this from working to your advantage. Your best bet is to plan your filesystems better so you can manage dumps and fscks without terrible hassle or use ZFS and buy 32 gigs of RAM. -- Rick C. Petty From linimon at FreeBSD.org Fri Jan 16 14:43:55 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 16 14:44:06 2009 Subject: bin/130632: [patch] gpart(8) assert failure if used from FreeBSD Live CD Message-ID: <200901162243.n0GMhsrY049747@freefall.freebsd.org> Old Synopsis: gpart assert failure if used from FreeBSD Live CD New Synopsis: [patch] gpart(8) assert failure if used from FreeBSD Live CD Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 16 22:43:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130632 From bugmaster at FreeBSD.org Mon Jan 19 03:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:07:51 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200901191106.n0JB6vwW062959@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/130632 geom [patch] gpart(8) assert failure if used from FreeBSD L o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 44 problems total. From alekar2009 at gmail.com Tue Jan 20 09:08:33 2009 From: alekar2009 at gmail.com (Alex Karpovic) Date: Tue Jan 20 09:08:49 2009 Subject: GELI problem... Oh, I mean disaster Message-ID: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> Hello everyone, I am a long-time user of geli encryption, but just today I faced a problem, connected probably to some hardware malfunction, and I am in need of good advice now. I have a SATA drive, encrypted as whole with GELI. Booting is performed via usbflash drive. Today I tried to add an old IDE hdd, but when I turned my box on, loud clicking sound informed me that the hdd is physically broken. OK, turned computer off right after memory test, removed IDE hdd, and tried to boot as usual. However, GELI is unable to recognize my encrypted SATA now! I do bi-weekly backups, but in current situation it won't save me. I did a lot of work recently, and deadline is so near, that I cannot recreate all that is lost. Therefore, my first question is evident: taking into account the situation, is it possible that the damage is reversible? I know there's little hope, but maybe it is just a signature, which could be re-written? Second question is to feed my brain: what is the technical nature of my problem? Before that, I never expirienced a damaging of good SATA caused by attaching of bad IDE. Alex From pjd at FreeBSD.org Tue Jan 20 13:20:55 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Jan 20 13:21:02 2009 Subject: GELI problem... Oh, I mean disaster In-Reply-To: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> References: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> Message-ID: <20090120205843.GB3819@garage.freebsd.pl> On Tue, Jan 20, 2009 at 06:55:19PM +0200, Alex Karpovic wrote: > Hello everyone, > > I am a long-time user of geli encryption, but just today I faced a problem, > connected probably to some hardware malfunction, and I am in need of good > advice now. > > I have a SATA drive, encrypted as whole with GELI. Booting is performed via > usbflash drive. > > Today I tried to add an old IDE hdd, but when I turned my box on, loud > clicking sound informed me that the hdd is physically broken. OK, turned > computer off right after memory test, removed IDE hdd, and tried to boot as > usual. However, GELI is unable to recognize my encrypted SATA now! Strange. Please send content of /var/run/dmesg.boot, output of geli dump , etc. Your previous /var/run/dmesg.boot would be also helpful if you can dig it up from your backups. > I do bi-weekly backups, but in current situation it won't save me. I did a > lot of work recently, and deadline is so near, that I cannot recreate all > that is lost. > Therefore, my first question is evident: taking into account the situation, > is it possible that the damage is reversible? I know there's little hope, > but maybe it is just a signature, which could be re-written? > Second question is to feed my brain: what is the technical nature of my > problem? Before that, I never expirienced a damaging of good SATA caused by > attaching of bad IDE. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090120/4cfe7d40/attachment.pgp From ota at j.email.ne.jp Thu Jan 22 00:30:11 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Thu Jan 22 00:30:18 2009 Subject: kern/129245: [geom] gcache is more suitable for suffix based provider name Message-ID: <200901220830.n0M8UApX049636@freefall.freebsd.org> The following reply was made to PR kern/129245; it has been noted by GNATS. From: Yoshihiro Ota To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129245: [geom] gcache is more suitable for suffix based provider name Date: Thu, 22 Jan 2009 03:24:55 -0500 This is a multi-part message in MIME format. --Multipart=_Thu__22_Jan_2009_03_24_55_-0500_aV.gtuCgOo9pWE9w Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This will create suffixes, i.e. md2.uzip.cache. Thanks, Hiro --Multipart=_Thu__22_Jan_2009_03_24_55_-0500_aV.gtuCgOo9pWE9w Content-Type: text/x-diff; name="gcache-naming-20090122.diff" Content-Disposition: attachment; filename="gcache-naming-20090122.diff" Content-Transfer-Encoding: 7bit Index: sys/geom/cache/g_cache.c =================================================================== RCS file: /home/ncvs/src/sys/geom/cache/g_cache.c,v retrieving revision 1.2.6.1 diff -u -r1.2.6.1 g_cache.c --- sys/geom/cache/g_cache.c 25 Nov 2008 02:59:29 -0000 1.2.6.1 +++ sys/geom/cache/g_cache.c 22 Jan 2009 08:17:38 -0000 @@ -475,11 +475,11 @@ newpp = NULL; cp = NULL; - G_CACHE_DEBUG(1, "Creating device %s.", md->md_name); + G_CACHE_DEBUG(1, "Creating device %s%s.", pp->name, G_CACHE_SUFFIX); /* Cache size is minimum 100. */ if (md->md_size < 100) { - G_CACHE_DEBUG(0, "Invalid size for device %s.", md->md_name); + G_CACHE_DEBUG(0, "Invalid size for device %s%s.", pp->name, G_CACHE_SUFFIX); return (NULL); } @@ -492,15 +492,9 @@ return (NULL); } - /* Check for duplicate unit. */ - if (g_cache_find_device(mp, (const char *)&md->md_name) != NULL) { - G_CACHE_DEBUG(0, "Provider %s already exists.", md->md_name); - return (NULL); - } - - gp = g_new_geomf(mp, md->md_name); + gp = g_new_geomf(mp, "%s%s", pp->name, G_CACHE_SUFFIX); if (gp == NULL) { - G_CACHE_DEBUG(0, "Cannot create geom %s.", md->md_name); + G_CACHE_DEBUG(0, "Cannot create geom %s%s.", pp->name, G_CACHE_SUFFIX); return (NULL); } gp->softc = NULL; /* for a moment */ @@ -524,9 +518,9 @@ gp->access = g_cache_access; gp->dumpconf = g_cache_dumpconf; - newpp = g_new_providerf(gp, "cache/%s", gp->name); + newpp = g_new_providerf(gp, "%s", gp->name); if (newpp == NULL) { - G_CACHE_DEBUG(0, "Cannot create provider cache/%s.", gp->name); + G_CACHE_DEBUG(0, "Cannot create provider %s.", gp->name); goto fail; } newpp->sectorsize = pp->sectorsize; @@ -709,7 +703,7 @@ gp = g_cache_create(mp, pp, &md, G_CACHE_TYPE_AUTOMATIC); if (gp == NULL) { - G_CACHE_DEBUG(0, "Can't create %s.", md.md_name); + G_CACHE_DEBUG(0, "Can't create %s%s.", pp->name, G_CACHE_SUFFIX); return (NULL); } return (gp); @@ -732,19 +726,13 @@ gctl_error(req, "No '%s' argument", "nargs"); return; } - if (*nargs != 2) { + if (*nargs != 1) { gctl_error(req, "Invalid number of arguments."); return; } strlcpy(md.md_magic, G_CACHE_MAGIC, sizeof(md.md_magic)); md.md_version = G_CACHE_VERSION; - name = gctl_get_asciiparam(req, "arg0"); - if (name == NULL) { - gctl_error(req, "No 'arg0' argument"); - return; - } - strlcpy(md.md_name, name, sizeof(md.md_name)); size = gctl_get_paraml(req, "size", sizeof(*size)); if (size == NULL) { @@ -771,9 +759,9 @@ /* This field is not important here. */ md.md_provsize = 0; - name = gctl_get_asciiparam(req, "arg1"); + name = gctl_get_asciiparam(req, "arg0"); if (name == NULL) { - gctl_error(req, "No 'arg1' argument"); + gctl_error(req, "No 'arg0' argument"); return; } if (strncmp(name, "/dev/", strlen("/dev/")) == 0) @@ -786,7 +774,7 @@ } gp = g_cache_create(mp, pp, &md, G_CACHE_TYPE_MANUAL); if (gp == NULL) { - gctl_error(req, "Can't create %s.", md.md_name); + gctl_error(req, "Can't create %s%s.", pp->name, G_CACHE_SUFFIX); return; } } @@ -818,13 +806,14 @@ gctl_error(req, "No 'arg0' argument"); return; } +#if 0 sc = g_cache_find_device(mp, name); if (sc == NULL) { G_CACHE_DEBUG(1, "Device %s is invalid.", name); gctl_error(req, "Device %s is invalid.", name); return; } - +#endif size = gctl_get_paraml(req, "size", sizeof(*size)); if (size == NULL) { gctl_error(req, "No '%s' argument", "size"); @@ -850,7 +839,6 @@ if (sc->sc_type != G_CACHE_TYPE_AUTOMATIC) return; - strlcpy(md.md_name, name, sizeof(md.md_name)); strlcpy(md.md_magic, G_CACHE_MAGIC, sizeof(md.md_magic)); md.md_version = G_CACHE_VERSION; if ((u_int)*size != 0) Index: sys/geom/cache/g_cache.h =================================================================== RCS file: /home/ncvs/src/sys/geom/cache/g_cache.h,v retrieving revision 1.1.6.1 diff -u -r1.1.6.1 g_cache.h --- sys/geom/cache/g_cache.h 25 Nov 2008 02:59:29 -0000 1.1.6.1 +++ sys/geom/cache/g_cache.h 22 Jan 2009 08:17:38 -0000 @@ -34,6 +34,7 @@ #define G_CACHE_CLASS_NAME "CACHE" #define G_CACHE_MAGIC "GEOM::CACHE" #define G_CACHE_VERSION 1 +#define G_CACHE_SUFFIX ".cache" #ifdef _KERNEL #define G_CACHE_TYPE_MANUAL 0 @@ -113,7 +114,6 @@ struct g_cache_metadata { char md_magic[16]; /* Magic value. */ uint32_t md_version; /* Version number. */ - char md_name[16]; /* Cache value. */ uint32_t md_bsize; /* Cache block size. */ uint32_t md_size; /* Cache size. */ uint64_t md_provsize; /* Provider's size. */ @@ -125,10 +125,9 @@ bcopy(md->md_magic, data, sizeof(md->md_magic)); le32enc(data + 16, md->md_version); - bcopy(md->md_name, data + 20, sizeof(md->md_name)); - le32enc(data + 36, md->md_bsize); - le32enc(data + 40, md->md_size); - le64enc(data + 44, md->md_provsize); + le32enc(data + 20, md->md_bsize); + le32enc(data + 24, md->md_size); + le64enc(data + 28, md->md_provsize); } static __inline void @@ -137,10 +136,9 @@ bcopy(data, md->md_magic, sizeof(md->md_magic)); md->md_version = le32dec(data + 16); - bcopy(data + 20, md->md_name, sizeof(md->md_name)); - md->md_bsize = le32dec(data + 36); - md->md_size = le16dec(data + 40); - md->md_provsize = le64dec(data + 44); + md->md_bsize = le32dec(data + 20); + md->md_size = le16dec(data + 24); + md->md_provsize = le64dec(data + 24); } #endif /* _G_CACHE_H_ */ Index: sbin/geom/class/cache/geom_cache.c =================================================================== RCS file: /home/ncvs/src/sbin/geom/class/cache/geom_cache.c,v retrieving revision 1.3.6.1 diff -u -r1.3.6.1 geom_cache.c --- sbin/geom/class/cache/geom_cache.c 25 Nov 2008 02:59:29 -0000 1.3.6.1 +++ sbin/geom/class/cache/geom_cache.c 22 Jan 2009 08:17:38 -0000 @@ -62,7 +62,7 @@ { 's', "size", &size_configure, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-v] [-b blocksize] [-s size] name" + NULL, "[-v] [-b blocksize] [-s size] prov" }, { "create", G_FLAG_VERBOSE | G_FLAG_LOADKLD, NULL, { @@ -70,14 +70,14 @@ { 's', "size", &size_label, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-v] [-b blocksize] [-s size] name prov" + NULL, "[-v] [-b blocksize] [-s size] prov" }, { "destroy", G_FLAG_VERBOSE, NULL, { { 'f', "force", NULL, G_TYPE_BOOL }, G_OPT_SENTINEL }, - NULL, "[-fv] name ..." + NULL, "[-fv] prov ..." }, { "dump", 0, cache_main, G_NULL_OPTS, NULL, "prov ..." @@ -88,17 +88,17 @@ { 's', "size", &size_label, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-v] [-b blocksize] [-s size] name prov" + NULL, "[-v] [-b blocksize] [-s size] prov" }, { "reset", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, - "[-v] name ..." + "[-v] prov ..." }, { "stop", G_FLAG_VERBOSE, NULL, { { 'f', "force", NULL, G_TYPE_BOOL }, G_OPT_SENTINEL }, - NULL, "[-fv] name ..." + NULL, "[-fv] prov ..." }, G_CMD_SENTINEL }; @@ -138,21 +138,19 @@ intmax_t val; nargs = gctl_get_int(req, "nargs"); - if (nargs != 2) { + if (nargs != 1) { gctl_error(req, "Invalid number of arguments."); return; } strlcpy(md.md_magic, G_CACHE_MAGIC, sizeof(md.md_magic)); md.md_version = G_CACHE_VERSION; - name = gctl_get_ascii(req, "arg0"); - strlcpy(md.md_name, name, sizeof(md.md_name)); val = gctl_get_intmax(req, "blocksize"); md.md_bsize = val; val = gctl_get_intmax(req, "size"); md.md_size = val; - name = gctl_get_ascii(req, "arg1"); + name = gctl_get_ascii(req, "arg0"); md.md_provsize = g_get_mediasize(name); if (md.md_provsize == 0) { fprintf(stderr, "Can't get mediasize of %s: %s.\n", @@ -204,7 +202,6 @@ printf(" Magic string: %s\n", md->md_magic); printf(" Metadata version: %u\n", (u_int)md->md_version); - printf(" Device name: %s\n", md->md_name); printf(" Block size: %u\n", (u_int)md->md_bsize); printf(" Cache size: %u\n", (u_int)md->md_size); printf(" Provider size: %ju\n", (uintmax_t)md->md_provsize); --Multipart=_Thu__22_Jan_2009_03_24_55_-0500_aV.gtuCgOo9pWE9w-- From alekar2009 at gmail.com Thu Jan 22 07:01:16 2009 From: alekar2009 at gmail.com (Alex Karpovic) Date: Thu Jan 22 07:01:24 2009 Subject: GELI problem... Oh, I mean disaster In-Reply-To: <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> References: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> <20090120205843.GB3819@garage.freebsd.pl> <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> Message-ID: <700ff07a0901220701p238b0a6epf3f8510c1757d1be@mail.gmail.com> Witam Pawel! Thank you for response. Below are two dmesgs (current and one taken few months ago). Comparing them, one can see that the disk became smaller for about 2 megs, maybe, simply reports wrong size: 476940MB 476938MB Thus, it is quite natural, that GELI sees no metadata, and "geli dump" reports invalid metadata. I am still unable to understand what happened, but currently it doesn't look as software problem. New question: if I recover just last sector, but not others, than it should be possible to decipher all non-lost sectors - am I right? ==================== of September Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #1: Wed Sep 24 03:32:46 EEST 2008 head@:/usr/obj/usr/src/sys/GIRAFFE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2712.37-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2092191744 (1995 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 hptrr: HPT RocketRAID controller driver v1.1 (Sep 24 2008 03:32:33) cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci1 pcib2: at device 10.0 on pci0 pci2: on pcib2 re0: port 0xee00-0xeeff mem 0xfdfff000-0xfdffffff irq 18 at device 0.0 on pci2 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:34:7e:c7 re0: [FILTER] re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xfe02b000-0xfe02bfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xfe02a000-0xfe02afff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xfe029000-0xfe0290ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: mem 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 22 at device 14.0 on pci3 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:63:ec:1f:00:00:1d:7d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:63:ec:00:1d:7d fwe0: Ethernet address: 02:63:ec:00:1d:7d dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x151c000 fwip0: on firewire0 fwip0: Firewire address: 00:63:ec:1f:00:00:1d:7d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounters tick every 1.000 msec hptrr: no controller detected. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad1: 76350MB at ata0-slave UDMA100 ad5: 476940MB at ata2-slave UDMA33 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. Enter passphrase for ad5: GEOM_ELI: Device ad5.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Integrity: HMAC/SHA1 GEOM_ELI: Crypto: software Trying to mount root from ufs:/dev/ad1s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 ================================================= =================================================Today's Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE-p2 #2 r187533: Wed Jan 21 23:08:53 EET 2009 root@giraffe:/usr/obj/usr/src/sys/GIRAFFE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2712.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2083717120 (1987 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: at device 10.0 on pci0 pci2: on pcib2 re0: port 0xee00-0xeeff mem 0xfdfff000-0xfdffffff irq 18 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:34:7e:c7 re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xfe02b000-0xfe02bfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xfe02a000-0xfe02afff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xfe029000-0xfe0290ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pcm0: mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 pcm0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: mem 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 22 at device 14.0 on pci3 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:63:ec:1f:00:00:1d:7d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwip0: on firewire0 fwip0: Firewire address: 00:63:ec:1f:00:00:1d:7d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:63:ec:00:1d:7d fwe0: Ethernet address: 02:63:ec:00:1d:7d dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x194c000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 device_attach: powernow1 attach returned 6 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad1: 76350MB at ata0-slave UDMA100 ad6: 610480MB at ata3-master SATA300 ad8: 476938MB at ata4-master SATA300 pcm0: pcm0: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad1s1a This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. spa_config_load:90[1]: Cannot open /boot/zfs/zpool.cache. ZFS filesystem version 6 zvol_init:794[1]: ZVOL Initialized. ZFS storage pool version 6 WARNING: /old was not properly dismounted ================================ From alekar2009 at gmail.com Thu Jan 22 08:35:32 2009 From: alekar2009 at gmail.com (Alex Karpovic) Date: Thu Jan 22 08:35:39 2009 Subject: GELI problem... Oh, I mean disaster In-Reply-To: <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> References: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> <20090120205843.GB3819@garage.freebsd.pl> <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> Message-ID: <700ff07a0901220835u59a2a965l6da1503d4dcea3fe@mail.gmail.com> Subject line: "GELI problem" is denounced. Most likely, it is Host Protected Area was activated suddenly, for unknown reason, and there's nothing to blame on FreeBSD, nor GELI in particular. It should be something wrong with either my motherboard (GA-MA770-DS3) or HDD (or static electricity, cosmic rays and so on). The fate of data is now contained in question: whether it was written something to those sectors or it was just SET MAX ADDRESS ATA command. And the only question remains related to GELI is the one I asked in previous message: Is it possible to decipher non-destructed sectors, if last sector recovery will be successful? I believe it should, but everyone is welcomed to support my opinion :) On Thu, Jan 22, 2009 at 5:00 PM, Alex Karpovic wrote: > Witam Pawel! > > Thank you for response. Below are two dmesgs (current and one taken few > months ago). Comparing them, one can see that the disk became smaller for > about 2 megs, maybe, simply reports wrong size: > 476940MB > 476938MB > > Thus, it is quite natural, that GELI sees no metadata, and "geli dump" > reports invalid metadata. > > I am still unable to understand what happened, but currently it doesn't > look as software problem. > > New question: if I recover just last sector, but not others, than it should > be possible to decipher all non-lost sectors - am I right? > > > > ==================== of September > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-RELEASE #1: Wed Sep 24 03:32:46 EEST 2008 > head@:/usr/obj/usr/src/sys/GIRAFFE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2712.37-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > real memory = 2146304000 (2046 MB) > avail memory = 2092191744 (1995 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > hptrr: HPT RocketRAID controller driver v1.1 (Sep 24 2008 03:32:33) > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fde0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > powernow0: on cpu0 > cpu1: on acpi0 > powernow1: on cpu1 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xdf00-0xdf7f mem > 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at > device 0.0 on pci1 > pcib2: at device 10.0 on pci0 > pci2: on pcib2 > re0: port 0xee00-0xeeff mem > 0xfdfff000-0xfdffffff irq 18 at device 0.0 on pci2 > re0: Using 2 MSI messages > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:1f:d0:34:7e:c7 > re0: [FILTER] > re0: [FILTER] > atapci0: port > 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem > 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ohci0: mem 0xfe02e000-0xfe02efff irq 16 at > device 19.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xfe02d000-0xfe02dfff irq 17 at > device 19.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at > device 19.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: SMM does not respond, resetting > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ohci3: mem 0xfe02b000-0xfe02bfff irq 17 at > device 19.3 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: SMM does not respond, resetting > usb3: on ohci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ohci4: mem 0xfe02a000-0xfe02afff irq 18 at > device 19.4 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: SMM does not respond, resetting > usb4: on ohci4 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > ehci0: mem 0xfe029000-0xfe0290ff irq 19 > at device 19.5 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 > usb5: on ehci0 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 10 ports with 10 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pci3: on pcib3 > fwohci0: mem > 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 22 at device 14.0 on pci3 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:63:ec:1f:00:00:1d:7d > fwohci0: Phy 1394a available S400, 3 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:63:ec:00:1d:7d > fwe0: Ethernet address: 02:63:ec:00:1d:7d > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x151c000 > fwip0: on firewire0 > fwip0: Firewire address: 00:63:ec:1f:00:00:1d:7d @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > pmtimer0 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > Timecounters tick every 1.000 msec > hptrr: no controller detected. > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > acd0: DMA limited to UDMA33, device found non-ATA66 cable > acd0: DVDR at ata0-master UDMA33 > ad1: 76350MB at ata0-slave UDMA100 > ad5: 476940MB at ata2-slave UDMA33 > SMP: AP CPU #1 Launched! > GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. > Enter passphrase for ad5: > GEOM_ELI: Device ad5.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Integrity: HMAC/SHA1 > GEOM_ELI: Crypto: software > Trying to mount root from ufs:/dev/ad1s1a > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 > ================================================= > > > =================================================Today's > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-RELEASE-p2 #2 r187533: Wed Jan 21 23:08:53 EET 2009 > root@giraffe:/usr/obj/usr/src/sys/GIRAFFE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2712.83-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > real memory = 2146304000 (2046 MB) > avail memory = 2083717120 (1987 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fde0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xdf00-0xdf7f mem > 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at > device 0.0 on pci1 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_busmaster > vgapci0: child nvidia0 requested pci_enable_io > nvidia0: [GIANT-LOCKED] > nvidia0: [ITHREAD] > pcib2: at device 10.0 on pci0 > pci2: on pcib2 > re0: Ethernet> port 0xee00-0xeeff mem 0xfdfff000-0xfdffffff irq 18 at device 0.0 > on pci2 > re0: turning off MSI enable bit. > re0: Chip rev. 0x38000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:1f:d0:34:7e:c7 > re0: [FILTER] > atapci0: port > 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem > 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ohci0: mem 0xfe02e000-0xfe02efff irq 16 at > device 19.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xfe02d000-0xfe02dfff irq 17 at > device 19.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at > device 19.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: SMM does not respond, resetting > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ohci3: mem 0xfe02b000-0xfe02bfff irq 17 at > device 19.3 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: SMM does not respond, resetting > usb3: on ohci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ohci4: mem 0xfe02a000-0xfe02afff irq 18 at > device 19.4 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: SMM does not respond, resetting > usb4: on ohci4 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > ehci0: mem 0xfe029000-0xfe0290ff irq 19 > at device 19.5 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 > usb5: on ehci0 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 10 ports with 10 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > pcm0: mem > 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 > pcm0: [ITHREAD] > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pci3: on pcib3 > fwohci0: mem > 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 22 at device 14.0 on pci3 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:63:ec:1f:00:00:1d:7d > fwohci0: Phy 1394a available S400, 3 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwip0: on firewire0 > fwip0: Firewire address: 00:63:ec:1f:00:00:1d:7d @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:63:ec:00:1d:7d > fwe0: Ethernet address: 02:63:ec:00:1d:7d > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x194c000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > cpu0: on acpi0 > powernow0: on cpu0 > device_attach: powernow0 attach returned 6 > cpu1: on acpi0 > powernow1: on cpu1 > device_attach: powernow1 attach returned 6 > pmtimer0 on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > acd0: DMA limited to UDMA33, device found non-ATA66 cable > acd0: DVDR at ata0-master UDMA33 > ad1: 76350MB at ata0-slave UDMA100 > ad6: 610480MB at ata3-master SATA300 > ad8: 476938MB at ata4-master SATA300 > pcm0: > pcm0: > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad1s1a > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > spa_config_load:90[1]: Cannot open /boot/zfs/zpool.cache. > ZFS filesystem version 6 > zvol_init:794[1]: ZVOL Initialized. > ZFS storage pool version 6 > WARNING: /old was not properly dismounted > ================================ > > > From avg at icyb.net.ua Thu Jan 22 11:12:18 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 22 11:12:25 2009 Subject: gpart bootcode and /boot/boot Message-ID: <4978C24D.9040706@icyb.net.ua> Sorry for being lazy - what is "gpart bootcode" equivalent of bsdlabel -B [-b boot] ? -- Andriy Gapon From info.lmtd at gadgetsukdirect.com Fri Jan 23 00:38:44 2009 From: info.lmtd at gadgetsukdirect.com (DIRECT Lmtd UK) Date: Fri Jan 23 00:38:51 2009 Subject: SLASH SALES:Get Blackberry Storm/N95/E90/N93 or Apple iPhone 16GB Message-ID: <20090123082034.5505262588@d-o-w.ru> SLASH SALES:Get Blackberry Storm/N95/E90/N93 or Apple iPhone 16GB Sony Ericsson X1 - $400 USD SONY PS3 (60GB) = $300 USD Apple iPhone 16GB............$250 USD Blackberry Bold..............$300 USD Blackberry Storm.............$350 USD Samsung Omnia i900 (16GB)....$470 USD HTC Touch Pro................$400 USD HTC Diamond .................$400 USD Nokia N96....................$350 USD Nokia N85....................$350 USD Nokia E71....................$300 USD Nokia E66....................$300 USD Nokia E90....................$350 USD Motorola V3i D&G......$250 USD Nokia N95......... ...$320 USD Nokia N93......... ...$260 USD Nokia N93i ...........$280 USD Nokia N70 ............$160 USD Nokia N72 ............$175 USD Nokia N73 ............$250 USD Nokia N80 ............$200 USD Nokia N90 ............$200 USD Nokia N91 ............$200 USD We are offering 2 free Units for Any 5 Units order Mixed or Single Model in our CLOSEOUT OFFER All Phones,Brand New,Tri- Band,Quadband with Complete Accessories plus Intl Warranty . Alan Pepple Gadgets DIRECT Lmtd UK 6 Greenhill Crescent, Watford Business Park,Watford,WD18 8RF.UNITED KINGDOM E-mail- gadgets.direct.lmtd@googlemail.com http://www.gadgetsukdirect.com From pjd at FreeBSD.org Fri Jan 23 01:47:29 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Jan 23 01:47:36 2009 Subject: GELI problem... Oh, I mean disaster In-Reply-To: <700ff07a0901220835u59a2a965l6da1503d4dcea3fe@mail.gmail.com> References: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> <20090120205843.GB3819@garage.freebsd.pl> <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> <700ff07a0901220835u59a2a965l6da1503d4dcea3fe@mail.gmail.com> Message-ID: <20090123094739.GB3188@garage.freebsd.pl> On Thu, Jan 22, 2009 at 06:35:30PM +0200, Alex Karpovic wrote: > Subject line: "GELI problem" is denounced. > Most likely, it is Host Protected Area was activated suddenly, for unknown > reason, and there's nothing to blame on FreeBSD, nor GELI in particular. It > should be something wrong with either my motherboard (GA-MA770-DS3) or HDD > (or static electricity, cosmic rays and so on). > > The fate of data is now contained in question: whether it was written > something to those sectors or it was just SET MAX ADDRESS ATA command. > > And the only question remains related to GELI is the one I asked in previous > message: Is it possible to decipher non-destructed sectors, if last sector > recovery will be successful? I believe it should, but everyone is welcomed > to support my opinion :) Yes, it is. Sectors are chained together (using CBC) only within geli provider sector (-s option). -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090123/b36b9a99/attachment.pgp From alekar2009 at gmail.com Fri Jan 23 08:52:55 2009 From: alekar2009 at gmail.com (Alex Karpovic) Date: Fri Jan 23 08:53:02 2009 Subject: GELI problem... Oh, I mean disaster In-Reply-To: <20090123094608.GA3188@garage.freebsd.pl> References: <700ff07a0901200855oaf6eaccpf2693bcf791269e6@mail.gmail.com> <20090120205843.GB3819@garage.freebsd.pl> <700ff07a0901220700p34d01347vbd1f03cde519bd6b@mail.gmail.com> <20090123094608.GA3188@garage.freebsd.pl> Message-ID: <700ff07a0901230852k796b38ak971886648b74cdb6@mail.gmail.com> > Verify that you connected disk back to the same contoller, to the same > port, etc. and that contoller configuration is the same as before. Why? GELI is hardware independent, isn't it? From bugmaster at FreeBSD.org Mon Jan 26 03:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 26 03:07:51 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200901261106.n0QB6taD024254@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/130632 geom [patch] gpart(8) assert failure if used from FreeBSD L o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 44 problems total. From freebsd at soulrebel.in-berlin.de Mon Jan 26 12:20:05 2009 From: freebsd at soulrebel.in-berlin.de (Hannes Hauswedell) Date: Mon Jan 26 12:20:11 2009 Subject: Error creating label on .eli Message-ID: <200901261945.24432.freebsd@soulrebel.in-berlin.de> Hi GEOM-Hackers, I am having serious problems creating a label on a geli-container. I've been using geli for some years now and never encountered similar issues and google doesnt help. I created a standard slice /dev/ar0s2 and first tried to create a label on that. That works without problems. Then I decided to geli init -l 256 -K MYKEY -s 4096 /dev/ar0s2 geli attach -k MYKEY /dev/ar0s2 bsdlabel -w /dev/ar0s2.eli bsdlabel -e /dev/ar0s2.eli I enter a few partions and leave all info but size *. As soon as I save the label to disk I get: WARNING: Expected rawoffset 487974, found 487974 Which looks strange in itself... I tried to read the source code but the block is prefixed by: /* Historical braindamage... */ So I figured I wouldnt really understand what was going on any way... I tried to ignore the warning an just started copying data on a partition inside the slice, but got a reboot with geli-write errors in /var/log/messages. I tried repartitioning and relabeling multiple times to no avail. Thanks for any help! Hannes - please keep me cc'ed! P.S: System is 7.0RC2-GENERIC. The hardrives are both new 1TB of different brands. The issues happen on both drives also when the drives are not in soft-raid. From linimon at FreeBSD.org Tue Jan 27 07:55:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jan 27 07:55:43 2009 Subject: kern/131037: [geli] Unable to create disklabel on .eli-Device Message-ID: <200901271555.n0RFtUhD071030@freefall.freebsd.org> Old Synopsis: Unable to create disklabel on .eli-Device New Synopsis: [geli] Unable to create disklabel on .eli-Device Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jan 27 15:55:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131037 From jhitt at illumasys.com Tue Jan 27 20:26:13 2009 From: jhitt at illumasys.com (Jason Hitt) Date: Tue Jan 27 20:26:19 2009 Subject: graid5 patch Message-ID: <497FD9B9.3000106@illumasys.com> I'm working on replacing my aging fileserver and have set my sights on using graid5 (based on my past usage of the system). Unfortunately, i'm coming up quite short in terms of actually finding this module, even as a patch! My questions: 1) Can someone post a link to the existing source (preferably all three versions, "classic", "TNG", and "PP") 2) Does this project have any sort of real project structure to it, with release cycles and/or dedicated developers? 3) If the answer to 2 is "yes", is there any timeline for it to be added to the official source tree? Regarding 2 and 3 - if there is not an official project for this, would anyone else be interested in helping me set one up? I don't have a massive amount of free time, but i am a developer and have a vested interest in seeing the project succeed, so i would be more than willing to at least set up a more official project page for this critical module and help maintain the codebase. Jason From delphij at delphij.net Tue Jan 27 22:14:27 2009 From: delphij at delphij.net (Xin LI) Date: Tue Jan 27 22:14:34 2009 Subject: graid5 patch In-Reply-To: <497FD9B9.3000106@illumasys.com> References: <497FD9B9.3000106@illumasys.com> Message-ID: <497FF7B8.3090105@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Hitt wrote: > I'm working on replacing my aging fileserver and have set my sights on > using graid5 (based on my past usage of the system). Unfortunately, i'm > coming up quite short in terms of actually finding this module, even as > a patch! > > My questions: > 1) Can someone post a link to the existing source (preferably all > three versions, "classic", "TNG", and "PP") > 2) Does this project have any sort of real project structure to it, > with release cycles and/or dedicated developers? > 3) If the answer to 2 is "yes", is there any timeline for it to be > added to the official source tree? > > Regarding 2 and 3 - if there is not an official project for this, would > anyone else be interested in helping me set one up? I don't have a > massive amount of free time, but i am a developer and have a vested > interest in seeing the project succeed, so i would be more than willing > to at least set up a more official project page for this critical module > and help maintain the codebase. I think the FreeNAS project has a GEOM based RAID-5 implementation: http://www.freenas.org/ And here is their implementation in SVN: http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/build/ports/geom_raid5/ Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkl/97gACgkQi+vbBBjt66DcsgCgtpNr/dL5sl2hl3mPMbthnAge Qw0AoJPg9i/eSrZLZYtTlBbYSf5fxTKi =5Q6I -----END PGP SIGNATURE----- From ivoras at freebsd.org Wed Jan 28 01:20:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jan 28 01:20:14 2009 Subject: graid5 patch In-Reply-To: <497FD9B9.3000106@illumasys.com> References: <497FD9B9.3000106@illumasys.com> Message-ID: Jason Hitt wrote: > I'm working on replacing my aging fileserver and have set my sights on > using graid5 (based on my past usage of the system). Unfortunately, i'm > coming up quite short in terms of actually finding this module, even as > a patch! That's because it has never become an official part of the system. You'll probably have to track and ask its author for the sources. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090128/d6158a9c/signature.pgp From freebsd at soulrebel.in-berlin.de Thu Jan 29 07:10:08 2009 From: freebsd at soulrebel.in-berlin.de (Hannes Hauswedell) Date: Thu Jan 29 07:10:24 2009 Subject: kern/131037: [geli] Unable to create disklabel on .eli-Device Message-ID: <200901291510.n0TFA4g5077749@freefall.freebsd.org> The following reply was made to PR kern/131037; it has been noted by GNATS. From: Hannes Hauswedell To: bug-followup@freebsd.org Cc: Subject: Re: kern/131037: [geli] Unable to create disklabel on .eli-Device Date: Thu, 29 Jan 2009 15:06:44 +0000 The panic seems not to be connected to the warning. I partitioned the .eli with gpt and received no warnings, but still got a reboot while writing. I changed some options on the raid-adapter (which isn't supported by freebsd anyway - the raid is softraid) and now I don't have any panics. So GPT works fine for me and I will be using that. I can't verify whether it would have worked with bsdlabels as well but I think so. The warning in itself should still be considered a bug, but not really important. You may change or close this PR, however you see fit. In case someone wants to work on the warning, here are the infos that may help: Warning appears if you have UFS <-> bsd-partition <-> bsdlabel <-> .eli <-> freebsd-slice -> /dev/ad0s1.elia Warning DOES NOT appear if you have: UFS <-> .eli <-> freebsd-slice ->/dev/ad0s1.eli OR: UFS <-> bsd-partition <-> bsdlabel <-> .eli -> /dev/ad0.elia OR: UFS <-> gpt-partition <-> gpt-layout <-> .eli <-> freebsd-slice -> /dev/ad0s1.elip1 OR: UFS <-> bsd-partition <-> bsdlabel <-> freebsd-slice -> /dev/ad0s1a Regards, Hannes From anderson at freebsd.org Fri Jan 30 09:07:26 2009 From: anderson at freebsd.org (Eric Anderson) Date: Fri Jan 30 09:07:33 2009 Subject: Performance numbers? Message-ID: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> Hi GEOMers! Does anyone have any benchmarks or numbers relating to GEOM performance? I tried doing some on my own, but I didn't get very satisfactory results, so I'm curious what others have seen or used. My hardware is a Core 2 Quad, with 4GB of ram. First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I tried running such tools as rawio, and diskinfo. rawio fails with input/output errors, and diskinfo wants a larger device to give the full stats. I ended up using purely dd since that worked. Interestingly enough, dd'ing to the malloc device results in about 1000 operations per second, regardless of a blocksize of 512bytes or 1MB. Do you all expect this 1000 operations per second to be limited by the mdconfig'ed device, GEOM, both, all, none, ?? I'm looking for pointers here mostly. I really would like to see how many operations (512byte really) the GEOM infrastructure can do on a particular piece of hardware, so if there is a simpler way to do this test, give me a hint. :) Thanks! Eric From ulf.lilleengen at gmail.com Fri Jan 30 09:32:04 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Fri Jan 30 09:32:10 2009 Subject: graid5 patch In-Reply-To: <497FD9B9.3000106@illumasys.com> References: <497FD9B9.3000106@illumasys.com> Message-ID: <20090130183232.GA1275@carrot.BalPol.Local> On Tue, Jan 27, 2009 at 10:06:17PM -0600, Jason Hitt wrote: > I'm working on replacing my aging fileserver and have set my sights on > using graid5 (based on my past usage of the system). Unfortunately, i'm > coming up quite short in terms of actually finding this module, even as > a patch! > > My questions: > 1) Can someone post a link to the existing source (preferably all > three versions, "classic", "TNG", and "PP") > 2) Does this project have any sort of real project structure to it, > with release cycles and/or dedicated developers? > 3) If the answer to 2 is "yes", is there any timeline for it to be > added to the official source tree? > > Regarding 2 and 3 - if there is not an official project for this, would > anyone else be interested in helping me set one up? I don't have a > massive amount of free time, but i am a developer and have a vested > interest in seeing the project succeed, so i would be more than willing > to at least set up a more official project page for this critical module > and help maintain the codebase. > I started on some initial work on integration in a perforce branch a month ago, but it's not very prioritized atm :) Basically, I want to look over the code and make some things simpler where possible and make the code as readable as possible for others. I hope to bring it into a subversion branch eventually, but people who would like to help are welcome :) -- Ulf Lilleengen From ulf.lilleengen at gmail.com Fri Jan 30 10:17:51 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Fri Jan 30 10:17:57 2009 Subject: Performance numbers? In-Reply-To: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> Message-ID: <20090130191818.GB1275@carrot.BalPol.Local> On Fri, Jan 30, 2009 at 10:40:46AM -0600, Eric Anderson wrote: > Hi GEOMers! > > Does anyone have any benchmarks or numbers relating to GEOM performance? > > I tried doing some on my own, but I didn't get very satisfactory > results, so I'm curious what others have seen or used. > > My hardware is a Core 2 Quad, with 4GB of ram. > > First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I > tried running such tools as rawio, and diskinfo. rawio fails with > input/output errors, and diskinfo wants a larger device to give the > full stats. I ended up using purely dd since that worked. > Interestingly enough, dd'ing to the malloc device results in about > 1000 operations per second, regardless of a blocksize of 512bytes or > 1MB. > > Do you all expect this 1000 operations per second to be limited by the > mdconfig'ed device, GEOM, both, all, none, ?? I'm looking for > pointers here mostly. I really would like to see how many operations > (512byte really) the GEOM infrastructure can do on a particular piece > of hardware, so if there is a simpler way to do this test, give me a > hint. :) > Maybe try dtrace to find bottlenecks etc? -- Ulf Lilleengen From ulf.lilleengen at gmail.com Fri Jan 30 10:18:48 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Fri Jan 30 10:18:55 2009 Subject: Performance numbers? In-Reply-To: <20090130191818.GB1275@carrot.BalPol.Local> References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <20090130191818.GB1275@carrot.BalPol.Local> Message-ID: <20090130191918.GC1275@carrot.BalPol.Local> On Fri, Jan 30, 2009 at 07:18:18PM +0000, Ulf Lilleengen wrote: > On Fri, Jan 30, 2009 at 10:40:46AM -0600, Eric Anderson wrote: > > Hi GEOMers! > > > > Does anyone have any benchmarks or numbers relating to GEOM performance? > > > > I tried doing some on my own, but I didn't get very satisfactory > > results, so I'm curious what others have seen or used. > > > > My hardware is a Core 2 Quad, with 4GB of ram. > > > > First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I > > tried running such tools as rawio, and diskinfo. rawio fails with > > input/output errors, and diskinfo wants a larger device to give the > > full stats. I ended up using purely dd since that worked. > > Interestingly enough, dd'ing to the malloc device results in about > > 1000 operations per second, regardless of a blocksize of 512bytes or > > 1MB. > > > > Do you all expect this 1000 operations per second to be limited by the > > mdconfig'ed device, GEOM, both, all, none, ?? I'm looking for > > pointers here mostly. I really would like to see how many operations > > (512byte really) the GEOM infrastructure can do on a particular piece > > of hardware, so if there is a simpler way to do this test, give me a > > hint. :) > > > Maybe try dtrace to find bottlenecks etc? > Blah, sorry for the broken reply-to. -- Ulf Lilleengen From ivoras at freebsd.org Fri Jan 30 12:50:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Jan 30 12:50:15 2009 Subject: graid5 patch In-Reply-To: <20090130183232.GA1275@carrot.BalPol.Local> References: <497FD9B9.3000106@illumasys.com> <20090130183232.GA1275@carrot.BalPol.Local> Message-ID: Ulf Lilleengen wrote: > On Tue, Jan 27, 2009 at 10:06:17PM -0600, Jason Hitt wrote: >> I'm working on replacing my aging fileserver and have set my sights on >> using graid5 (based on my past usage of the system). Unfortunately, i'm >> coming up quite short in terms of actually finding this module, even as >> a patch! >> >> My questions: >> 1) Can someone post a link to the existing source (preferably all >> three versions, "classic", "TNG", and "PP") >> 2) Does this project have any sort of real project structure to it, >> with release cycles and/or dedicated developers? >> 3) If the answer to 2 is "yes", is there any timeline for it to be >> added to the official source tree? >> >> Regarding 2 and 3 - if there is not an official project for this, would >> anyone else be interested in helping me set one up? I don't have a >> massive amount of free time, but i am a developer and have a vested >> interest in seeing the project succeed, so i would be more than willing >> to at least set up a more official project page for this critical module >> and help maintain the codebase. >> > I started on some initial work on integration in a perforce branch a month > ago, but it's not very prioritized atm :) Basically, I want to look over the > code and make some things simpler where possible and make the code as > readable as possible for others. I hope to bring it into a subversion branch > eventually, but people who would like to help are welcome :) Does it still have the aggressive write cache enabled by default? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090130/c9a6a0c2/signature.pgp From ivoras at freebsd.org Fri Jan 30 12:55:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Jan 30 12:55:10 2009 Subject: Performance numbers? In-Reply-To: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> Message-ID: Eric Anderson wrote: > Hi GEOMers! > > Does anyone have any benchmarks or numbers relating to GEOM performance? > > I tried doing some on my own, but I didn't get very satisfactory > results, so I'm curious what others have seen or used. > > My hardware is a Core 2 Quad, with 4GB of ram. > > First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I > tried running such tools as rawio, and diskinfo. rawio fails with > input/output errors, and diskinfo wants a larger device to give the full > stats. I ended up using purely dd since that worked. Interestingly > enough, dd'ing to the malloc device results in about 1000 operations per > second, regardless of a blocksize of 512bytes or 1MB. It's a good idea for testing. 1000 ops/s looks suspiciously like HZ, though I don't know why HZ would influence GEOM (AFAIK context switches between threads, including GEOM threads do not depend on it) - can you try ruling out HZ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090130/ca74e2ba/signature.pgp