From lulf at freebsd.org Wed Oct 1 07:05:54 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Wed Oct 1 07:06:02 2008 Subject: [patch] geom_vinum platform fixes In-Reply-To: <20080407142713.GA62578@keira.kiwi-computer.com> References: <20080310052711.GA49676@keira.kiwi-computer.com> <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> <20080313182257.GB14969@keira.kiwi-computer.com> <20080316090554.GA1230@carrot.studby.ntnu.no> <20080316185055.GA64920@keira.kiwi-computer.com> <20080407075843.GA1391@carrot.studby.ntnu.no> <20080407142713.GA62578@keira.kiwi-computer.com> Message-ID: <20081001070911.GA1626@carrot.studby.ntnu.no> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081001/cb68527e/attachment.pgp From crahman at gmail.com Wed Oct 1 12:19:17 2008 From: crahman at gmail.com (Cyrus Rahman) Date: Wed Oct 1 12:19:23 2008 Subject: gjournal deadlock Message-ID: <9e77bdb50810010452r3bd4a01bs14facb8fa9a97b4a@mail.gmail.com> I continue to experience deadlocks using gjournal with large files. In a previous message I mentioned that they occur frequently with snapshots. Although useful, it is certainly possible to do without snapshots, however, lately I have experienced them in another context, namely, building nanobsd images. The problem occurs when writing out the image file through the md(4) device. Writing 128MB images causes no trouble, but moving to a 2GB image causes the deadlock every time. In fact, I was only able to succeed by building the image on a non-journaled filesystem. The deadlock occurs while sleeping on wdrain - here's the ps(1) output of the processes involved in one such event: 0 51 0 0 -16 0 0 16 wdrain DL ?? 1:24.22 [g_journal switcher] 0 52022 52018 0 -16 0 4640 1152 wdrain D ?? 0:00.02 newsyslog 1001 52069 1725 0 -16 0 2596 636 wdrain D p3 0:00.01 sync 0 51935 51933 0 -16 0 4640 1124 wdrain T p7 0:00.38 cpio -dump /usr/obj/nanobsd.img 0 51924 0 0 75 0 0 16 suspfs DL ?? 0:00.12 [md0] These values are used when deciding to msleep in wdrain: vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.runningbufspace: 1956352 They remain static after the deadlock. The really unacceptable aspect of this is that if you don't notice the deadlock has occurred, you can continue to work for many hours on other projects. However, none of the changes made to the filesystem after the deadlock will be committed to the disk. So all your work, including any notes about the deadlock, will vanish when you reboot. It's strange seeing all those deleted files reappear and your code revert back ten hours to the instant the deadlock occurred, and this issue represents a serious danger to anyone using gjournal in a production environment. Furthermore, the problem affects all gjournaled filesystems, not just the one involved in the observed deadlock - so, for example, your successfully received mail and such will also vanish. I expect what happens is that all the changes after the deadlock pile up in the journals, and so remain visible until the inevitable reboot, at which time they are discarded. From lulf at freebsd.org Wed Oct 1 13:05:48 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Wed Oct 1 13:05:55 2008 Subject: [patch] geom_vinum platform fixes In-Reply-To: <20081001070911.GA1626@carrot.studby.ntnu.no> References: <20080310052711.GA49676@keira.kiwi-computer.com> <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> <20080313182257.GB14969@keira.kiwi-computer.com> <20080316090554.GA1230@carrot.studby.ntnu.no> <20080316185055.GA64920@keira.kiwi-computer.com> <20080407075843.GA1391@carrot.studby.ntnu.no> <20080407142713.GA62578@keira.kiwi-computer.com> <20081001070911.GA1626@carrot.studby.ntnu.no> Message-ID: <20081001130842.GA1419@carrot.studby.ntnu.no> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081001/3c1f1220/attachment.pgp From lulf at freebsd.org Wed Oct 1 13:07:56 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Wed Oct 1 13:08:02 2008 Subject: [patch] geom_vinum platform fixes In-Reply-To: <20081001130842.GA1419@carrot.studby.ntnu.no> References: <20080310052711.GA49676@keira.kiwi-computer.com> <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> <20080313182257.GB14969@keira.kiwi-computer.com> <20080316090554.GA1230@carrot.studby.ntnu.no> <20080316185055.GA64920@keira.kiwi-computer.com> <20080407075843.GA1391@carrot.studby.ntnu.no> <20080407142713.GA62578@keira.kiwi-computer.com> <20081001070911.GA1626@carrot.studby.ntnu.no> <20081001130842.GA1419@carrot.studby.ntnu.no> Message-ID: <20081001131113.GB1419@carrot.studby.ntnu.no> On Wed, Oct 01, 2008 at 03:09:00PM +0200, Ulf Lilleengen wrote: > On Wed, Oct 01, 2008 at 09:09:12AM +0200, Ulf Lilleengen wrote: > > On man, apr 07, 2008 at 09:27:13am -0500, Rick C. Petty wrote: > > > On Mon, Apr 07, 2008 at 09:58:43AM +0200, Ulf Lilleengen wrote: > > > > On s?n, mar 16, 2008 at 12:50:55pm -0600, Rick C. Petty wrote: > > > > > On Sun, Mar 16, 2008 at 10:05:55AM +0100, Ulf Lilleengen wrote: > > > > > > > > > > > > I've reviewed the patch and done some modifications to it. I'll need some > > > > > > testing first though (I don't have a testbed right now since I'm travelling). > > > > > > > > > > I've reviewed your patch but haven't had time to test it yet (hopefully > > > > > this week..) > > > > > > > > > Have you been able to test it? I don't have any 64-bit hardware at the > > > > moment :) > > > > > > Sorry, I've been busy with other projects. I'll try to get to it this > > > week, although I can't see why your patch would break anything. > > > > > > > It has been a long time, but I was able to test the patch on i386, amd64 and > > sparc64, and unfortunately it did not work on sparc64. However, I have now > > modified it to support big/little endian 32/64-bit and it seems to work on > > both sparc64 and i386, and the testing is successful on amd64 as well (after > > I get home today), I will commit the attached patch. > > > > Sorry for the long delay :) > > > > And the patch :) > Hrmf, does not seem to get through. Here then: http://people.freebsd.org/~lulf/patches/gvinum/gvinum_platformfix.diff -- Ulf Lilleengen From crahman at gmail.com Wed Oct 1 20:31:52 2008 From: crahman at gmail.com (Cyrus Rahman) Date: Wed Oct 1 20:32:23 2008 Subject: Experiences with Gpart Message-ID: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> I recently had occasion to set up a system that needed to contain numerous partitions, and I thought it would be a good occasion to try gpart to divide the disk. By and large it went very well, with the exception of bug in 'gpart bootcode' which made it necessary to manually dd in the bootstrap. I did discover a few oddities that I will mention here. My intent was to mirror the disks with gmirror. It didn't make sense to individually mirror each gpart partition and have some 30 simultaneous restores going should the mirror ever break. My first idea was to mirror the entire disks (ad4 and ad6) with gmirror and put gpart over the mirror. This sort of works, except that gpart itself if it finds itself at the beginning of the disk even when it doesn't properly taste itself on the last block of the disk. As a result, the same gpart partitions get attached to ad4 and ad6, as well as to the mirror. The gpart geoms attached directly to the disks complain about the last sector being incorrect (the backup table) and request that you fix it (which would not likely go well). But in addition to that, any further geoms contained within the mirror get attached to the outer gpart geoms on ad4 and ad6 and not the mirror. They don't work properly, because the mirror is already attached to ad4 and ad6, so you end up with a non-functional setup. In experimenting, I also discovered that if you directly nest gpart tables, things work fine until you reboot. Then the internal partitions vanish because gpart doesn't attach to them. Fortunately, if you put the inner gpart inside a gmirror inside the outer gpart, things do work fine. This I did for two reasons: First, to avoid the aforementioned trouble with an outermost gmirror containing a gpart geom, and second, so that I could better define how the disk was to be mirrored. I was able to put a number of smaller filesystems inside a single mirrored gpart partition, and then most of the really big ones inside a second mirrored gpart partition. This second partition used the -F option to gmirror so that it would not need to be re-synchonized in a crash. The filesystems within it are gjournal'd to make this possible. Booting was yet another issue, since the loader objects to nested gpart partitions. I handled this by simply making a third partition on the outermost gpt that contained the root. Since this is likely confusing, here's a diagram that will help if you use a fixed font: ad4 ad6 ------ ------ gpart 1 (ad4p1) gpart 1 (ad6p1) freebsd-boot freebsd-boot gpart 2 (ad4p2) gpart 2 (ad6p2) gmirror (gm0 = ad4p2 + ad6p2) root (gm0.p1) gpart 3 (ad4p3) gpart3 (ad6p3) gmirror (gm1 = ad4p3 + ad6p3) gpart 1 (gm1p1) gpart 2 (gm1p2 ... gpart n (gm1pn) gpart 3 (ad4p4) gpart 3 (ad6p4) gmirror (gm2 = ad4p4 + ad6p4) (mirrored with -F) gpart 1 (gm2p1) gjournal (gm2p1.journal) gpart 2 (gm2p2) gjournal (gm2p2.journal) ... Despite the intent of gpt's being to make such nesting unnecessary, as a means of defining the structure of gmirrors, which take up the entire extent of whatever encloses them, the nesting was very helpful. From stickybit at gmx.net Thu Oct 2 22:16:08 2008 From: stickybit at gmx.net (Sticky Bit) Date: Thu Oct 2 22:16:15 2008 Subject: Wrong warnings about rawoffset not 0 (geom_bsd or geom_journal related?) Message-ID: <200810022345.22955.stickybit@gmx.net> Hello, after I recently setup and successful use gjournal I got following messages on every boot: WARNING: Expected rawoffset 0, found 63 WARNING: Expected rawoffset 0, found 120824865 I think the expectation is wrong here. Looks like geom_bsd (or another geom part) is not aware of the fact that there is more than one slice on disk? Slice 1 offset is 63. This of course should never be 0 because space before has to be reserved for boot managers etc. according to the specifications. So fdisk is right here to set offset at 63 for slice 1. Slice 2 offset is 120824865. This is also right because it is a new slice. So those warnings are not plausible and certainly wrong. Did I miss something? Can someone explain it? Slices 1 and 2 were created by sysinstall long time ago. BTW why starts the first partition within these slices at offset 0 and not at offset 16 which it should according to bsdlabel manual page? It works without problems but seems wrong. Slices 3 and 4 were recently created by hand using fdisk and then partitioned using bsdlabel. They hold the journal providers. BTW first partition within these slices starts at offset 16 which seems right. Looks like sysinstall created first partitions within a slice have a wrong offset beginning at 0 and not at 16. But that is probably not the cause of the warning messages at boot. This is my FreeBSD RELENG_7 amd64 setup (fdisk, bsdlabel, gjournal status): # fdisk /dev/ad6 ******* Working on device /dev/ad6 ******* parameters extracted from in-core disklabel are: cylinders=620181 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=620181 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 120824802 (58996 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 120824865, size 335533590 (163834 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 456358455, size 83875365 (40954 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 540233820, size 84903525 (41456 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 # bsdlabel /dev/ad6s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 2048 16384 28528 b: 22257664 2097152 swap c: 120824802 0 unused 0 0 # "raw" part, don't edit d: 2097152 24354816 4.2BSD 2048 16384 28528 e: 31457280 26451968 4.2BSD 2048 16384 28528 f: 20971520 57909248 4.2BSD 2048 16384 28528 g: 20971520 78880768 4.2BSD 2048 16384 28528 h: 20972514 99852288 4.2BSD 2048 16384 28528 # bsdlabel /dev/ad6s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 335533590 0 unused 0 0 # "raw" part, don't edit d: 41943040 0 4.2BSD 2048 16384 28528 e: 20971520 41943040 4.2BSD 2048 16384 28528 f: 62914560 62914560 4.2BSD 2048 16384 28528 g: 209704470 125829120 4.2BSD 2048 16384 28528 # bsdlabel /dev/ad6s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 83875365 0 unused 0 0 # "raw" part, don't edit d: 16777216 16 4.2BSD 0 0 0 e: 16777216 16777232 4.2BSD 0 0 0 f: 16777216 33554448 4.2BSD 0 0 0 g: 16777216 50331664 4.2BSD 0 0 0 h: 16766485 67108880 4.2BSD 0 0 0 # bsdlabel /dev/ad6s4: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 84903525 0 unused 0 0 # "raw" part, don't edit d: 16777216 16 4.2BSD 0 0 0 e: 16777216 16777232 4.2BSD 0 0 0 f: 16777216 33554448 4.2BSD 0 0 0 g: 16777216 50331664 4.2BSD 0 0 0 h: 17794645 67108880 4.2BSD 0 0 0 # gjournal status Name Status Components ad6s1a.journal N/A ad6s1a ad6s3d ad6s1d.journal N/A ad6s1d ad6s3e ad6s1e.journal N/A ad6s1e ad6s3f ad6s1f.journal N/A ad6s1f ad6s3g ad6s1g.journal N/A ad6s1g ad6s3h ad6s1h.journal N/A ad6s1h ad6s4d ad6s2d.journal N/A ad6s2d ad6s4e ad6s2e.journal N/A ad6s2e ad6s4f ad6s2f.journal N/A ad6s2f ad6s4g ad6s2g.journal N/A ad6s2g ad6s4h Thanks! Regards From bugmaster at FreeBSD.org Mon Oct 6 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:07:51 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200810061106.m96B6srO035474@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/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(8): 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/113885 geom [gmirror] [patch] improved gmirror balance algorithm 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] GBDE-encrypted swap causes panic at shutdown 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 38 problems total. From auryn at zirakzigil.org Sun Oct 12 09:46:13 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Sun Oct 12 09:46:21 2008 Subject: Problems with journal? In-Reply-To: <48DE439C.4050505@zirakzigil.org> References: <48DE439C.4050505@zirakzigil.org> Message-ID: <48F1C760.1080902@zirakzigil.org> Giulio Ferro wrote: > I'm experiencing very serious delay issues in 2 production servers. [...] > > I hope any of you can help me look in the right direction, and point > me to any further tests to try or tunable > to set... > > Thanks in advance. > I didn't receive any answer to this, so I'm guessing ufs journal is abandoned or there is no interest in supporting it in production environment. Anyway I removed it from my servers and reverted to standard UFS, so the problems disappeared. I also tried zfs (the only other journaled filesystem available on freebsd). I didn't experiences the hanging behavior I did with journaled ufs, but it's considerably slower than standard ufs (1/2 slower writes, 1/10 slower reads)... From ivoras at freebsd.org Sun Oct 12 14:13:41 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Oct 12 14:13:48 2008 Subject: Problems with journal? In-Reply-To: <48F1C760.1080902@zirakzigil.org> References: <48DE439C.4050505@zirakzigil.org> <48F1C760.1080902@zirakzigil.org> Message-ID: Giulio Ferro wrote: > Giulio Ferro wrote: >> I'm experiencing very serious delay issues in 2 production servers. > [...] >> >> I hope any of you can help me look in the right direction, and point >> me to any further tests to try or tunable >> to set... >> >> Thanks in advance. >> > > I didn't receive any answer to this, so I'm guessing ufs journal > is abandoned or there is no interest in supporting it in production > environment. > Anyway I removed it from my servers and reverted to standard UFS, > so the problems disappeared. I also tried zfs (the only other journaled > filesystem available on freebsd). I didn't experiences the hanging behavior > I did with journaled ufs, but it's considerably slower than standard ufs > (1/2 slower writes, 1/10 slower reads)... Both gjournal and ZFS are still "experimental" as far as stability and performance is concerned (actually, I have the feeling that gjournal itself is simple enough to be ok but it exposes timing problems with UFS...), but you might help by giving more information about your problem: * send output from top (with "S" mode) and vmstat ("vmstat 1") when you experience your slowdown problem * create a kernel core dump (see http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN and http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html , enter "call doadump" on the online debugger prompt) when your problem starts. * attach a debugger to the kernel dump, record and send output of "ps", "show pcpu", "show allpcpu", "show locks", "show alllocks", "show lockedvnods" and "alltrace." These are just generic tips, I don't have an idea what might cause your problems (so some of the information I requested might be useless, but better to send as much as possible; maybe someone will see something interesting). -------------- 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/20081012/ac966d38/signature.pgp From 000.fbsd at quip.cz Sun Oct 12 16:54:21 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sun Oct 12 16:54:28 2008 Subject: Problems with journal? In-Reply-To: <48F1C760.1080902@zirakzigil.org> References: <48DE439C.4050505@zirakzigil.org> <48F1C760.1080902@zirakzigil.org> Message-ID: <48F22BDB.2040803@quip.cz> Giulio Ferro wrote: > Giulio Ferro wrote: > >> I'm experiencing very serious delay issues in 2 production servers. > > [...] > >> >> I hope any of you can help me look in the right direction, and point >> me to any further tests to try or tunable >> to set... >> >> Thanks in advance. >> > > I didn't receive any answer to this, so I'm guessing ufs journal > is abandoned or there is no interest in supporting it in production > environment. > Anyway I removed it from my servers and reverted to standard UFS, > so the problems disappeared. I also tried zfs (the only other journaled > filesystem available on freebsd). I didn't experiences the hanging behavior > I did with journaled ufs, but it's considerably slower than standard ufs > (1/2 slower writes, 1/10 slower reads)... I am using gjournal on few production machines (not heavily IO loaded) without any hangs. Form time to time I get this message in log: fsync: giving up on dirty 0xc553e880: tag devfs, type VCHR usecount 1, writecount 0, refcount 5305 mountedhere 0xc54a1c00 flags () v_object 0xc5526e88 ref 0 pages 33571 lock type devfs: EXCL (count 1) by thread 0xc52aaa50 (pid 41) dev da0s2e.journal GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). I asked this message in the list 6 month ago and Eric Anderson wrote that it shouldn't be a problem. I tested ZFS and UFS comparing speed of copying ports tree in incremental endless loop - UFS became slower and slower with more used inodes, but ZFS had same speed even on almost full partition. At the end of the test, ZFS was about three times faster than UFS+SU. Miroslav Lachman From bugmaster at FreeBSD.org Mon Oct 13 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:07:50 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200810131106.m9DB6nBT029425@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/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(8): 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/113885 geom [gmirror] [patch] improved gmirror balance algorithm 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] GBDE-encrypted swap causes panic at shutdown 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 38 problems total. From auryn at zirakzigil.org Mon Oct 13 20:45:24 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Mon Oct 13 20:45:30 2008 Subject: Problems with journal? In-Reply-To: <48F22BDB.2040803@quip.cz> References: <48DE439C.4050505@zirakzigil.org> <48F1C760.1080902@zirakzigil.org> <48F22BDB.2040803@quip.cz> Message-ID: <48F3B35D.9060507@zirakzigil.org> Miroslav Lachman wrote: > Giulio Ferro wrote: >> Giulio Ferro wrote: >> >>> I'm experiencing very serious delay issues in 2 production servers. >> >> [...] >> >>> >>> I hope any of you can help me look in the right direction, and point >>> me to any further tests to try or tunable >>> to set... >>> >>> Thanks in advance. >>> >> >> I didn't receive any answer to this, so I'm guessing ufs journal >> is abandoned or there is no interest in supporting it in production >> environment. >> Anyway I removed it from my servers and reverted to standard UFS, >> so the problems disappeared. I also tried zfs (the only other journaled >> filesystem available on freebsd). I didn't experiences the hanging >> behavior >> I did with journaled ufs, but it's considerably slower than standard ufs >> (1/2 slower writes, 1/10 slower reads)... > > I am using gjournal on few production machines (not heavily IO loaded) > without any hangs. I'm glad for you. Unfortunately, as I reported in my original message, if the filesystem is cluttered enough even a simple "find" command can very nearly freeze the system. I had jails on the journaled partition, each running a heavily loaded db. > > I tested ZFS and UFS comparing speed of copying ports tree in > incremental endless loop - UFS became slower and slower with more used > inodes, but ZFS had same speed even on almost full partition. At the > end of the test, ZFS was about three times faster than UFS+SU. I believe ZFS is the best thing happened to freebsd in a long time, and I use it full time in my desktops. Anyway I deemed it unusable in my production setup, since a 10 times slower read can't really keep up with that environment. And there is no danger of reaching disk capacity anytime soon... :-) From bsd at fluffles.net Fri Oct 17 17:04:06 2008 From: bsd at fluffles.net (fluffles.net) Date: Fri Oct 17 17:04:13 2008 Subject: Problems with journal? In-Reply-To: <48F3B35D.9060507@zirakzigil.org> References: <48DE439C.4050505@zirakzigil.org> <48F1C760.1080902@zirakzigil.org> <48F22BDB.2040803@quip.cz> <48F3B35D.9060507@zirakzigil.org> Message-ID: <48F8C662.80602@fluffles.net> Giulio Ferro wrote: > Miroslav Lachman wrote: >> Giulio Ferro wrote: >>> Giulio Ferro wrote: >>> >>>> I'm experiencing very serious delay issues in 2 production servers. >>> >>> [...] >>> >>>> >>>> I hope any of you can help me look in the right direction, and >>>> point me to any further tests to try or tunable >>>> to set... >>>> >>>> Thanks in advance. >>>> >>> >>> I didn't receive any answer to this, so I'm guessing ufs journal >>> is abandoned or there is no interest in supporting it in production >>> environment. >>> Anyway I removed it from my servers and reverted to standard UFS, >>> so the problems disappeared. I also tried zfs (the only other >>> journaled >>> filesystem available on freebsd). I didn't experiences the hanging >>> behavior >>> I did with journaled ufs, but it's considerably slower than standard >>> ufs >>> (1/2 slower writes, 1/10 slower reads)... >> >> I am using gjournal on few production machines (not heavily IO >> loaded) without any hangs. > > I'm glad for you. Unfortunately, as I reported in my original message, if > the filesystem is cluttered enough even a simple "find" command can > very nearly freeze the system. Hi Giulio, Have you checked that your disks or array is not using PIO mode? Which uses hefty interrupts which will bring any system to its knees even on light I/O. For ata devices use atacontrol mode for scsi devices including hardware RAID lookup dmesg. I'm not sure if hardware RAID can use PIO, but any hybrid RAID / Fake RAID can. Also, during the journal commit, you may experience a delay. Could you provide some benchmarks like bonnie on the volume, without background I/O if possible. Not sure if any of this is related to your problem, though. Kind regards, Veronica From antik at bsd.ee Sat Oct 18 06:46:48 2008 From: antik at bsd.ee (Andrei Kolu) Date: Sat Oct 18 06:46:55 2008 Subject: gmirror inconsistent filesystem Message-ID: <48F9865A.5050304@bsd.ee> Hi, I encountered strange problem yesterday with gmirror setup on amd64 version of FreeBSD 7.1BETA2- after successful syncronization I shut down system cleanly and on bootup it said that /var filesystem is not clean and stopped rc startup script. I did "fsck -y /var" and mounted everything with "mount -a"- no problems on gmirror. Reboot and all starts over again- inconsistent /var... All other filesystems are clean. Everything works with gmirror without problem on 32bit FreeBSD 7.0RELEASE. Hardware is Asus P5GC-MX/1333, 2xMaxtor 160GB sata, 2x1GB Kingston 667MHz ddr2. Celeron dual-core 1,6GHz. From marius at nuenneri.ch Sun Oct 19 17:44:36 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sun Oct 19 17:44:42 2008 Subject: Experiences with Gpart In-Reply-To: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> Message-ID: Hello Cyrus, thanks for your experimentation. On Wed, Oct 1, 2008 at 10:31 PM, Cyrus Rahman wrote: > I recently had occasion to set up a system that needed to contain > numerous partitions, and I thought it would be a good occasion to try > gpart to divide the disk. By and large it went very well, with the > exception of bug in 'gpart bootcode' which made it necessary to > manually dd in the bootstrap. > > I did discover a few oddities that I will mention here. > > My intent was to mirror the disks with gmirror. It didn't make sense > to individually mirror each gpart partition and have some 30 > simultaneous restores going should the mirror ever break. My first > idea was to mirror the entire disks (ad4 and ad6) with gmirror and > put gpart over the mirror. > > This sort of works, except that gpart itself if it finds itself at the > beginning of the disk even when it doesn't properly taste itself on > the last block of the disk. As a result, the same gpart partitions > get attached to ad4 and ad6, as well as to the mirror. The gpart > geoms attached directly to the disks complain about the last sector > being incorrect (the backup table) and request that you fix it (which > would not likely go well). But in addition to that, any further geoms > contained within the mirror get attached to the outer gpart geoms on > ad4 and ad6 and not the mirror. They don't work properly, because the > mirror is already attached to ad4 and ad6, so you end up with a > non-functional setup. I don't know of a solution for this. Maybe GEOM itself should be extended with something like a taste priority? So that gmirror always tastes before gpart. But I do not really like this because it adds complexity. > In experimenting, I also discovered that if you directly nest gpart > tables, things work fine until you reboot. Then the internal > partitions vanish because gpart doesn't attach to them. > > Fortunately, if you put the inner gpart inside a gmirror inside the > outer gpart, things do work fine. > > This I did for two reasons: First, to avoid the aforementioned > trouble with an outermost gmirror containing a gpart geom, and second, > so that I could better define how the disk was to be mirrored. I was > able to put a number of smaller filesystems inside a single mirrored > gpart partition, and then most of the really big ones inside a second > mirrored gpart partition. This second partition used the -F option to > gmirror so that it would not need to be re-synchonized in a crash. > The filesystems within it are gjournal'd to make this possible. > > Booting was yet another issue, since the loader objects to nested > gpart partitions. I handled this by simply making a third partition > on the outermost gpt that contained the root. > > Since this is likely confusing, here's a diagram that will help if you > use a fixed font: > > ad4 ad6 > ------ ------ > gpart 1 (ad4p1) gpart 1 (ad6p1) > freebsd-boot freebsd-boot > > gpart 2 (ad4p2) gpart 2 (ad6p2) > gmirror (gm0 = ad4p2 + ad6p2) > root (gm0.p1) > > gpart 3 (ad4p3) gpart3 (ad6p3) > gmirror (gm1 = ad4p3 + ad6p3) > gpart 1 (gm1p1) > gpart 2 (gm1p2 > ... > gpart n (gm1pn) > > gpart 3 (ad4p4) gpart 3 (ad6p4) > gmirror (gm2 = ad4p4 + ad6p4) (mirrored with -F) > gpart 1 (gm2p1) > gjournal (gm2p1.journal) > gpart 2 (gm2p2) > gjournal (gm2p2.journal) > ... > > Despite the intent of gpt's being to make such nesting unnecessary, as > a means of defining the structure of gmirrors, which take up the > entire extent of whatever encloses them, the nesting was very helpful. Maybe nesting simply works if you comment the first if in g_part_gpt_probe() in sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, should be my decision to nest or not imo. Kind regards Marius From marius at nuenneri.ch Sun Oct 19 21:14:07 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sun Oct 19 21:14:13 2008 Subject: Experiences with Gpart In-Reply-To: <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> Message-ID: On Sun, Oct 19, 2008 at 10:18 PM, Marcel Moolenaar wrote: > > On Oct 19, 2008, at 10:24 AM, Marius N?nnerich wrote: > >>> Despite the intent of gpt's being to make such nesting unnecessary, as >>> a means of defining the structure of gmirrors, which take up the >>> entire extent of whatever encloses them, the nesting was very helpful. >> >> Maybe nesting simply works if you comment the first if in >> g_part_gpt_probe() in >> sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, should be >> my >> decision to nest or not imo. > > Nesting is not allowed as per the GPT specification. OK. It doesn't make much sense for slices too, but is still allowed. From xcllnt at mac.com Sun Oct 19 21:18:10 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sun Oct 19 21:18:16 2008 Subject: Experiences with Gpart In-Reply-To: References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> Message-ID: <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> On Oct 19, 2008, at 10:24 AM, Marius N?nnerich wrote: >> Despite the intent of gpt's being to make such nesting unnecessary, >> as >> a means of defining the structure of gmirrors, which take up the >> entire extent of whatever encloses them, the nesting was very >> helpful. > > Maybe nesting simply works if you comment the first if in > g_part_gpt_probe() in > sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, > should be my > decision to nest or not imo. Nesting is not allowed as per the GPT specification. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Sun Oct 19 21:40:54 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sun Oct 19 21:41:00 2008 Subject: Experiences with Gpart In-Reply-To: References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> Message-ID: On Oct 19, 2008, at 2:14 PM, Marius N?nnerich wrote: > On Sun, Oct 19, 2008 at 10:18 PM, Marcel Moolenaar > wrote: >> >> On Oct 19, 2008, at 10:24 AM, Marius N?nnerich wrote: >> >>>> Despite the intent of gpt's being to make such nesting >>>> unnecessary, as >>>> a means of defining the structure of gmirrors, which take up the >>>> entire extent of whatever encloses them, the nesting was very >>>> helpful. >>> >>> Maybe nesting simply works if you comment the first if in >>> g_part_gpt_probe() in >>> sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, >>> should be >>> my >>> decision to nest or not imo. >> >> Nesting is not allowed as per the GPT specification. > > OK. It doesn't make much sense for slices too, but is still allowed. A nested MBR provides for backward compatibility by presenting a GPT partition as a drive to those legacy OSes or tools. I don't think it was needed, but it was envisioned that way, AFAICT. It makes sense in a weird way. -- Marcel Moolenaar xcllnt@mac.com From marius at nuenneri.ch Sun Oct 19 22:37:48 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sun Oct 19 22:37:53 2008 Subject: How to get the partition number of a GPT partition from the geom? Message-ID: Hi all, I'm currently experimenting with adding a geom_label for the GPT labels and uuid's. I'm not sure how to proceed because it's different to FS labels. I added g_label_gpt_taste() and changed some files according to the comment in g_label.c. Can I somehow determine which partion number cp->provider has? I already check that cp->provider->geom->class->name is equal to "PART". cp->provider->name is "md0p1" for example, do I really need to parse that string for the number? I need that number as an index into the partition table. Another thing: Can I call g_part_read() which is provided by the PART class to get the partition table of the geom or would I need to read and parse it on my own? Another idea: geom_part already provides a mechanism to get/set the label from userspace, would it be possible to use that mechanism from inside the geom_label? Thanks for your help Marius From bugmaster at FreeBSD.org Mon Oct 20 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:07:50 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200810201106.m9KB6phc082658@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/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(8): 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/113885 geom [gmirror] [patch] improved gmirror balance algorithm 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] GBDE-encrypted swap causes panic at shutdown 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 38 problems total. From marius at nuenneri.ch Mon Oct 20 17:55:35 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon Oct 20 17:55:42 2008 Subject: How to get the partition number of a GPT partition from the geom? In-Reply-To: References: Message-ID: Time for an update :) On Mon, Oct 20, 2008 at 12:37 AM, Marius N?nnerich wrote: > Hi all, > > I'm currently experimenting with adding a geom_label for the GPT > labels and uuid's. I'm not sure how to proceed because it's different > to FS labels. I added g_label_gpt_taste() and changed some files > according to the comment in g_label.c. > > Can I somehow determine which partion number cp->provider has? I > already check that cp->provider->geom->class->name is equal to "PART". > cp->provider->name is "md0p1" for example, do I really need to parse > that string for the number? No > I need that number as an index into the partition table. It's cp->provider->index :) > Another thing: Can I call g_part_read() which is provided by the PART > class to get the partition table of the geom or would I need to read > and parse it on my own? I don't need to, because the whole table is stored in cp->provider->geom->softc. > Another idea: geom_part already provides a mechanism to get/set the > label from userspace, would it be possible to use that mechanism from > inside the geom_label? Wouldn't help, seems like userland gpart parses the dumpconf xml. A new question popped up: Is it possible to test the a geom of class PART is of "subclass" GPT? - Marius From xcllnt at mac.com Mon Oct 20 19:09:39 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Oct 20 19:09:47 2008 Subject: How to get the partition number of a GPT partition from the geom? In-Reply-To: References: Message-ID: On Oct 20, 2008, at 10:55 AM, Marius N?nnerich wrote: > A new question popped up: > Is it possible to test the a geom of class PART is of "subclass" GPT? Not easily from the kernel now, but it's always possible to make certain bits of information more readily available for use inside the kernel. It seems to make sense to have GEOMs export label information through g_getattr(). This allows the label to come from every GEOM that possibly can have labels, without the need to add explicit support... -- Marcel Moolenaar xcllnt@mac.com From marius at nuenneri.ch Mon Oct 20 19:45:08 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon Oct 20 19:45:15 2008 Subject: How to get the partition number of a GPT partition from the geom? In-Reply-To: References: Message-ID: Hi Marcel, thanks for your reply. On Mon, Oct 20, 2008 at 9:09 PM, Marcel Moolenaar wrote: > > On Oct 20, 2008, at 10:55 AM, Marius N?nnerich wrote: > >> A new question popped up: >> Is it possible to test the a geom of class PART is of "subclass" GPT? > > > Not easily from the kernel now, but it's always possible to make > certain bits of information more readily available for use inside > the kernel. > > It seems to make sense to have GEOMs export label information > through g_getattr(). This allows the label to come from every > GEOM that possibly can have labels, without the need to add > explicit support... That would certainly be a clean thing to do. I'll take a look into g_getattr() now, thanks. From marius at nuenneri.ch Mon Oct 20 20:21:39 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon Oct 20 20:21:46 2008 Subject: How to get the partition number of a GPT partition from the geom? In-Reply-To: References: Message-ID: On Mon, Oct 20, 2008 at 9:45 PM, Marius N?nnerich wrote: > Hi Marcel, > > thanks for your reply. > > On Mon, Oct 20, 2008 at 9:09 PM, Marcel Moolenaar wrote: >> >> On Oct 20, 2008, at 10:55 AM, Marius N?nnerich wrote: >> >>> A new question popped up: >>> Is it possible to test the a geom of class PART is of "subclass" GPT? >> >> >> Not easily from the kernel now, but it's always possible to make >> certain bits of information more readily available for use inside >> the kernel. >> >> It seems to make sense to have GEOMs export label information >> through g_getattr(). This allows the label to come from every >> GEOM that possibly can have labels, without the need to add >> explicit support... > > That would certainly be a clean thing to do. > I'll take a look into g_getattr() now, thanks. Hmm, this would not really help for GPT, since I would also like to have the partition uuid, so another attr would be needed. BIO_GETATTR is handled in g_part.c so the specific implementations never see the request. For example MBR has no label or uuid so it doesn't make sense to ask it for one. Is there some documentation why gpart was started and what it's main advantages are over the old style? From marius at nuenneri.ch Mon Oct 20 20:40:47 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon Oct 20 20:40:53 2008 Subject: raid & label issues In-Reply-To: <20080901125709.GA26304@syhpoon-portaone.portaone.com> References: <20080901125709.GA26304@syhpoon-portaone.portaone.com> Message-ID: On Mon, Sep 1, 2008 at 2:57 PM, Max E. Kuznecov wrote: > Hi, > I have a RAID1 created with atacontrol. > After installation I create a label, say: tunefs -L root /dev/ar0s1a > and put /def/ufs/root as rootfs into fstab. > So I expect the system will boot from raid (ar0s1a) device, but it > won't. > > It occurs that tunefs create label not only on ar0 device itself but on > the raid components as well, in my case they are ad4 and ad6. > > And after reboot I've got my system booted from ad4, i.e. the first > device with 'root' label on it. I've skimmed through the geom_label > sources and, indeed, it creates /dev/ufs/