From bugmaster at FreeBSD.org Mon Aug 3 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:08:33 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200908031106.n73B6vgt088602@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/136467 geom [geom] glabel(8) destroys access to GEOM tree if volum o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls 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 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 o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 o kern/115856 geom [geli] ZFS thought it was degraded when it should have o 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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage 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 58 problems total. From achilov-rn at askd.ru Wed Aug 5 11:32:08 2009 From: achilov-rn at askd.ru (Rashid N. Achilov) Date: Wed Aug 5 11:32:15 2009 Subject: 28-in-1 Acorp card reader Message-ID: <200908051824.26539.achilov-rn@askd.ru> I have asked this in freebsd-usb@, but take an answer, that's not USB-related trouble. I have 28-in-1 Acorp internal cardreader, which connects to USB port. When I insert card in reader and boot, all OK. When I boot, and later insert card - does nothing - /dev/da0s1 not appeared, in spite of presence /dev/da0. I have search this advice - open /dev/da0 for writing and immediately close it. I.e. cat /dev/null > /dev/da0 or dd if=/dev/null of=/dev/da0 count=0 Well, after these "magic actions" /dev/da0s1 appears. But I think, that opening raw device for writing isn't good idea. How to mount flash, inserted in cardreader another way, without opening raw device for writing or is there any program, which does it by itself? -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.org OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A From paul at gromit.dlib.vt.edu Wed Aug 5 15:34:08 2009 From: paul at gromit.dlib.vt.edu (Paul Mather) Date: Wed Aug 5 15:34:15 2009 Subject: ZFS slow write performance Message-ID: <3E2345AC-55AD-4D23-B76C-B0C37CB62A51@gromit.dlib.vt.edu> I have a system I intend to use to back up a remote system via rsync. It is running FreeBSD/i386 7.2-STABLE and has a ZFS raidz1 pool consisting of four 1 TB SATA drives. The system has 768 MiB of RAM and a 2 GHz Pentium 4 CPU. Currently, I am just trying to rsync data locally from a read-only UFS2-mounted USB-attached hard drive, and am getting (IMHO) poor write speeds of only about 5 MiB/sec. I can't figure out why this is so relatively low. Looking at gstat shows the source drive and destination drives as cruising along at an average of 30%--50% busy (the destination drives averaging between 1800--2000 kBps each in the gstat display). Top shows an average of ~20% system time and ~70% idle (though when I changed "compression=on" to "compression=gzip-9" for the target file system, system CPU load shot up to ~70% utilization). Memory usage is pretty static, with ~165 MiB wired and 512-523 MiB inactive RAM usage. Given there appears to be nothing stressing the system, why isn't it apparently making more use of the available resources, in particular, disk bandwidth? A dd of a large file from the source USB drive reports a transfer rate of about 15 MiB/sec from it, so getting only about a third of this when rsyncing to an otherwise idle ZFS pool is disappointing when the source drive can obviously go faster than it is. If I dd /dev/zero to a file on the target ZFS file system I get about 15 MiB/sec write speed with "compression=off" set and about 18 MiB/sec with "compression=on" set, indicating that the target can go faster, too. Even though I am rsyncing from one local filesystem to another, could the problem lie with rsync overheads? Has anyone else encountered poor rsync performance with ZFS and can offer any tuning advice? Otherwise, does anyone have any advice for speeding up my local copy performance? Here is some dmesg information about the attached hardware: atapci0: port 0xecf8-0xecff, 0xecf0-0xecf3,0xece0-0xece7,0xecd8-0xecdb,0xecc0-0xeccf mem 0xff8ffc00-0xff8fffff irq 16 at device 7.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] [...] ehci0: mem 0xffa00000-0xffa003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered umass0: on uhub3 [...] ad4: 953869MB at ata2-master SATA150 ad6: 953869MB at ata3-master SATA150 ad8: 953869MB at ata4-master SATA150 ad10: 953869MB at ata5-master SATA150 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) I have the following tuning in /boot/loader.conf: vm.kmem_size="640M" vm.kmem_size_max="640M" vfs.zfs.arc_max="320M" #vfs.zfs.vdev.cache.size="5M" vfs.zfs.prefetch_disable="1" Any help or advice is appreciated. Cheers, Paul. From wjw at digiware.nl Fri Aug 7 11:56:35 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Fri Aug 7 11:56:41 2009 Subject: Gmirror rebuilding In-Reply-To: <200907311118.33490.lists@jnielsen.net> References: <4A7305A9.3080506@digiware.nl> <200907311118.33490.lists@jnielsen.net> Message-ID: <4A7C16E6.7070901@digiware.nl> John Nielsen wrote: > On Friday 31 July 2009 10:54:33 Willem Jan Withagen wrote: >> I lost one of my disk in a gmirror, so I inserted a fresh one. >> And thusfar things went rather smoothly,it started rebuilding >> automagically. >> >> That's good,but what isn't is: >> >> Jul 31 16:43:15 www kernel: ad2: FAILURE - READ_DMA >> status=51 error=40 LBA=16344448 >> Jul 31 16:43:15 www kernel: GEOM_MIRROR: Synchronization request failed >> (error=5). mirror/mirror[READ(offset=8368291840, length=131072)] >> Jul 31 16:43:40 www kernel: ad2: FAILURE - READ_DMA >> status=51 error=40 LBA=16910976 >> Jul 31 16:43:40 www kernel: GEOM_MIRROR: Synchronization request failed >> (error=5). mirror/mirror[READ(offset=8658354176, length=131072)] >> >> and ad2 is the original disk. So somewhere I'm left with corrupt files. >> >> And what's worse, once this happens, geom_mirror does not continue with the >> remainder of the disk... >> It claims it is, but there is no activity at all on the disks. >> >> So what to do???? >> >> Hard way out would be to make a backup, reinstall the basic system with >> another/second fresh harddisk, and recover the backup. >> But that is a lot of work. > > If you have a backup already then restoring from it would be the best option. > If you don't then the "hard" way above is a good second (assuming you can > read enough of your remaining disk to get your backup tool to cooperate). > > You should make a backup in any case, but if you want to try to avoid > reinstalling you could do some dd trickery. Remove the new disk from the > mirror. Create a new mirror containing only the new disk. Run > dd if=/dev/mirror/ of=/dev/mirror/ conv=noerror,sync > > This will take a long time with the default block size (512 bytes, one > sector), but the plus side is that you only lose the data from the sectors > that cannot be read. Depending on the extent of the damage to the original > disk and your level of desperation, you may want to make note of which > sectors fail to copy on the first run and try to copy them again (dd if=... > of=... skip=NN seek=NN count=1). See also sysutils/ddrescue, > sysutils/recoverdm and similar (I haven't used any of them). > > If you get a (mostly) viable clone, run fsck -f on it, assess the damage, > update your fstab(s), reboot and add a second new disk to your new mirror. > >> Why doesn't geom_mirror continue with the remainder of the disk? > > I'll leave this question for someone else, but I suspect the behavior is > intentional. As you say, you now have corruption on your volume so the best > recourse is to restore from a known good backup. Well... I did it slightly different. Used sysinstall to partitioned/formatted the fresh disk and then rsynced everything over to the new disk. Hoping that the bad sectors where in empty space or some trivial std file.... Which actually did the job. No complaints about bad files... Now I just need to find a new 80Gb seagate IDE disk to stick in. This is because of the spacing between power-connector and IDE-cableheader. :( Western-Digital's just don't fit. Still remains the question why gmirror does not continue copying the remainder of the disk to get at least a working mirror again. Flags on the state of the disks should still be able to resolve error read conflicts (I think) --WjW From tom.hurst at clara.net Sun Aug 9 17:54:34 2009 From: tom.hurst at clara.net (Thomas Hurst) Date: Sun Aug 9 17:54:42 2009 Subject: Gmirror rebuilding In-Reply-To: <200907311118.33490.lists@jnielsen.net> References: <4A7305A9.3080506@digiware.nl> <200907311118.33490.lists@jnielsen.net> Message-ID: <20090809173707.GA58107@voi.aagh.net> * John Nielsen (lists@jnielsen.net) wrote: > See also sysutils/ddrescue, sysutils/recoverdm and similar (I haven't > used any of them). recoverdisk is part of base and was moved from /usr/src/tools to /sbin a while back. It will, like these tools in ports, use a large block size and then use smaller blocks around an unreadable sector, as well as being able to start where it previously left off. -- Thomas 'Freaky' Hurst http://hur.st/ From bugmaster at FreeBSD.org Mon Aug 10 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:08:09 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200908101106.n7AB6tYF025152@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/136467 geom [geom] glabel(8) destroys access to GEOM tree if volum o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls 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 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 o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 o kern/115856 geom [geli] ZFS thought it was degraded when it should have o 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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage 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 58 problems total. From pjd at FreeBSD.org Mon Aug 10 13:14:52 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Aug 10 13:15:03 2009 Subject: kern/130528: gjournal fsck during boot Message-ID: <200908101314.n7ADEp1t034203@freefall.freebsd.org> Synopsis: gjournal fsck during boot State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 10 sie 2009 13:14:21 UTC State-Changed-Why: As stated by Yoshihiro Ota, this is configuration error, not a bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=130528 From fabio at freebsd.org Tue Aug 11 04:27:45 2009 From: fabio at freebsd.org (Fabio Checconi) Date: Tue Aug 11 04:27:51 2009 Subject: On the transparent insertion of geoms, again Message-ID: <20090811033050.GS18696@gandalf.sssup.it> Hi all, some time ago there was a discussion [1, 2] on this list on the transparent insertion of geoms in an open geom path. There was some kind of agreement on a possible way of doing that, this is the diagram used at the time: > BEFORE ---> [ pp --> old_gp ...] > > Then we can do either "geom xx create ad0" which results in > > AFTER create ---> [ newpp --> gp --> cp ] ---> [ pp --> old_gp ... ] > > or "geom xx insert ad0", which results in > > AFTER insert ---> [ pp --> gp --> cp ] ---> [ newpp --> old_gp ... ] > [ see the original threads for more details and a draft of the code ] The solution relied on the fact that bios keep a reference to their way back up into the geom path, so it is possible to change on-the-fly the contents of the providers they go through without affecting the pending bios. Unfortunately a little problem hides behind this assumption; considering e.g., g_disk_done(): % if ((bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) && % (dp = bp2->bio_to->geom->softc)) { % devstat_end_transaction_bio(dp->d_devstat, bp); % } if bp2->bio_to->geom is dereferenced after the ``geom insert'' above, pp->geom points to the new geom, thus the softc of the new class is used as a struct disk pointer (with all the consequent breakage). To fix that we have fallen back to waiting for the completion of all the pending bios in the ``geom insert'' path, which involves sleeping (with a timeout) with topology held, from the event thread. The reasons behind this (admittedly ugly) design are: - waiting unconditionally may lead to stall, if the transparent insertion is done on top of a geom which serves its bios from the event thread (like geom_slice hotspot users may do), so we need a timeout to limit this effect; - new requests for the old provider/geom couple may arrive, we need to store them in a temporary queue; - we need to sleep inside topology, releasing it to allow progress to the event thread would mean rechecking *everything* after we reacquire it to verify if there are no more pending bios; we tried this and the complexity seemed to be excessive. So the question is: does anyone see a better/simpler way of doing the same hot-insertion without the spurious failures this method may introduce? Any suggestion is welcome, thank you in advance. [1] http://lists.freebsd.org/pipermail/freebsd-geom/2009-March/003400.html [2] http://lists.freebsd.org/pipermail/freebsd-geom/2009-March/003407.html From linimon at FreeBSD.org Tue Aug 11 07:13:36 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Aug 11 07:13:42 2009 Subject: bin/137656: [geom][patch] gpart drops core when adding partition to non-existent geom Message-ID: <200908110713.n7B7DZ7N076952@freefall.freebsd.org> Synopsis: [geom][patch] gpart drops core when adding partition to non-existent geom Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Tue Aug 11 07:13:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137656 From jhay at meraka.org.za Tue Aug 11 08:05:18 2009 From: jhay at meraka.org.za (John Hay) Date: Tue Aug 11 08:05:24 2009 Subject: gptboot parse error Message-ID: <20090811080515.GA52948@zibbi.meraka.csir.co.za> Hi, When experimenting with gptboot to boot different partitions, I found that its parse() function was broken. Using 'p' to seperate the units from the partition did not work, neither did a ','. Here is a fix to make it work with 'p' like it is suggested in main(). Any comments? Should we try to get it in before 8.0? This allows me to use boot.config to select different partitions to boot from. Something like "ad(0p3)/boot/loader" for instance. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org Index: gptboot.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/gptboot/gptboot.c,v retrieving revision 1.86.2.3 diff -u -r1.86.2.3 gptboot.c --- gptboot.c 15 Aug 2008 19:31:12 -0000 1.86.2.3 +++ gptboot.c 7 Aug 2009 10:27:09 -0000 @@ -466,16 +466,13 @@ dsk.type = i; arg += 3; dsk.unit = *arg - '0'; - if (arg[1] != ',' || dsk.unit > 9) + if (arg[1] != 'p' || dsk.unit > 9) return -1; arg += 2; - dsk.part = -1; - if (arg[1] == ',') { - dsk.part = *arg - '0'; - if (dsk.part < 1 || dsk.part > 9) - return -1; - arg += 2; - } + dsk.part = *arg - '0'; + if (dsk.part < 1 || dsk.part > 9) + return -1; + arg++; if (arg[0] != ')') return -1; arg++; From acc at hexadecagram.org Tue Aug 11 09:42:39 2009 From: acc at hexadecagram.org (Anthony Chavez) Date: Tue Aug 11 09:42:47 2009 Subject: Re-starting a gjournal provider In-Reply-To: <20090731064948.GG1584@garage.freebsd.pl> References: <4A62E0CE.1000508@hexadecagram.org> <20090729140436.GG1586@garage.freebsd.pl> <4A7289B9.2060907@hexadecagram.org> <20090731064948.GG1584@garage.freebsd.pl> Message-ID: <4A813CF3.8080609@hexadecagram.org> Pawel Jakub Dawidek wrote: > On Fri, Jul 31, 2009 at 12:05:45AM -0600, Anthony Chavez wrote: >>> It doesn't come back because something (ATA layer?) doesn't properly >>> remove ad0 provider. When you remove the disk, /dev/ad0 should disappear >>> and reappear once you insert it again. >>> >>> You can still do this trick after you insert the disk again so the GEOM >>> can schedule retaste: >>> >>> # true > /dev/ad0 >> Thank you for informing me of that trick. I tried using it after >> "gjournal stop" but unfortunately, nothing changed. > > This is because it should be /dev/ad0s1 and not /dev/ad0. Try with > /dev/ad0s1. I made certain to try both devices and include the results in the example session that I included in my last post. >> Here are the points to note. >> >> 1) When I physically remove a drive from the enclosure, /dev/ad0 does >> not disappear. /dev/ad0 *always* exists until I "atacontrol detach." >> Even when the device is powered off, /dev/ad0 continues to exist. > > This might be three things: > > 1. Your enclosure/controller doesn't report back about disk being > removed. > > 2. Your enclosure does report back, but ATA ignores such report. > This will be a bug in ATA. > > 3. Your controller doesn't support hot-swap or it supports warm-swap, > which means you have to detach it by hand before removing it. The marketing fluff at [1] claims that it does in fact support hot-swap. The extremely small (in physical size) yet extremely large (in lack of specifications) printed documentation included with the device makes absolutely no mention of whether (or not) it is capable of hot-swap. Are there any tools available that would enable me to determine whether or not it supports hot-/warm-swap? All of the places I've looked (/var/log/messages, usbdevs, lspci, gnome-device-manager) seem to be devoid of any such information. >> 2) /dev/ad0s1.journal disappears when I "gjournal stop." >> /dev/ad0s1.journal is the device that, AFAIK, will only come back after >> "atacontrol detach ata0; atacontrol attach ata0". > > It should also get back after 'true > /dev/ad0s1'. What this command do > is to open provider for writing (it doesn't write anything). In GEOM it > will trigger spoil event and then, once command completes, it will > trigger retaste event. This mean that GEOM will inform gjournal to check > /dev/ad0s1 again and this will allow gjournal to find its metadata and > create /dev/ad0s1.journal once again. I understand, but that is not happening. > One more test would be in place. If you could try the command below > before removing disk and after inserting different disk: > > # diskinfo -v /dev/ad0 > > If it shows exactly the same in two cases, it means that it is not aware > that disk was replaced and detach/attach cycle is needed. Okay, I attempted that. The data displayed was exactly the same. I also attempted to power off the device before removing the first drive and power it back on when inserting the new one. The data displayed was exactly the same in that case also. >> 1) Is "atacontrol detach ata0 && atacontrol attach ata0" in fact a safe >> operation to perform in any circumstance? >> >> My better judgment has me thinking that the answer to this question is >> almost certainly "no." However, I am hypothesizing that it would safe >> enough if all devices on ata0 are properly unmounted first, but if I can >> avoid that, I will. It feels clumsy and seems to defeat the purpose of >> hot-swapping. > > It should be safe, but there were plenty of bugs related to disappearing > disk from under mount file system, etc. If nothing is mounted you should > be fine (if there are no ATA bugs in this area). > > But for full hot-swap the disk controller should discover disk being > removed and ATA code should remove it from /dev/. It would seem that unless I'm encountering an ATA bug, I am the victim of false advertising, then. I'm not terribly surprised though, to be honest. I don't really think that the device was designed to be used in this manner. It's not terribly sophisticated. ;-) >> 2) Is it *necessary* to "gjournal stop" before hot-swapping? >> >> In such a scenario, I would opt to simply "umount; gjournal sync," swap >> disks, and then "atacontrol cap ad0; mount" (or even just "mount"). It >> seems quite likely, however, that all drives that undergo this treatment >> would be *required* to have gjournal labels since /dev/ad0s1.journal >> would never disappear (although I've yet to actually test that). > > I'd go with 'umount; gjournal stop' and drop 'gjournal sync'. > > Controler should inform ATA that disk is gone. ATA should inform GEOM > that ad0 is gone. If that would be the case, simple 'umount; gjournal > sync' will be enough. But because it isn't the case, you have to stop > gjournal and detach ad0. Okay so I am skipping "gjournal sync" only for this particular circumstance, then. Under ideal circumstances, I shouldn't have to "gjournal stop," then? >> 3) If the answer to question 2 is "yes," then how can I handle the case >> of inserting a drive that does *not* have a gjournal label? > > There's nothing special here. Let's see how diskinfo test will go first. Okay, since the 2 diskinfo's were identical, what then? It seems to me that a properly working hot-swap device would report the correct information to GEOM, which would create /dev/*.journal devices as necessary, is that correct? >> 1) Is it really necessary to perform 3 "sync" commands before "umount"? >> >> Line 94 of src/sbin/umount/umount.c,v 1.45.20.1 has me thinking that the >> answer is "no," since it calls sync() itself, albeit only once. I got >> the idea for executing "sync" three times from /etc/rc.suspend. > > The idea is that unmount should take case of syncing data. There should > be not need for even one sync. It is called "just in case". My experience in the past is that a simple umount has been sufficient, but since gjournal is still new territory for me, I thought I had better make sure. Thank you. ;-) -- Anthony Chavez http://hexadecagram.org/ mailto:acc@hexadecagram.org xmpp:acc@hexadecagram.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090811/aa05b02d/signature.pgp From pjd at FreeBSD.org Tue Aug 11 13:23:00 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 11 13:23:07 2009 Subject: On the transparent insertion of geoms, again In-Reply-To: <20090811033050.GS18696@gandalf.sssup.it> References: <20090811033050.GS18696@gandalf.sssup.it> Message-ID: <20090811132250.GM2013@garage.freebsd.pl> On Tue, Aug 11, 2009 at 05:30:50AM +0200, Fabio Checconi wrote: > Hi all, > some time ago there was a discussion [1, 2] on this list on the > transparent insertion of geoms in an open geom path. There was some > kind of agreement on a possible way of doing that, this is the diagram > used at the time: > > > BEFORE ---> [ pp --> old_gp ...] > > > > Then we can do either "geom xx create ad0" which results in > > > > AFTER create ---> [ newpp --> gp --> cp ] ---> [ pp --> old_gp ... ] > > > > or "geom xx insert ad0", which results in > > > > AFTER insert ---> [ pp --> gp --> cp ] ---> [ newpp --> old_gp ... ] > > > > [ see the original threads for more details and a draft of the code ] > > > The solution relied on the fact that bios keep a reference to their > way back up into the geom path, so it is possible to change on-the-fly > the contents of the providers they go through without affecting the > pending bios. > > Unfortunately a little problem hides behind this assumption; considering > e.g., g_disk_done(): > > % if ((bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) && > % (dp = bp2->bio_to->geom->softc)) { > % devstat_end_transaction_bio(dp->d_devstat, bp); > % } > > if bp2->bio_to->geom is dereferenced after the ``geom insert'' above, > pp->geom points to the new geom, thus the softc of the new class is used > as a struct disk pointer (with all the consequent breakage). > > To fix that we have fallen back to waiting for the completion of all > the pending bios in the ``geom insert'' path, which involves sleeping > (with a timeout) with topology held, from the event thread. The reasons > behind this (admittedly ugly) design are: > > - waiting unconditionally may lead to stall, if the transparent > insertion is done on top of a geom which serves its bios from the > event thread (like geom_slice hotspot users may do), so we need a > timeout to limit this effect; > > - new requests for the old provider/geom couple may arrive, we need > to store them in a temporary queue; > > - we need to sleep inside topology, releasing it to allow progress > to the event thread would mean rechecking *everything* after we > reacquire it to verify if there are no more pending bios; we tried > this and the complexity seemed to be excessive. > > So the question is: does anyone see a better/simpler way of doing the > same hot-insertion without the spurious failures this method may introduce? > > Any suggestion is welcome, thank you in advance. I also found another problem. Some classes (mine, for example) reference provider in their private metadata (sc_provider field in g_mirror_softc structure), once this provider is moved to another geom this reference will become invalid. -- 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/20090811/51aee736/attachment.pgp From pjd at FreeBSD.org Tue Aug 11 13:27:07 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:27:13 2009 Subject: kern/132242: [gmirror] gmirror.ko fails to fully initialize Message-ID: <200908111327.n7BDR60P098246@freefall.freebsd.org> Synopsis: [gmirror] gmirror.ko fails to fully initialize State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: wto 11 sie 2009 13:25:48 UTC State-Changed-Why: Please provide output of: # gmirror list # fdisk /dev/mirror/gm0 # fdisk /dev/ad8 # fdisk /dev/ad14 http://www.freebsd.org/cgi/query-pr.cgi?pr=132242 From pjd at FreeBSD.org Tue Aug 11 13:30:01 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:30:08 2009 Subject: kern/126902: [geom] geom_label: kernel panic during install boot Message-ID: <200908111330.n7BDU0nT098337@freefall.freebsd.org> Synopsis: [geom] geom_label: kernel panic during install boot State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: wto 11 sie 2009 13:29:19 UTC State-Changed-Why: Could you at least provide backtrace, please. http://www.freebsd.org/cgi/query-pr.cgi?pr=126902 From pjd at FreeBSD.org Tue Aug 11 13:34:35 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:34:56 2009 Subject: kern/131037: [geli] Unable to create disklabel on .eli-Device Message-ID: <200908111334.n7BDYYfP007540@freefall.freebsd.org> Synopsis: [geli] Unable to create disklabel on .eli-Device State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: wto 11 sie 2009 13:33:23 UTC State-Changed-Why: Closing at submitter's request. Not a geli problem anyway. http://www.freebsd.org/cgi/query-pr.cgi?pr=131037 From pjd at FreeBSD.org Tue Aug 11 13:40:47 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:40:59 2009 Subject: kern/124130: [usb] gmirror fails to start usb devices that were present at boot time Message-ID: <200908111340.n7BDek9R014650@freefall.freebsd.org> Old Synopsis: [gmirror] [usb] gmirror fails to start usb devices that were present at boot time New Synopsis: [usb] gmirror fails to start usb devices that were present at boot time Responsible-Changed-From-To: freebsd-geom->freebsd-usb Responsible-Changed-By: pjd Responsible-Changed-When: wto 11 sie 2009 13:38:31 UTC Responsible-Changed-Why: This is not gmirror nor GEOM problem. The disks presented by umass cannot be properly accessed by GEOM classes, so they can't detect their metadata. http://www.freebsd.org/cgi/query-pr.cgi?pr=124130 From pjd at FreeBSD.org Tue Aug 11 13:49:56 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:50:03 2009 Subject: kern/124294: [geom] gmirror(8) have inappropriate logic when working with bad hard-drive Message-ID: <200908111349.n7BDntkx015144@freefall.freebsd.org> Synopsis: [geom] gmirror(8) have inappropriate logic when working with bad hard-drive State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: wto 11 sie 2009 13:48:32 UTC State-Changed-Why: Could you verufy you have sysctl kern.geom.mirror.disconnect_on_failure set to 1? It should disconnect component that behaves badly on first I/O error. After disconnect, another (valid) component will have more fresh metadata and should be choosen as master when synchronization is needed. http://www.freebsd.org/cgi/query-pr.cgi?pr=124294 From pjd at FreeBSD.org Tue Aug 11 13:53:33 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Aug 11 13:53:40 2009 Subject: kern/120231: [geom] GEOM_CONCAT error adding second drive Message-ID: <200908111353.n7BDrW8Y022569@freefall.freebsd.org> Synopsis: [geom] GEOM_CONCAT error adding second drive State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: wto 11 sie 2009 13:51:58 UTC State-Changed-Why: As lulf suggested, gconcat has no way to tell if it should use ad5s1d or ad5s1 if they present exactly the same data. Gconcat report duplicate, but should still work perfectly fine. Either use -h option or ignore duplicate report. http://www.freebsd.org/cgi/query-pr.cgi?pr=120231 From attilio at freebsd.org Tue Aug 11 14:26:47 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Aug 11 14:27:04 2009 Subject: kern/124130: [usb] gmirror fails to start usb devices that were present at boot time In-Reply-To: <200908111549.54441.hselasky@c2i.net> References: <200908111340.n7BDek9R014650@freefall.freebsd.org> <200908111549.54441.hselasky@c2i.net> Message-ID: <3bbf2fe10908110658t139df585q2613977d07d2bca8@mail.gmail.com> 2009/8/11 Hans Petter Selasky : > On Tuesday 11 August 2009 15:40:46 pjd@freebsd.org wrote: >> Old Synopsis: [gmirror] [usb] gmirror fails to start usb devices that were >> present at boot time New Synopsis: [usb] gmirror fails to start usb devices >> that were present at boot time >> >> Responsible-Changed-From-To: freebsd-geom->freebsd-usb >> Responsible-Changed-By: pjd >> Responsible-Changed-When: wto 11 sie 2009 13:38:31 UTC >> Responsible-Changed-Why: >> This is not gmirror nor GEOM problem. The disks presented by umass cannot >> be properly accessed by GEOM classes, so they can't detect their metadata. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=124130 > > Is this related to the recent introduction of newbus_lock() ? Of course it is not as long as it is submitted in May 30. Attilio -- Peace can only be achieved by understanding - A. Einstein From hselasky at c2i.net Tue Aug 11 14:45:50 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 11 14:45:57 2009 Subject: kern/124130: [usb] gmirror fails to start usb devices that were present at boot time In-Reply-To: <3bbf2fe10908110658t139df585q2613977d07d2bca8@mail.gmail.com> References: <200908111340.n7BDek9R014650@freefall.freebsd.org> <200908111549.54441.hselasky@c2i.net> <3bbf2fe10908110658t139df585q2613977d07d2bca8@mail.gmail.com> Message-ID: <200908111645.54028.hselasky@c2i.net> On Tuesday 11 August 2009 15:58:48 Attilio Rao wrote: > 2009/8/11 Hans Petter Selasky : > > On Tuesday 11 August 2009 15:40:46 pjd@freebsd.org wrote: > >> Old Synopsis: [gmirror] [usb] gmirror fails to start usb devices that > >> were present at boot time New Synopsis: [usb] gmirror fails to start usb > >> devices that were present at boot time > >> > >> Responsible-Changed-From-To: freebsd-geom->freebsd-usb > >> Responsible-Changed-By: pjd > >> Responsible-Changed-When: wto 11 sie 2009 13:38:31 UTC > >> Responsible-Changed-Why: > >> This is not gmirror nor GEOM problem. The disks presented by umass > >> cannot be properly accessed by GEOM classes, so they can't detect their > >> metadata. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=124130 > > > > Is this related to the recent introduction of newbus_lock() ? > > Of course it is not as long as it is submitted in May 30. > This PR looks like FreeBSD 7 and not FreeBSD 8. Ignore my comment. --HPS From hselasky at c2i.net Tue Aug 11 14:49:53 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 11 14:49:59 2009 Subject: kern/124130: [usb] gmirror fails to start usb devices that were present at boot time In-Reply-To: <200908111340.n7BDek9R014650@freefall.freebsd.org> References: <200908111340.n7BDek9R014650@freefall.freebsd.org> Message-ID: <200908111549.54441.hselasky@c2i.net> On Tuesday 11 August 2009 15:40:46 pjd@freebsd.org wrote: > Old Synopsis: [gmirror] [usb] gmirror fails to start usb devices that were > present at boot time New Synopsis: [usb] gmirror fails to start usb devices > that were present at boot time > > Responsible-Changed-From-To: freebsd-geom->freebsd-usb > Responsible-Changed-By: pjd > Responsible-Changed-When: wto 11 sie 2009 13:38:31 UTC > Responsible-Changed-Why: > This is not gmirror nor GEOM problem. The disks presented by umass cannot > be properly accessed by GEOM classes, so they can't detect their metadata. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124130 Is this related to the recent introduction of newbus_lock() ? --HPS From 000.fbsd at quip.cz Tue Aug 11 15:22:35 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Aug 11 15:22:41 2009 Subject: kern/113885: [gmirror] [patch] improved gmirror balance algorithm In-Reply-To: <200907160820.n6G8KAGe072164@freefall.freebsd.org> References: <200907160820.n6G8KAGe072164@freefall.freebsd.org> Message-ID: <4A8188A0.8050905@quip.cz> Emil Mikulic wrote: > The following reply was made to PR kern/113885; it has been noted by GNATS. > > From: Emil Mikulic > To: bug-followup@FreeBSD.org > Cc: will@firepipe.net > Subject: Re: kern/113885: [gmirror] [patch] improved gmirror balance > algorithm > Date: Thu, 16 Jul 2009 17:56:19 +1000 > > Will Andrews' patch is *fantastic* > > With this patch and gmirror set to "load" style balancing, I can run two > long sequential reads in parallel and get practically linear scaling on > a two-disk mirror. > > Could someone please commit this? Are there any news on this enhancement? Will it be included in to 8.0-RELEASE? Miroslav Lachman From jilles at FreeBSD.org Wed Aug 12 21:00:33 2009 From: jilles at FreeBSD.org (jilles@FreeBSD.org) Date: Wed Aug 12 21:01:03 2009 Subject: kern/120044: [msdosfs] [geom] incorrect MSDOSFS label fries administrative access to GEOM Message-ID: <200908122100.n7CL0WRq090645@freefall.freebsd.org> Synopsis: [msdosfs] [geom] incorrect MSDOSFS label fries administrative access to GEOM State-Changed-From-To: open->closed State-Changed-By: jilles State-Changed-When: Wed Aug 12 21:00:32 UTC 2009 State-Changed-Why: duplicate of kern/104389 http://www.freebsd.org/cgi/query-pr.cgi?pr=120044 From jilles at FreeBSD.org Wed Aug 12 21:01:04 2009 From: jilles at FreeBSD.org (jilles@FreeBSD.org) Date: Wed Aug 12 21:01:10 2009 Subject: kern/136467: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters Message-ID: <200908122101.n7CL13mj095804@freefall.freebsd.org> Synopsis: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters State-Changed-From-To: open->closed State-Changed-By: jilles State-Changed-When: Wed Aug 12 21:01:03 UTC 2009 State-Changed-Why: duplicate of kern/104389 http://www.freebsd.org/cgi/query-pr.cgi?pr=136467 From gavin at FreeBSD.org Sat Aug 15 20:47:41 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Aug 15 20:47:52 2009 Subject: kern/137797: gmirror split does not improve performance Message-ID: <200908152047.n7FKlfnd022675@freefall.freebsd.org> Synopsis: gmirror split does not improve performance Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Sat Aug 15 20:45:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=137797 From marcel at FreeBSD.org Mon Aug 17 04:49:52 2009 From: marcel at FreeBSD.org (marcel@FreeBSD.org) Date: Mon Aug 17 04:49:58 2009 Subject: bin/137656: [geom][patch] gpart drops core when adding partition to non-existent geom Message-ID: <200908170449.n7H4npK4031581@freefall.freebsd.org> Synopsis: [geom][patch] gpart drops core when adding partition to non-existent geom State-Changed-From-To: open->closed State-Changed-By: marcel State-Changed-When: Mon Aug 17 04:49:37 UTC 2009 State-Changed-Why: Committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=137656 From pjd at FreeBSD.org Mon Aug 17 05:21:41 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Aug 17 05:21:47 2009 Subject: kern/137797: gmirror(8): gmirror split does not improve performance Message-ID: <200908170521.n7H5LeMw065493@freefall.freebsd.org> Synopsis: gmirror(8): gmirror split does not improve performance State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 17 sie 2009 05:18:25 UTC State-Changed-Why: Note that sequential read from two local SATA disks is not the only possible workload. Split mode was implemented there more as an example, although the idea was that it could be used when disks are behind two slow links (eg. accessible over slow network). http://www.freebsd.org/cgi/query-pr.cgi?pr=137797 From bugmaster at FreeBSD.org Mon Aug 17 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:08:08 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200908171106.n7HB6sJV075792@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/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls 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 f kern/128276 geom [gmirror] machine lock up when gmirror module is used f 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 f kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin 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 o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 o kern/115856 geom [geli] ZFS thought it was degraded when it should have o 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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage 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 52 problems total. From xcllnt at mac.com Mon Aug 17 16:29:46 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Aug 17 16:29:51 2009 Subject: 7.x and 8.0 gpt and gpart GPT PMBR prevents Intel boot In-Reply-To: <4A579076.5070008@wagsky.com> References: <4A578E3F.8050305@wagsky.com> <4A579076.5070008@wagsky.com> Message-ID: On Jul 10, 2009, at 12:03 PM, Jeff Kletsky wrote: *snip* > The PR indicates patches for the CHS issue for gpt. For gpart, the > code is in /usr/src/sys/geom/part/g_part_gpt.c and, I believe, should > be modified to read > > le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC); > table->mbr[DOSPARTOFF + 1] = 0x01; /* shd */ > table->mbr[DOSPARTOFF + 2] = 0x01; /* ssect */ > table->mbr[DOSPARTOFF + 3] = 0x00; /* scyl */ > table->mbr[DOSPARTOFF + 4] = 0xee; /* typ */ > table->mbr[DOSPARTOFF + 5] = 0xff; /* ehd */ > table->mbr[DOSPARTOFF + 6] = 0xff; /* esect */ > table->mbr[DOSPARTOFF + 7] = 0xff; /* ecyl */ > le32enc(table->mbr + DOSPARTOFF + 8, 1); /* start */ > le32enc(table->mbr + DOSPARTOFF + 12, MIN(last, 0xffffffffLL)); *snip* > In my opinion, these issues should be considered for inclusion in the > 8.0-RELEASE -- at the very least, the 0xffffff issue, as it cannot > easily be resolved from the command line. This particular change will be in 8.0-RELEASE. Making the EFI GPT slice active is questionable and such has not been done. As you said, there's a simple work-around for it by using fdisk. 7-STABLE needs addressing still. FYI, -- Marcel Moolenaar xcllnt@mac.com From lev at serebryakov.spb.ru Mon Aug 17 23:13:34 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Mon Aug 17 23:13:41 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? Message-ID: <1226785293.20090818025941@serebryakov.spb.ru> Hello, Freebsd-geom. I'm porting geom_raid5 to FreeBSD8, and have strange problem: when module is loaded after system start (with kldload) it tastes its consumers (configured early) and creates array. When it is loaded on boot time (with /boot/loader.conf), it doesn't see array components at all, as if taste is not called... It works on FreeBSD7 flawless in both cases... I've changed only two things: (1) allow root_mount_hold() tocken to be NULL (2) change working thread creation from kthread_create() to kproc_kthread_add(). What are other differences in GEOM between 7 and 8? -- // Black Lion AKA Lev Serebryakov From lev at serebryakov.spb.ru Tue Aug 18 07:38:37 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Tue Aug 18 07:38:44 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: <1226785293.20090818025941@serebryakov.spb.ru> References: <1226785293.20090818025941@serebryakov.spb.ru> Message-ID: <852978746.20090818113833@serebryakov.spb.ru> Hello, Lev. You wrote 18 ??????? 2009 ?., 02:59:41: > I'm porting geom_raid5 to FreeBSD8, and have strange problem: when > module is loaded after system start (with kldload) it tastes its > consumers (configured early) and creates array. > When it is loaded on boot time (with /boot/loader.conf), it doesn't > see array components at all, as if taste is not called... > It works on FreeBSD7 flawless in both cases... > I've changed only two things: > (1) allow root_mount_hold() tocken to be NULL > (2) change working thread creation from kthread_create() to kproc_kthread_add(). > What are other differences in GEOM between 7 and 8? I've found problem. geom_raid5 check cp->provider->sectorsize before g_access() call, and on boot it is zero before g_access() and 512 (which is proper value) after this call. -- // Black Lion AKA Lev Serebryakov From lev at serebryakov.spb.ru Tue Aug 18 07:45:19 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Tue Aug 18 07:45:26 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: <16362.1250581262@critter.freebsd.dk> References: Your message of "Tue, 18 Aug 2009 11:38:33 +0400." <852978746.20090818113833@serebryakov.spb.ru> <16362.1250581262@critter.freebsd.dk> Message-ID: <254357380.20090818114515@serebryakov.spb.ru> Hello, Poul-Henning. You wrote 18 ??????? 2009 ?., 11:41:02: >> I've found problem. geom_raid5 check cp->provider->sectorsize before >>g_access() call, and on boot it is zero before g_access() and 512 >>(which is proper value) after this call. > This is a bug in geom_raid5: > The sectorsize and mediasize are only valid if you hold a proper access > to the provider. Yep, I understand this. It worked on 7 and worked after proper boot, (when somebody tasted this providers -- disks -- already), so bug was well-hidden. -- // Black Lion AKA Lev Serebryakov From phk at phk.freebsd.dk Tue Aug 18 07:56:47 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue Aug 18 07:56:54 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: Your message of "Tue, 18 Aug 2009 11:38:33 +0400." <852978746.20090818113833@serebryakov.spb.ru> Message-ID: <16362.1250581262@critter.freebsd.dk> In message <852978746.20090818113833@serebryakov.spb.ru>, Lev Serebryakov write s: > I've found problem. geom_raid5 check cp->provider->sectorsize before >g_access() call, and on boot it is zero before g_access() and 512 >(which is proper value) after this call. This is a bug in geom_raid5: The sectorsize and mediasize are only valid if you hold a proper access to the provider. -- 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 votdev at gmx.de Tue Aug 18 08:47:46 2009 From: votdev at gmx.de (Volker Theile) Date: Tue Aug 18 08:47:53 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: <16362.1250581262@critter.freebsd.dk> References: <16362.1250581262@critter.freebsd.dk> Message-ID: <20090818082102.184300@gmx.net> Can you please make a bugfix for geom_raid5 (FBSD7). I think some FreeNAS users will be happy, too. Regards Volker -------- Original-Nachricht -------- > Datum: Tue, 18 Aug 2009 07:41:02 +0000 > Von: "Poul-Henning Kamp" > An: Lev Serebryakov > CC: freebsd-geom@freebsd.org > Betreff: Re: Difference between FreeBSD-7 and FreeBSD-8 in tasting? > In message <852978746.20090818113833@serebryakov.spb.ru>, Lev Serebryakov > write > s: > > > I've found problem. geom_raid5 check cp->provider->sectorsize before > >g_access() call, and on boot it is zero before g_access() and 512 > >(which is proper value) after this call. > > This is a bug in geom_raid5: > > The sectorsize and mediasize are only valid if you hold a proper access > to the provider. > > -- > 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. > _______________________________________________ > 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" -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From lev at serebryakov.spb.ru Tue Aug 18 09:36:53 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Tue Aug 18 09:37:03 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: <20090818082102.184300@gmx.net> References: <16362.1250581262@critter.freebsd.dk> <20090818082102.184300@gmx.net> Message-ID: <1555318911.20090818133648@serebryakov.spb.ru> Hello, Volker. You wrote 18 ??????? 2009 ?., 12:21:02: > Can you please make a bugfix for geom_raid5 (FBSD7). I think some FreeNAS users will be happy, too. I'm working on it right now. It seems to be ready, but I need some more tresting. I want to cleanup code and polish it till it will be included in base system in fufutre. -- // Black Lion AKA Lev Serebryakov From ivoras at freebsd.org Tue Aug 18 13:27:09 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Aug 18 13:27:15 2009 Subject: ZFS slow write performance In-Reply-To: <3E2345AC-55AD-4D23-B76C-B0C37CB62A51@gromit.dlib.vt.edu> References: <3E2345AC-55AD-4D23-B76C-B0C37CB62A51@gromit.dlib.vt.edu> Message-ID: Paul Mather wrote: > Currently, I am just trying to rsync data locally from a read-only > UFS2-mounted USB-attached hard drive, and am getting (IMHO) poor write > speeds of only about 5 MiB/sec. I can't figure out why this is so > relatively low. > Any help or advice is appreciated. There could be many reasons, but you will have to dig more to find them. For example, it might be just that USB has a greater latency and it interferes with some assumptions, but it's only a guess. Try 8.0-BETA2, it has both new ZFS and new USB code. From lulf at freebsd.org Wed Aug 19 21:59:06 2009 From: lulf at freebsd.org (Ulf Lilleengen) Date: Wed Aug 19 21:59:12 2009 Subject: Difference between FreeBSD-7 and FreeBSD-8 in tasting? In-Reply-To: <1226785293.20090818025941@serebryakov.spb.ru> References: <1226785293.20090818025941@serebryakov.spb.ru> Message-ID: <4A8C75A6.30401@freebsd.org> Lev Serebryakov wrote: > Hello, Freebsd-geom. > > I'm porting geom_raid5 to FreeBSD8, and have strange problem: when > module is loaded after system start (with kldload) it tastes its > consumers (configured early) and creates array. > > When it is loaded on boot time (with /boot/loader.conf), it doesn't > see array components at all, as if taste is not called... > > It works on FreeBSD7 flawless in both cases... > > I've changed only two things: > (1) allow root_mount_hold() tocken to be NULL > (2) change working thread creation from kthread_create() to kproc_kthread_add(). > > What are other differences in GEOM between 7 and 8? > > Just to mention: http://svn.freebsd.org/base/projects/geom_raid5/ In case you want a repo to submit patches against for people to test. I started to review it a while ago, but got bored too soon :) Nice to see someone works on getting this into the tree. -- Ulf Lilleengen From linimon at FreeBSD.org Sat Aug 22 20:20:06 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Aug 22 20:20:17 2009 Subject: bin/138065: gpart(8) dumps core Message-ID: <200908222020.n7MKK417001327@freefall.freebsd.org> Old Synopsis: gpart dumps core New Synopsis: gpart(8) dumps core Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Aug 22 20:19:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138065 From bugmaster at FreeBSD.org Mon Aug 24 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:08:13 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200908241106.n7OB6tNF048576@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/138065 geom gpart(8) dumps core o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls 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 f kern/128276 geom [gmirror] machine lock up when gmirror module is used f 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 f kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin 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 o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 o kern/115856 geom [geli] ZFS thought it was degraded when it should have o 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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage 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 53 problems total. From marcel at FreeBSD.org Tue Aug 25 02:05:43 2009 From: marcel at FreeBSD.org (marcel@FreeBSD.org) Date: Tue Aug 25 02:05:49 2009 Subject: bin/138065: gpart(8) dumps core Message-ID: <200908250205.n7P25hZM066181@freefall.freebsd.org> Synopsis: gpart(8) dumps core State-Changed-From-To: open->closed State-Changed-By: marcel State-Changed-When: Tue Aug 25 02:04:51 UTC 2009 State-Changed-Why: Fixed in 9-CURRENT and 8.0-BETA3 http://www.freebsd.org/cgi/query-pr.cgi?pr=138065 From ivoras at freebsd.org Tue Aug 25 09:20:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Aug 25 09:20:10 2009 Subject: kern/113885: [gmirror] [patch] improved gmirror balance algorithm Message-ID: <200908250920.n7P9K3XA042099@freefall.freebsd.org> The following reply was made to PR kern/113885; it has been noted by GNATS. From: Ivan Voras To: bug-followup@freebsd.org, zuborg@advancedhosters.com Cc: Subject: Re: kern/113885: [gmirror] [patch] improved gmirror balance algorithm Date: Tue, 25 Aug 2009 11:11:12 +0200 The patch will not increase streaming read performance beyond what's possible with a single drive, it will improve random read performance in certain cases where reads are localized in such ways that reading some of them from one drive and others from the other drive helps. The reason why there is no scalability with streaming read performance vs what can be achieved with RAID0/3/5 is that there is no striping here. For example: if you need to read 4 striped blocks from a RAID0 of two drives, blocks 0 and 2 will be sequentially stored on the first drive, blocks 1 and 3 will be sequentially stored on the second drive. Thus reading the 4 blocks will result in two sequential reads per drive. OTOH, with RAID1, blocks 0 and 2 will be stored with a "gap" between them, containing block 1, and cannot be read sequentially, but a seek is needed. This is why e.g. the "split" method (which effectively does striping on the request level) doesn't help much with performance. From bugmaster at FreeBSD.org Mon Aug 31 11:07:07 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:08:13 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200908311107.n7VB763W070559@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/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls 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 f kern/128276 geom [gmirror] machine lock up when gmirror module is used f 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 f kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin 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 o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 o kern/115856 geom [geli] ZFS thought it was degraded when it should have o 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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage 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 52 problems total.