From owner-freebsd-geom@FreeBSD.ORG Sun Oct 23 13:19:38 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9ACB106567F for ; Sun, 23 Oct 2011 13:19:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 68CAB8FC12 for ; Sun, 23 Oct 2011 13:19:38 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:7cad:61c8:8c4a:e83f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 11B9E4AC2D for ; Sun, 23 Oct 2011 17:19:36 +0400 (MSD) Date: Sun, 23 Oct 2011 17:19:35 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <4710290662.20111023171935@serebryakov.spb.ru> To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: GEOM "splicing"? Is it possible to insert GEOM into stack on-line? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 13:19:38 -0000 Hello, Freebsd-geom. As far as I remeber, there was some support for "splicing" GEOM I/O schedulers into "live" GEOM graph without rebuilding graph from scratches. Is it possible now for GEOM class, which is completely transparent (like geom_nop, without offsets, errors, etc) to be inserted into live GEOM graph? I need to put one such GEOM between device and file system and I don't want to stop server, unmount filesystem, etc... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Mon Oct 24 10:19:48 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28021065674 for ; Mon, 24 Oct 2011 10:19:48 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 994708FC08 for ; Mon, 24 Oct 2011 10:19:48 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RIHdB-0007JN-4h for freebsd-geom@freebsd.org; Mon, 24 Oct 2011 12:19:45 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Oct 2011 12:19:45 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Oct 2011 12:19:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 24 Oct 2011 12:19:31 +0200 Lines: 38 Message-ID: References: <4710290662.20111023171935@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26C7DA7FCA947274BEA190C1" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 In-Reply-To: <4710290662.20111023171935@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: GEOM "splicing"? Is it possible to insert GEOM into stack on-line? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 10:19:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26C7DA7FCA947274BEA190C1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23/10/2011 15:19, Lev Serebryakov wrote: > Hello, Freebsd-geom. >=20 > As far as I remeber, there was some support for "splicing" GEOM I/O > schedulers into "live" GEOM graph without rebuilding graph from > scratches. AFAIK it was a relatively dirty hack; a better, more systematic solution is being discussed for a long time now... > Is it possible now for GEOM class, which is completely transparent > (like geom_nop, without offsets, errors, etc) to be inserted into live > GEOM graph? I need to put one such GEOM between device and file system > and I don't want to stop server, unmount filesystem, etc... Short answer: no. --------------enig26C7DA7FCA947274BEA190C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6lO7MACgkQldnAQVacBcjOfgCfSVe+TgZCNwC44oKL0J5TsVnL COMAoJuj96/eiZ8m9iPB2YuR431q2TFY =JR0S -----END PGP SIGNATURE----- --------------enig26C7DA7FCA947274BEA190C1-- From owner-freebsd-geom@FreeBSD.ORG Mon Oct 24 11:07:02 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA79C1065670 for ; Mon, 24 Oct 2011 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C8BE18FC0A for ; Mon, 24 Oct 2011 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9OB72E4025295 for ; Mon, 24 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9OB72H8025293 for freebsd-geom@FreeBSD.org; Mon, 24 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Oct 2011 11:07:02 GMT Message-Id: <201110241107.p9OB72H8025293@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:07:02 -0000 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/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/161486 geom [geli] GELI password entry is too visible o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider o kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres o kern/159091 geom [geom] GEOM fails to scan nested partitions to create p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] ABI change without version bump in 8.2 o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working 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/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock 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/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore 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/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot 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/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 f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to 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 o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa 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. 67 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Oct 24 12:33:21 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B6F1065670 for ; Mon, 24 Oct 2011 12:33:21 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA568FC12 for ; Mon, 24 Oct 2011 12:33:20 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CC7082842F; Mon, 24 Oct 2011 14:33:19 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B818328428; Mon, 24 Oct 2011 14:33:17 +0200 (CEST) Message-ID: <4EA55B0D.4080508@quip.cz> Date: Mon, 24 Oct 2011 14:33:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Alfred Bartsch References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <4E9D3B56.50300@quip.cz> <4E9D99F3.40104@dssgmbh.de> <4E9ED3C8.7030607@quip.cz> <4E9FF09B.4030204@dssgmbh.de> In-Reply-To: <4E9FF09B.4030204@dssgmbh.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:33:21 -0000 Alfred Bartsch wrote: > Am 19.10.2011 15:42, schrieb Miroslav Lachman: [...] >> UEFI will replace old BIOS sooner or later, so what you will do >> then? Than you will need to rework your servers and change your >> setup routine. And I think it is better to avolid known possible >> problem than hoping "it will not bite me". You can't avoid Murphy's >> law ;) >> > >> From my present point of view there are two alternatives: Hardware > RAID and (matured) ZFS. > > If I were a GEOM guru, i would try to enhance the compatibility > between upcoming UEFI and GMIRROR / GRAID3 etc. Just guessing: > What about adding a flag named "-gpt" "-efi" or just "-offset" to > these geoms to reserve enough space (at least 33 sectors) behind the > metadata sector at the end of the disk provider to hold whatever > secondary gpt table is needed to satisfy UEFI. In ideal world, it will be "the right way", but I guess it will never happen in our real FreeBSD world. There are nobody with time, skills an courage to revork "all" GEOM classes. It is not so easy task (backward compatibility, compatibility with other OSes / tools, etc.) >>>> I am using gjournal on few of our servers, but we are slowly >>>> removing it from our setups. Data writes to gjournaled disks >>>> are too slow and sometimes gjournal is not playing nice. >>> >>> I'm heavily interested in more details. >> >> When I did some tests in the past, gjournal cannot be used in >> combination with iSCSI and I was not able to stop gjournal tasting >> providers (I was not able to remove / disable gjournal on device) >> until I stop all of them and unload gjournal kernel module. I don't >> know the current state. > > Up to now I'm not using any ISCSI equipment. Good to know about some > weaknesses in advance. > >> >>>> Maybe ZFS or UFS+SUJ is better option. >>> >>> Yes, maybe. ZFS is mainly for future use. Do you use the second >>> option on large filesystems? >> >> ZFS is there for "a long time". I feel safe to use it in production >> on few of our servers. I didn't test UFS+SUJ because it is released >> in forthcoming 9.0 and we are not deploying current on our >> servers. >> > > Compared to UFS, ZFS lifetime is relatively short. From my point of > view ZFS in its present state is too immature to hold mission critical > data, YMMV. UFS2 or UFS2+SU (Soft-Updates) is there for a longer time than ZFS, but UFS2+SUJ (journaled soft-updates) is there ofr a short time and not much tested in production. Even UFS2+gjournal is not widely deployed / tested. > On the other hand ZFS needs a lot of redundant disk space and memory > to work as expected, not to forget cpu-cycles. IMHO, ZFS is not 32-bit > capable, so there is no way to use it on older and small hardware. Yes, you are right, ZFS cannot be used in some scenarios. But in some others scenario, ZFS is the best possible. e.g. for large flexible storage, I will use ZFS, for database server I will use UFS2+SU without gjournal. [...] > > Did you perform any benchmarks (UFS+Softupdates vs. UFS+Gjournal)? If > yes, did you compare async mounts + write cache enabled (gjournal) to > sync mounts + write cache disabled (softupdates)? I don't have a fancy graphs or tables from benchmarking SW, I just have real workload experiencies where write cache were enabled in both cases. > If I understand you right, you prefer write speed to data consistency > in these cases. This may be the right choice in your environment. > >> From my point of view, I am happy to find all bits restored in /var > after an unclean shutdown for error analysis and recovery purposes, > and I hate the vision of having to restore databases from backup, even > after power failures. Furthermore I am glad, only having to wait for > gmirror synchronizing to regain redundancy after replacing a failed disk. I am not sure, you can rely on data consistency with todays HDDs when cache is enabled even if you use gjournal. You allways lose content of device cache as rotating (and some flash devices - SSD - too) is known to lie to OS about "data is written", so you end up with lost or demaged date with unclean shutdown. Database engines handle it in its own way with own journal log etc., because some of them can be installed on raw partitions without underling FS. (also MySQL can do it) I rember one case (about 3 years ago) where server remains unbootable after kernel panic and I spent a couple of hours by playing with disabling gjournal, doing full fsck on the given partition etc. It is rare case, but can happen. >>> with fdisk + bsdlabel there are not enough partitions in one >>> slice to hold all the journals, and as I already mentioned I >>> really want to minimize recovery time. With gmirror + gjournal >>> I'm able to activate disk write cache without losing data >>> consistency, which improves performance significantly. >> >> According to following commit message, bsdlabel was extended to 26 >> partitions 3 years ago. >> http://lists.freebsd.org/pipermail/cvs-all/2007-December/239719.html >> >> > (I didn't tested yet, because I don't need it - we are using two slices >> on our servers) > > I didn't know this, thanks for revealing. I'm not sure if all BSD > utilities can deal with this. > >> >>>> I see what you are trying to do and it would be nice if "all >>>> works as one can expect", but the reality is different. So I >>>> don't think it is good idea to make it as you described. >>>> >>> I'm not yet fully convinced, that my idea of disk partitioning is >>> a bad one, so please let me take part in your negative >>> experiences with gjournal. Thanks in advance. >> >> I am not saying that your idea is bad. It just contains some >> things which I rather avoid. > > To summarize some of the pros and cons of this method of disk > partitioning: > pros: > - IMHO easy to configure > - easy to recover from a failed disk (just replace with a suitable > one and resync with gmirror, needs no preparation of the new disk) > - minimal downtime after unclean shutdowns (gjournal is responsible > for this, no sucking fsck on large file systems) > - disk write cache can and should be enabled (enhanced performance) > - all disk / partition sizes are supported (even> 2TB) > - 32 bit version of FreeBSD (i386) is sufficient (small and old > hardware remains usable) > > cons: > - danger of overwriting gmirror metadata by an "unfriendly" UEFI-BIOS - somewhat complex initial setup or future changes in partitioning (you must have prepared right number of partitions for journals, so adding more partitions is not so easy - in case with UFS2+SUJ or ZFS, you just add another partition) > - to be continued ... > > Feel free to add some topics here which I am missing. One thing in my mind is longstanding problem with gjournal on heavily loaded servers: Aug 16 01:48:28 praha kernel: fsync: giving up on dirty Aug 16 01:48:30 praha kernel: 0xc44ba9b4: tag devfs, type VCHR Aug 16 01:48:30 praha kernel: usecount 1, writecount 0, refcount 6941 mountedhere 0xc445b700 Aug 16 01:48:30 praha kernel: flags () Aug 16 01:48:30 praha kernel: v_object 0xc1548c00 ref 0 pages 192023 Aug 16 01:48:30 praha kernel: lock type devfs: EXCL (count 1) by thread 0xc42a7240 (pid 45) Aug 16 01:48:30 praha kernel: dev mirror/gm0s2e.journal Aug 16 01:48:30 praha kernel: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). Aug 16 02:32:34 praha kernel: fsync: giving up on dirty Aug 16 02:32:34 praha kernel: 0xc44ba9b4: tag devfs, type VCHR Aug 16 02:32:34 praha kernel: usecount 1, writecount 0, refcount 1418 mountedhere 0xc445b700 Aug 16 02:32:34 praha kernel: flags () Aug 16 02:32:34 praha kernel: v_object 0xc1548c00 ref 0 pages 128123 Aug 16 02:32:34 praha kernel: lock type devfs: EXCL (count 1) by thread 0xc42a7240 (pid 45) Aug 16 02:32:34 praha kernel: dev mirror/gm0s2e.journal Aug 16 02:32:34 praha kernel: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). This error messages is seen on theme almost every second day and nobody gives me suitable explanation what it really means / what it cause. The only answer I got was something like "it is not harmfull"... then why it is logged at all? So today I removed gjournal from the next older server. I will try UFS2+SUJ with 9.0 as one of the possible ways for a future setups, where ZFS cannot be used. Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Mon Oct 24 22:27:29 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA2F1065670; Mon, 24 Oct 2011 22:27:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D8AC88FC0A; Mon, 24 Oct 2011 22:27:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9OMRS8e061049; Mon, 24 Oct 2011 22:27:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9OMRSZv061045; Mon, 24 Oct 2011 22:27:28 GMT (envelope-from linimon) Date: Mon, 24 Oct 2011 22:27:28 GMT Message-Id: <201110242227.p9OMRSZv061045@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161979: [geom] glabel doesn't update after newfs, and glabel status is flaky X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:27:29 -0000 Old Synopsis: GEOM: glabel issue New Synopsis: [geom] glabel doesn't update after newfs, and glabel status is flaky Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 24 22:25:49 UTC 2011 Responsible-Changed-Why: Write a better Synopsis and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=161979 From owner-freebsd-geom@FreeBSD.ORG Tue Oct 25 13:59:29 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38C21065670 for ; Tue, 25 Oct 2011 13:59:29 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 619A08FC1D for ; Tue, 25 Oct 2011 13:59:29 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 6ACF7EA1; Tue, 25 Oct 2011 15:59:28 +0200 (CEST) Date: Tue, 25 Oct 2011 15:58:45 +0200 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20111025135845.GG1640@garage.freebsd.pl> References: <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> <20111019161833.GB1982@garage.freebsd.pl> <20111019201317.GC1982@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtJ+CqYNzKB4ukR4" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 13:59:29 -0000 --vtJ+CqYNzKB4ukR4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, as of r226733, error reporting should be better for unsupported version and there is support for creating GELI devices with older metadata versions. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --vtJ+CqYNzKB4ukR4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6mwJQACgkQForvXbEpPzSUVQCfTkwti8HEgLmbR1a7heUz4apM +e8AnA6rK2bzCO6SDiGeGO6QaKiHr+DD =c9bH -----END PGP SIGNATURE----- --vtJ+CqYNzKB4ukR4-- From owner-freebsd-geom@FreeBSD.ORG Tue Oct 25 16:39:02 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEEE81065670; Tue, 25 Oct 2011 16:39:02 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 972DE8FC0C; Tue, 25 Oct 2011 16:39:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9PGd29E017141; Tue, 25 Oct 2011 16:39:02 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9PGd2Va017137; Tue, 25 Oct 2011 16:39:02 GMT (envelope-from pjd) Date: Tue, 25 Oct 2011 16:39:02 GMT Message-Id: <201110251639.p9PGd2Va017137@freefall.freebsd.org> To: robv@ieee.org, pjd@FreeBSD.org, freebsd-geom@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/161486: [geli] GELI password entry is too visible X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 16:39:02 -0000 Synopsis: [geli] GELI password entry is too visible State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: wto 25 paź 2011 16:38:05 UTC State-Changed-Why: This is already implemented as of r215299. Responsible-Changed-From-To: freebsd-geom->pjd Responsible-Changed-By: pjd Responsible-Changed-When: wto 25 paź 2011 16:38:05 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=161486 From owner-freebsd-geom@FreeBSD.ORG Tue Oct 25 18:41:16 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26CE106566B for ; Tue, 25 Oct 2011 18:41:16 +0000 (UTC) (envelope-from rob_vanhooren@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id B7A068FC15 for ; Tue, 25 Oct 2011 18:41:16 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [192.168.200.80] (24-246-69-42.cable.teksavvy.com [24.246.69.42]) by asmtp021.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LTM008K4UFYYD30@asmtp021.mac.com>; Tue, 25 Oct 2011 10:40:53 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-25_06:2011-10-25, 2011-10-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=6 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110250187 From: Rob VanHooren In-reply-to: <201110251639.p9PGd2Va017137@freefall.freebsd.org> Date: Tue, 25 Oct 2011 13:40:45 -0400 Content-transfer-encoding: quoted-printable Message-id: <55862237-CCAB-4FD7-B6BE-54621B0380BD@mac.com> References: <201110251639.p9PGd2Va017137@freefall.freebsd.org> To: pjd@FreeBSD.org X-Mailer: Apple Mail (2.1251.1) Cc: Rob VanHooren , freebsd-geom@FreeBSD.org Subject: in head only Re: kern/161486: [geli] GELI password entry is too visible X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rob VanHooren List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:41:16 -0000 yes, I see that lme did roll it into head as r215299, tho please could = it be backed into 8.2 thanks, R. On 2011-10-25, at 12:39 PM, pjd@FreeBSD.org wrote: > Synopsis: [geli] GELI password entry is too visible >=20 > State-Changed-From-To: open->closed > State-Changed-By: pjd > State-Changed-When: wto 25 pa=C5=BA 2011 16:38:05 UTC > State-Changed-Why:=20 > This is already implemented as of r215299. >=20 >=20 > Responsible-Changed-From-To: freebsd-geom->pjd > Responsible-Changed-By: pjd > Responsible-Changed-When: wto 25 pa=C5=BA 2011 16:38:05 UTC > Responsible-Changed-Why:=20 > I'll take this one. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161486 From owner-freebsd-geom@FreeBSD.ORG Tue Oct 25 18:43:29 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3B01065674; Tue, 25 Oct 2011 18:43:29 +0000 (UTC) (envelope-from miwi.freebsd@googlemail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2231B8FC1C; Tue, 25 Oct 2011 18:43:28 +0000 (UTC) Received: by pzk4 with SMTP id 4so4664580pzk.3 for ; Tue, 25 Oct 2011 11:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=aMX/c+kyGF3ezo8Lw0JLCwpOBDH2fx/cq4OJry4PmqI=; b=IX8SyvmQqMUUqdAmnuqEyJ/4RkLQyWinAmyzxfkJalLCxKaC++IKzwxiWm4wko6dgH lOZ2vHWt4Kp8W/ncuNa8NiowB/wBWq92alP+46V9AmvKJh+0Borgc748eYgxvk/cjeMl BBAnGj1V4dCcZFEpSMCFADTAranGpF2qYguY0= Received: by 10.68.39.231 with SMTP id s7mr58288759pbk.33.1319566636113; Tue, 25 Oct 2011 11:17:16 -0700 (PDT) Received: from [192.168.0.103] ([175.139.105.2]) by mx.google.com with ESMTPS id g1sm9012015pbv.2.2011.10.25.11.17.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Oct 2011 11:17:14 -0700 (PDT) Sender: Martin Wilke From: Martin Wilke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2011 02:15:09 +0800 Message-Id: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> To: antik@bsd.ee Mime-Version: 1.0 (Apple Message framework v1251) X-Mailer: Apple Mail (2.1251) Cc: current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:43:29 -0000 Hi, I face the same error since upgrade from 8.2 to 9.0RC1, is there any way = to fix that? thx Martin= From owner-freebsd-geom@FreeBSD.ORG Tue Oct 25 19:27:15 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E52CD106566B; Tue, 25 Oct 2011 19:27:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C59B8FC18; Tue, 25 Oct 2011 19:27:14 +0000 (UTC) Received: by eyd10 with SMTP id 10so1162894eyd.13 for ; Tue, 25 Oct 2011 12:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ujs16e0o+mvx6c0enn/0EI9etMYUuSgEHGd0HPkmvao=; b=AygFQXRaf9cK4gg5fjzPyvgQk+ZaEd5UTIu9xBgv5+WsfcJuhk5gmgyz6p/dmrFNTl Y2f30dBQOhuCJlID6UPRDc0Sfa31TyJSnMiqG9zrCw8YE09iQtalRlUzljkfSw771AHA khgy+kFF4R2c4i1b02wLa8z6X/xVKO12jaOA8= MIME-Version: 1.0 Received: by 10.182.111.70 with SMTP id ig6mr4608725obb.6.1319570833436; Tue, 25 Oct 2011 12:27:13 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Tue, 25 Oct 2011 12:27:13 -0700 (PDT) In-Reply-To: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> Date: Tue, 25 Oct 2011 12:27:13 -0700 Message-ID: From: Garrett Cooper To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Cc: antik@bsd.ee, current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:27:16 -0000 On Tue, Oct 25, 2011 at 11:15 AM, Martin Wilke wrote: > Hi, > > I face the same error since upgrade from 8.2 to 9.0RC1, is there any way to fix that? errno == 19 => ENODEV -- so the question is, what device is missing? -Garrett From owner-freebsd-geom@FreeBSD.ORG Wed Oct 26 04:22:51 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C618106564A; Wed, 26 Oct 2011 04:22:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 555318FC08; Wed, 26 Oct 2011 04:22:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9Q4Mpus070417; Wed, 26 Oct 2011 04:22:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9Q4MpSD070413; Wed, 26 Oct 2011 04:22:51 GMT (envelope-from linimon) Date: Wed, 26 Oct 2011 04:22:51 GMT Message-Id: <201110260422.p9Q4MpSD070413@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162010: [geli] panic: Provider's error should be set (error=0)(device=label/feiya.eli). X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 04:22:51 -0000 Synopsis: [geli] panic: Provider's error should be set (error=0)(device=label/feiya.eli). Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 26 04:21:49 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162010 From owner-freebsd-geom@FreeBSD.ORG Wed Oct 26 17:29:02 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B313106564A for ; Wed, 26 Oct 2011 17:29:02 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 0014C8FC15 for ; Wed, 26 Oct 2011 17:29:01 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id 9C4CF5D4AF; Wed, 26 Oct 2011 19:29:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id ii8OuSCZwJKd; Wed, 26 Oct 2011 19:28:58 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id BE5F45D435; Wed, 26 Oct 2011 19:28:58 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id B4C20450A0; Wed, 26 Oct 2011 19:28:58 +0200 (CEST) Message-ID: <4EA84359.2090905@dssgmbh.de> Date: Wed, 26 Oct 2011 19:28:57 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <4E9D3B56.50300@quip.cz> <4E9D99F3.40104@dssgmbh.de> <4E9ED3C8.7030607@quip.cz> <4E9FF09B.4030204@dssgmbh.de> <4EA55B0D.4080508@quip.cz> In-Reply-To: <4EA55B0D.4080508@quip.cz> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:29:02 -0000 Am 24.10.2011 14:33, schrieb Miroslav Lachman: > Alfred Bartsch wrote: >> Am 19.10.2011 15:42, schrieb Miroslav Lachman: > > [...] > >>> UEFI will replace old BIOS sooner or later, so what you will >>> do then? Than you will need to rework your servers and change >>> your setup routine. And I think it is better to avolid known >>> possible problem than hoping "it will not bite me". You can't >>> avoid Murphy's law ;) >>> >> >>> From my present point of view there are two alternatives: >>> Hardware >> RAID and (matured) ZFS. >> >> If I were a GEOM guru, i would try to enhance the compatibility >> between upcoming UEFI and GMIRROR / GRAID3 etc. Just guessing: >> What about adding a flag named "-gpt" "-efi" or just "-offset" >> to these geoms to reserve enough space (at least 33 sectors) >> behind the metadata sector at the end of the disk provider to >> hold whatever secondary gpt table is needed to satisfy UEFI. > > In ideal world, it will be "the right way", but I guess it will > never happen in our real FreeBSD world. There are nobody with time, > skills an courage to revork "all" GEOM classes. It is not so easy > task (backward compatibility, compatibility with other OSes / > tools, etc.) > >>>>> I am using gjournal on few of our servers, but we are >>>>> slowly removing it from our setups. Data writes to >>>>> gjournaled disks are too slow and sometimes gjournal is not >>>>> playing nice. >>>> >>>> I'm heavily interested in more details. >>> >>> When I did some tests in the past, gjournal cannot be used in >>> combination with iSCSI and I was not able to stop gjournal >>> tasting providers (I was not able to remove / disable gjournal >>> on device) until I stop all of them and unload gjournal kernel >>> module. I don't know the current state. >> >> Up to now I'm not using any ISCSI equipment. Good to know about >> some weaknesses in advance. >> >>> >>>>> Maybe ZFS or UFS+SUJ is better option. >>>> >>>> Yes, maybe. ZFS is mainly for future use. Do you use the >>>> second option on large filesystems? >>> >>> ZFS is there for "a long time". I feel safe to use it in >>> production on few of our servers. I didn't test UFS+SUJ because >>> it is released in forthcoming 9.0 and we are not deploying >>> current on our servers. >>> >> >> Compared to UFS, ZFS lifetime is relatively short. From my point >> of view ZFS in its present state is too immature to hold mission >> critical data, YMMV. > > UFS2 or UFS2+SU (Soft-Updates) is there for a longer time than ZFS, > but UFS2+SUJ (journaled soft-updates) is there ofr a short time and > not much tested in production. Even UFS2+gjournal is not widely > deployed / tested. > >> On the other hand ZFS needs a lot of redundant disk space and >> memory to work as expected, not to forget cpu-cycles. IMHO, ZFS >> is not 32-bit capable, so there is no way to use it on older and >> small hardware. > > Yes, you are right, ZFS cannot be used in some scenarios. But in > some others scenario, ZFS is the best possible. e.g. for large > flexible storage, I will use ZFS, for database server I will use > UFS2+SU without gjournal. > > [...] > >> >> Did you perform any benchmarks (UFS+Softupdates vs. >> UFS+Gjournal)? If yes, did you compare async mounts + write cache >> enabled (gjournal) to sync mounts + write cache disabled >> (softupdates)? > > I don't have a fancy graphs or tables from benchmarking SW, I just > have real workload experiencies where write cache were enabled in > both cases. > >> If I understand you right, you prefer write speed to data >> consistency in these cases. This may be the right choice in your >> environment. >> >>> From my point of view, I am happy to find all bits restored in >>> /var >> after an unclean shutdown for error analysis and recovery >> purposes, and I hate the vision of having to restore databases >> from backup, even after power failures. Furthermore I am glad, >> only having to wait for gmirror synchronizing to regain >> redundancy after replacing a failed disk. > > I am not sure, you can rely on data consistency with todays HDDs > when cache is enabled even if you use gjournal. You allways lose > content of device cache as rotating (and some flash devices - SSD - > too) is known to lie to OS about "data is written", so you end up > with lost or demaged date with unclean shutdown. AFAIK gjournal guarantees data consistency, even in such scenarios. There is a thread in freebsd-geom (June 2006), subject: "Journaling UFS with gjournal", started by Pawel Jakub Dawidek, which explains some details and prerequisits. As far as I'm getting it, in a gjournaled UFS file system, there is a potential data loss of one journal block at maximum. This is only dependent on whether this last block has been fully written to the journal or not. The underlying file system (UFS) is always consistent. Gmirror/graid only has to pitch in, if one disk fails due to hardware reasons. At present, I don't know of any other software raid configuration (other than ZFS) which combines these strong features, concerning FreeBSD. Please correct me, if I'm wrong. > > Database engines handle it in its own way with own journal log > etc., because some of them can be installed on raw partitions > without underling FS. (also MySQL can do it) Ok, but I'm not sure, if these proprietary (hidden) file systems really do better than UFS+GJOURNAL in case of unclean shutdown(s). > > I rember one case (about 3 years ago) where server remains > unbootable after kernel panic and I spent a couple of hours by > playing with disabling gjournal, doing full fsck on the given > partition etc. It is rare case, but can happen. Sorry to hear of this. Hopefully, Gjournal has improved since then. I don't expect to run into similar problems very often. > >>>> with fdisk + bsdlabel there are not enough partitions in one >>>> slice to hold all the journals, and as I already mentioned I >>>> really want to minimize recovery time. With gmirror + >>>> gjournal I'm able to activate disk write cache without losing >>>> data consistency, which improves performance significantly. >>> >>> According to following commit message, bsdlabel was extended to >>> 26 partitions 3 years ago. >>> http://lists.freebsd.org/pipermail/cvs-all/2007-December/239719.html >>> >>> >> >>> (I didn't tested yet, because I don't need it - we are using two slices >>> on our servers) >> >> I didn't know this, thanks for revealing. I'm not sure if all >> BSD utilities can deal with this. >> >>> >>>>> I see what you are trying to do and it would be nice if >>>>> "all works as one can expect", but the reality is >>>>> different. So I don't think it is good idea to make it as >>>>> you described. >>>>> >>>> I'm not yet fully convinced, that my idea of disk >>>> partitioning is a bad one, so please let me take part in your >>>> negative experiences with gjournal. Thanks in advance. >>> >>> I am not saying that your idea is bad. It just contains some >>> things which I rather avoid. >> >> To summarize some of the pros and cons of this method of disk >> partitioning: pros: - IMHO easy to configure - easy to recover >> from a failed disk (just replace with a suitable one and resync >> with gmirror, needs no preparation of the new disk) - minimal >> downtime after unclean shutdowns (gjournal is responsible for >> this, no sucking fsck on large file systems) - disk write cache >> can and should be enabled (enhanced performance) - all disk / >> partition sizes are supported (even> 2TB) - 32 bit version of >> FreeBSD (i386) is sufficient (small and old hardware remains >> usable) >> >> cons: - danger of overwriting gmirror metadata by an "unfriendly" >> UEFI-BIOS > - somewhat complex initial setup or future changes in partitioning > (you must have prepared right number of partitions for journals, > so adding more partitions is not so easy - in case with UFS2+SUJ or > ZFS, you just add another partition) You're right, nothing's for free. In our environment, I can live with that. As our system disks are all configured similarly, adding partitions almost never happens. I will unfortunately not be able to test UFS2+SUJ together with realistic workload for the next few months, as we are now switching our servers from FreeBSD-6-stable to FreeBSD-8-stable, >> - to be continued ... >> >> Feel free to add some topics here which I am missing. > > One thing in my mind is longstanding problem with gjournal on > heavily loaded servers: > > Aug 16 01:48:28 praha kernel: fsync: giving up on dirty Aug 16 > 01:48:30 praha kernel: 0xc44ba9b4: tag devfs, type VCHR Aug 16 > 01:48:30 praha kernel: usecount 1, writecount 0, refcount 6941 > mountedhere 0xc445b700 Aug 16 01:48:30 praha kernel: flags () Aug > 16 01:48:30 praha kernel: v_object 0xc1548c00 ref 0 pages 192023 > Aug 16 01:48:30 praha kernel: lock type devfs: EXCL (count 1) by > thread 0xc42a7240 (pid 45) Aug 16 01:48:30 praha kernel: dev > mirror/gm0s2e.journal Aug 16 01:48:30 praha kernel: GEOM_JOURNAL: > Cannot suspend file system /vol0 (error=35). > > Aug 16 02:32:34 praha kernel: fsync: giving up on dirty Aug 16 > 02:32:34 praha kernel: 0xc44ba9b4: tag devfs, type VCHR Aug 16 > 02:32:34 praha kernel: usecount 1, writecount 0, refcount 1418 > mountedhere 0xc445b700 Aug 16 02:32:34 praha kernel: flags () Aug > 16 02:32:34 praha kernel: v_object 0xc1548c00 ref 0 pages 128123 > Aug 16 02:32:34 praha kernel: lock type devfs: EXCL (count 1) by > thread 0xc42a7240 (pid 45) Aug 16 02:32:34 praha kernel: dev > mirror/gm0s2e.journal Aug 16 02:32:34 praha kernel: GEOM_JOURNAL: > Cannot suspend file system /vol0 (error=35). > > This error messages is seen on theme almost every second day and > nobody gives me suitable explanation what it really means / what it > cause. The only answer I got was something like "it is not > harmfull"... then why it is logged at all? I haven't yet seen such kind of messages. Perhaps our servers are not loaded heavily enough? ;-) BTW, which BSD version are you using with gjournal? > > So today I removed gjournal from the next older server. I will try > UFS2+SUJ with 9.0 as one of the possible ways for a future setups, > where ZFS cannot be used. I would be glad to hear from your hands-on experience in this topic. > > Miroslav Lachman -- Alfred Bartsch Data-Service GmbH From owner-freebsd-geom@FreeBSD.ORG Fri Oct 28 10:28:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028DF1065670; Fri, 28 Oct 2011 10:28:27 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from mikako.shopkeeper.de (mikako.shopkeeper.de [82.119.175.20]) by mx1.freebsd.org (Postfix) with ESMTP id 64EFD8FC15; Fri, 28 Oct 2011 10:28:26 +0000 (UTC) Received: from avalon.dobu.local (p508D47DF.dip.t-dialin.net [80.141.71.223]) (authenticated bits=0) by mikako.shopkeeper.de (8.14.3/8.14.3) with ESMTP id p9S9mTkq037682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 11:48:31 +0200 (CEST) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.4/8.14.2) with ESMTP id p9S9mS6H001886; Fri, 28 Oct 2011 11:48:28 +0200 (CEST) (envelope-from sascha@avalon.dobu.local) Received: (from sascha@localhost) by avalon.dobu.local (8.14.4/8.14.4/Submit) id p9S9mSCm001885; Fri, 28 Oct 2011 11:48:28 +0200 (CEST) (envelope-from sascha) Date: Fri, 28 Oct 2011 11:48:28 +0200 From: Sascha Klauder To: Garrett Cooper Message-ID: <20111028094828.GA1781@trimind.de> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.97.2 at mikako.shopkeeper.de X-Virus-Status: Clean Cc: antik@bsd.ee, freebsd-geom@freebsd.org, current@freebsd.org, Martin Wilke Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sascha@trimind.de List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 10:28:27 -0000 On Tue, 2011-10-25 12:27 -0700, Garrett Cooper wrote: > On Tue, Oct 25, 2011 at 11:15 AM, Martin Wilke wrote: > > I face the same error since upgrade from 8.2 to 9.0RC1, is there any way to fix that? > errno == 19 => ENODEV -- so the question is, what device is missing? I've got bitten by this as well when trying a source up- grade of a freshly installed 8.2-RELEASE system that had gmirror configured after installation according to the procedure in the Handbook. The 9.0-RC1 kernel drops to the mountroot prompt when booting with GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) ... Trying to mount root from ufs:/dev/mirror/gm0s1a [rw]... mountroot: waiting for device /dev/mirror/gm0s1a ... Mounting from ufs:/dev/mirror/gm0s1a failed with error 19. which can be circumvented by setting the loader tunable kern.geom.part.check_integrity=0. The only immediately obvious difference I could find is that "gpart list" reports the last sector of the mirror/gm0 device different from the 8.2 kernel (490350670 vs 490350608). "gpart list" output when running the 8.2-RELEASE kernel: http://arwen.shopkeeper.de/~sascha/gpart-82 vs 9.0-RC1: http://arwen.shopkeeper.de/~sascha/gpart-90 Image of the MBR: http://arwen.shopkeeper.de/~sascha/ada0-mbr.bin Cheers, -sascha From owner-freebsd-geom@FreeBSD.ORG Fri Oct 28 20:18:49 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EED2C106564A; Fri, 28 Oct 2011 20:18:49 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C74348FC08; Fri, 28 Oct 2011 20:18:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9SKIn9L035018; Fri, 28 Oct 2011 20:18:49 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9SKInVK035014; Fri, 28 Oct 2011 20:18:49 GMT (envelope-from ae) Date: Fri, 28 Oct 2011 20:18:49 GMT Message-Id: <201110282018.p9SKInVK035014@freefall.freebsd.org> To: bruce@cran.org.uk, ae@FreeBSD.org, freebsd-geom@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/144905: [geom][geom_part] panic in gpart_ctlreq when unplugging card reader X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:18:50 -0000 Synopsis: [geom][geom_part] panic in gpart_ctlreq when unplugging card reader State-Changed-From-To: open->feedback State-Changed-By: ae State-Changed-When: Fri Oct 28 20:18:29 UTC 2011 State-Changed-Why: Feedback requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=144905 From owner-freebsd-geom@FreeBSD.ORG Fri Oct 28 20:20:10 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CCC1106564A for ; Fri, 28 Oct 2011 20:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 732AC8FC08 for ; Fri, 28 Oct 2011 20:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9SKKA3H035251 for ; Fri, 28 Oct 2011 20:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9SKKAuF035250; Fri, 28 Oct 2011 20:20:10 GMT (envelope-from gnats) Date: Fri, 28 Oct 2011 20:20:10 GMT Message-Id: <201110282020.p9SKKAuF035250@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: kern/144905: [geom][geom_part] panic in gpart_ctlreq when unplugging card reader X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:20:10 -0000 The following reply was made to PR kern/144905; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-followup@FreeBSD.org, bruce@cran.org.uk Cc: Subject: Re: kern/144905: [geom][geom_part] panic in gpart_ctlreq when unplugging card reader Date: Sat, 29 Oct 2011 00:11:53 +0400 Hi, Bruce, Can you reproduce this problem after r226880? -- WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Sat Oct 29 16:23:03 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38CA11065678; Sat, 29 Oct 2011 16:23:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 10BEE8FC15; Sat, 29 Oct 2011 16:23:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9TGN2Y5004449; Sat, 29 Oct 2011 16:23:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9TGN2jO004445; Sat, 29 Oct 2011 16:23:02 GMT (envelope-from linimon) Date: Sat, 29 Oct 2011 16:23:02 GMT Message-Id: <201110291623.p9TGN2jO004445@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162147: [geom] mirror GPT: GPT rejected -- may not be recoverable X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:23:03 -0000 Old Synopsis: GEOM: mirror GPT New Synopsis: [geom] mirror GPT: GPT rejected -- may not be recoverable Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 29 16:22:05 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162147