From owner-freebsd-geom@FreeBSD.ORG Sun Jun 17 10:32:37 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB17E106566B for ; Sun, 17 Jun 2012 10:32:37 +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 9B4FE8FC0C for ; Sun, 17 Jun 2012 10:32:37 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 1B3A7348; Sun, 17 Jun 2012 12:32:29 +0200 (CEST) Date: Sun, 17 Jun 2012 12:30:29 +0200 From: Pawel Jakub Dawidek To: "John W. O'Brien" Message-ID: <20120617103029.GK1399@garage.freebsd.pl> References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> <4FDB16B4.4060705@saltant.com> <20120615200924.GE1399@garage.freebsd.pl> <4FDBB453.9060806@saltant.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JsihDCElWRmQcbOr" Content-Disposition: inline In-Reply-To: <4FDBB453.9060806@saltant.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Sun, 17 Jun 2012 10:32:38 -0000 --JsihDCElWRmQcbOr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2012 at 06:16:51PM -0400, John W. O'Brien wrote: > @@ -58,7 +58,7 @@ > .Op Fl i Ar iterations > .Op Fl J Ar newpassfile > .Op Fl K Ar newkeyfile > -.Op Fl l Ar keylen > +.Op Fl l Ar datakeylen I wouldn't change that. It is called 'keylen' also in geli(8) usage. > @@ -83,7 +83,7 @@ > .Op Fl d > .Op Fl a Ar aalgo > .Op Fl e Ar ealgo > -.Op Fl l Ar keylen > +.Op Fl l Ar datakeylen Same here. > -.It Fl l Ar keylen > -Key length to use with the given cryptographic algorithm. > +.It Fl l Ar datakeylen And here. All the rest looks good. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --JsihDCElWRmQcbOr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/dscQACgkQForvXbEpPzRQ2ACfUBY+I4FQKUJme4eh+qMMVRMy TVcAoNGuMZLgfTow+8ZfLP8BgZTjubuh =7GsB -----END PGP SIGNATURE----- --JsihDCElWRmQcbOr-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 18 03:49:07 2012 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 3BB3E106566B; Mon, 18 Jun 2012 03:49:07 +0000 (UTC) (envelope-from nwhitehorn@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F29B8FC12; Mon, 18 Jun 2012 03:49:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5I3n6sx067232; Mon, 18 Jun 2012 03:49:06 GMT (envelope-from nwhitehorn@freefall.freebsd.org) Received: (from nwhitehorn@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5I3n6Uu067228; Mon, 18 Jun 2012 03:49:06 GMT (envelope-from nwhitehorn) Date: Mon, 18 Jun 2012 03:49:06 GMT Message-Id: <201206180349.q5I3n6Uu067228@freefall.freebsd.org> To: nwhitehorn@FreeBSD.org, freebsd-sysinstall@FreeBSD.org, freebsd-geom@FreeBSD.org From: nwhitehorn@FreeBSD.org Cc: Subject: Re: bin/169077: bsdinstall(8) does not use partition labels in /etc/fstab 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, 18 Jun 2012 03:49:07 -0000 Synopsis: bsdinstall(8) does not use partition labels in /etc/fstab Responsible-Changed-From-To: freebsd-sysinstall->freebsd-geom Responsible-Changed-By: nwhitehorn Responsible-Changed-When: Mon Jun 18 03:48:00 UTC 2012 Responsible-Changed-Why: Reassigning to freebsd-geom. Using partition labels is not currently possible without integration of partition labels into the gpart module. The current mechanism that makes labeled devices show up in /dev is unreliable, does not apply to all partition schemes, and may not be present. There were experimental patches from ae@ but unfortunately I do not believe they have been committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=169077 From owner-freebsd-geom@FreeBSD.ORG Mon Jun 18 11:07:48 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4048A1065673 for ; Mon, 18 Jun 2012 11:07:48 +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 207F58FC26 for ; Mon, 18 Jun 2012 11:07:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5IB7mhQ007984 for ; Mon, 18 Jun 2012 11:07:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5IB7leL007982 for freebsd-geom@FreeBSD.org; Mon, 18 Jun 2012 11:07:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Jun 2012 11:07:47 GMT Message-Id: <201206181107.q5IB7leL007982@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, 18 Jun 2012 11:07:48 -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 -------------------------------------------------------------------------------- a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s 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/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres 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] [regression] ABI change without version bump 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/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/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 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 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. 70 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 18 12:42:10 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 826501065672; Mon, 18 Jun 2012 12:42:10 +0000 (UTC) (envelope-from john@saltant.com) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by mx1.freebsd.org (Postfix) with ESMTP id 55BF58FC1A; Mon, 18 Jun 2012 12:42:10 +0000 (UTC) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 6581A67C06E; Mon, 18 Jun 2012 05:42:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=saltant.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=saltant.com; b=bpCf89QLM4VR042su0F4hzbOqARBwuanM/5RSgh5RnI6lrwG3nNbR1m2SfPQJ 6d/NCUdKLY/qTjqweTa2GPd1KQqcg7gJ7DG4xU7YkBLTxVGeJH0BB1MkKkeC8QHV XUtWGwSIrvs2qSLLQOiqKTtYaDPHRmExFcdvxMEPk8kEBE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=saltant.com; bh=bfpU2 3juBPv+uPoNbDqpLkOoVOE=; b=UpT5h6oIvmqdYdyOatpN9Jm7lQu+kfXkME0BC uSTWpmpM0fJJ/NvgCf7PmVwAV3cfkSN7DJVnNP85s1DUn9E/rUngGEq36uWbU5xq MsPkMRWaX8RBHSI4bNQShgkyXe4GAA+Aob60UV9RMVyZ26YuwJh+cSCNGtyuZ5jQ lEwkhk= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 18F2E67C06D; Mon, 18 Jun 2012 05:42:04 -0700 (PDT) Message-ID: <4FDF221A.7080205@saltant.com> Date: Mon, 18 Jun 2012 08:42:02 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> <4FDB16B4.4060705@saltant.com> <20120615200924.GE1399@garage.freebsd.pl> <4FDBB453.9060806@saltant.com> <20120617103029.GK1399@garage.freebsd.pl> In-Reply-To: <20120617103029.GK1399@garage.freebsd.pl> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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, 18 Jun 2012 12:42:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/17/2012 06:30 AM, Pawel Jakub Dawidek wrote: > On Fri, Jun 15, 2012 at 06:16:51PM -0400, John W. O'Brien wrote: >> @@ -58,7 +58,7 @@ .Op Fl i Ar iterations .Op Fl J Ar newpassfile >> .Op Fl K Ar newkeyfile -.Op Fl l Ar keylen +.Op Fl l Ar >> datakeylen > > I wouldn't change that. It is called 'keylen' also in geli(8) > usage. > >> @@ -83,7 +83,7 @@ .Op Fl d .Op Fl a Ar aalgo .Op Fl e Ar ealgo >> -.Op Fl l Ar keylen +.Op Fl l Ar datakeylen > > Same here. > >> -.It Fl l Ar keylen -Key length to use with the given >> cryptographic algorithm. +.It Fl l Ar datakeylen > > And here. The /keylen/datakeylen/ change shows up in four places, including the usage section. % grep -n keylen geli.8 61:.Op Fl l Ar datakeylen 86:.Op Fl l Ar datakeylen 322:.It Fl l Ar datakeylen 445:.It Fl l Ar datakeylen I thought about changing the 'keyfile' parameter name too, but that applies in loader.conf, so I left it alone. In any case, I don't feel that strongly about it. I'll back out those four lines and post an updated patch to the PR. John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP3yIYAAoJEEdKvTwaez9wNJYH/3rowPCQIxqiVrd4f0OmYsn7 Us9Sx/udaknznfhW824r040EsXZDD0uC/Ka22XKMLXwAeTMIrQPGdUox6sxMuQuF 6S/g0I3rti+ECwEmERnIYtbspHWO1HktvrpStdtwVag98H9uFtd9dKhPYMJIK96t jFKx5VDUyP5KL+4WbM/0avRJqilGs5Xk4nnZ2Ad68H6XZzWPd7VRMtaMaQrQ6Bmt 43xG4nalbQ7bCzWSE0rhcU+znAVxKtlG8cbH7H/lvcgbrUUK10L0sBDHZ4qjbciC V8dvg3rfQvUzZsA9gzWwBtbxRSyB4XhRmryckc8cYhldDDE1P9pB1PewfyVxv/s= =Spam -----END PGP SIGNATURE----- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 09:48:25 2012 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 8A88E106564A for ; Tue, 19 Jun 2012 09:48:25 +0000 (UTC) (envelope-from rudi.kramer@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5154A8FC0A for ; Tue, 19 Jun 2012 09:48:25 +0000 (UTC) Received: by obcni5 with SMTP id ni5so12494328obc.13 for ; Tue, 19 Jun 2012 02:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=fj59NiVEkmX94jNAK0VUVxEs7aPXlVbkK/R5Avf7/AI=; b=hoJ8gEO1bXkt8XzkeJneiOcRUnfk5pBqw7oc4nU2J0BdJhd45jseIv9c8M98pWVzcl 1dv/idQVryJyozieacieBjIP79cl7my9DEGnuveIzY/iP4EpktZjWf3nNiIXwcsq0icg 0QxWq5xsKi+xlZgFNsNQzqxwkLUMPjINh1rBX6yHhZGGQWMxhXBitSI3cFgHcdBJJMS8 S8/13hKun4Tfs/xhbJpz7Y9dk74eCBXPmNfnU+6N7woZ4IKaLCIyfURo90tU78tHGzIk ealKwS2SjNqQiwCoNfZWrbe7KHeFahsjdt3kH1jTd58jBKxFjV0KZ5EcyHnyoD+TRBdW n2iw== Received: by 10.60.2.138 with SMTP id 10mr18932251oeu.58.1340099304917; Tue, 19 Jun 2012 02:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.58.135 with HTTP; Tue, 19 Jun 2012 02:48:04 -0700 (PDT) From: Rudi Kramer Date: Tue, 19 Jun 2012 11:48:04 +0200 Message-ID: To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Gconcat + growfs: we are not growing 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, 19 Jun 2012 09:48:25 -0000 Hello, I am running a FreeBSD 8.2-RELEASE-p6 GENERIC (amd64) home media server I wanted to find a way to add multiple disks to a single volume without using raid because I am not too fussy about the data but I dont want one disk failing to cause me to loose all my data. I found gconcat and it seemed to be the exact application I was looking for. I first created a volume with a single drive (1.5 TB) so that I could migrate all my data across. (I was using zfs but as stated I dont need/want raid). # gconcat label -v data /dev/ad4 # newfs /dev/concat/data # mount /dev/concat/data /mnt Everything seemed fine and I was able to migrate my data across with no problems. I then tried to add two more drives (1 TB each) using the following commands: # umount /dev/concat/data # gconcat label data /dev/ad4 /dev/ad5 /dev/ad6 Once again everything looked fine and when I execute gconcat list I can see the drives are added and the space allocation is correct. # gconcat list Geom name: data State: UP Status: Total=3, Online=3 Type: AUTOMATIC ID: 1745188505 Providers: 1. Name: concat/data Mediasize: 3500711680512 (3.2T) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: ad4 Mediasize: 1500301910016 (1.4T) Sectorsize: 512 Mode: r0w0e0 Start: 0 End: 1500301909504 2. Name: ad5 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r0w0e0 Start: 1500301909504 End: 2500506795008 3. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r0w0e0 Start: 2500506795008 End: 3500711680512 The problem comes when I try to grow the file system using growfs I get the following error: growfs: we are not growing (732569291->635590051) I have tried using google to found out what could be causing the issue and I found some information about creating a disk label but bsdlabel doesn't work on large drives and I'm not sure this is even the correct answer and so I decided to mail the list and see if anyone had some advice for me. Regards Rudi From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 13:17:51 2012 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 AD141106564A for ; Tue, 19 Jun 2012 13:17:51 +0000 (UTC) (envelope-from lee@dilkie.com) Received: from data.snhdns.com (data.snhdns.com [208.76.82.136]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6328FC1A for ; Tue, 19 Jun 2012 13:17:51 +0000 (UTC) Received: from [142.46.160.218] (port=51350 helo=[206.51.1.11]) by data.snhdns.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SgxJG-0002Y1-OF; Tue, 19 Jun 2012 08:13:27 -0400 Message-ID: <4FE06CF2.7040108@dilkie.com> Date: Tue, 19 Jun 2012 08:13:38 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Rudi Kramer References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/mixed; boundary="------------050507040200090306020106" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - data.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dilkie.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 13:17:51 -0000 This is a multi-part message in MIME format. --------------050507040200090306020106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Rudi, Seems like you are hitting the same growfs bug that gets all of us that try to do this simple task. growfs needs a patch to use 64 bit math inside... I created such a beast a while back, based on some earlier work and fixed it up a bit myself. I'm a bit surprised that this hasn't been fixed in a newer freebsd release but such is life I guess. I'm running 7.4-STABLE FreeBSD and the version of growfs.c that my patch is based on is: __FBSDID("$FreeBSD: src/sbin/growfs/growfs.c,v 1.25.2.5 2011/03/05 04:33:42 brucec Exp $"); I've attached my patch/diff to fix things up.... you may have to modify it based ont he version of growfs.c that you have. It may also fail... it's worked for me through several "growings" of my gconcat array but YMMV as usual -lee On 6/19/2012 5:48 AM, Rudi Kramer wrote: > Hello, > > I am running a FreeBSD 8.2-RELEASE-p6 GENERIC (amd64) home media server I > wanted to find a way to add multiple disks to a single volume without using > raid because I am not too fussy about the data but I dont want one disk > failing to cause me to loose all my data. > > I found gconcat and it seemed to be the exact application I was looking for. > > I first created a volume with a single drive (1.5 TB) so that I could > migrate all my data across. (I was using zfs but as stated I dont need/want > raid). > > # gconcat label -v data /dev/ad4 > # newfs /dev/concat/data > # mount /dev/concat/data /mnt > > Everything seemed fine and I was able to migrate my data across with no > problems. > > I then tried to add two more drives (1 TB each) using the following > commands: > > # umount /dev/concat/data > # gconcat label data /dev/ad4 /dev/ad5 /dev/ad6 > > Once again everything looked fine and when I execute gconcat list I can see > the drives are added and the space allocation is correct. > > # gconcat list > Geom name: data > State: UP > Status: Total=3, Online=3 > Type: AUTOMATIC > ID: 1745188505 > Providers: > 1. Name: concat/data > Mediasize: 3500711680512 (3.2T) > Sectorsize: 512 > Mode: r0w0e0 > Consumers: > 1. Name: ad4 > Mediasize: 1500301910016 (1.4T) > Sectorsize: 512 > Mode: r0w0e0 > Start: 0 > End: 1500301909504 > 2. Name: ad5 > Mediasize: 1000204886016 (932G) > Sectorsize: 512 > Mode: r0w0e0 > Start: 1500301909504 > End: 2500506795008 > 3. Name: ad6 > Mediasize: 1000204886016 (932G) > Sectorsize: 512 > Mode: r0w0e0 > Start: 2500506795008 > End: 3500711680512 > > The problem comes when I try to grow the file system using growfs I get the > following error: > > growfs: we are not growing (732569291->635590051) > > I have tried using google to found out what could be causing the issue and > I found some information about creating a disk label but bsdlabel doesn't > work on large drives and I'm not sure this is even the correct answer and > so I decided to mail the list and see if anyone had some advice for me. > > Regards > Rudi > _______________________________________________ > 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" --------------050507040200090306020106 Content-Type: text/plain; charset=windows-1252; name="growfs.diff.64bit_fix" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="growfs.diff.64bit_fix" 159c159 < static void get_dev_size(int, int *); --- > static void get_dev_size(int, u_int64_t *); 1919c1919 < get_dev_size(int fd, int *size) --- > get_dev_size(int fd, u_int64_t *size) 1964c1964 < unsigned int size=0; --- > u_int64_t size=0; 1972c1972 < u_int32_t p_size; --- > u_int64_t p_size; 1986c1986 < size=(size_t)atol(optarg); --- > size=(size_t)atoll(optarg); 2081c2081 < p_size = pp->p_size; --- > p_size = (u_int64_t)pp->p_size; /* number sectors in partition table is 32 bits but we use 64 bit temp */ 2083c2083 < get_dev_size(fsi, &p_size); --- > get_dev_size(fsi, &p_size); 2120c2120 < sblock.fs_size = dbtofsb(&osblock, p_size); --- > sblock.fs_size = dbtofsb(&osblock, p_size); /* fs_size is 64 bits, p_size is too */ 2123c2123 < errx(1, "there is not enough space (%d < %d)", --- > errx(1, "there is not enough space (%jd < %jd)", 2126c2126 < sblock.fs_size = dbtofsb(&osblock, size); --- > sblock.fs_size = dbtofsb(&osblock, size); /* size is 64 bit now */ 2211c2211 < sblock.fs_size = sblock.fs_ncg * sblock.fs_fpg; --- > sblock.fs_size = (int64_t)sblock.fs_ncg * (int64_t)sblock.fs_fpg; 2222c2222,2223 < errx(1, "not enough new space"); --- > errx(1, "not enough new space (II) (%jd->%jd)", > (intmax_t)osblock.fs_size, (intmax_t)sblock.fs_size); --------------050507040200090306020106-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 14:26:45 2012 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 6C34B106566B for ; Tue, 19 Jun 2012 14:26:45 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 32B518FC0C for ; Tue, 19 Jun 2012 14:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Cc:Date:References:Subject:To:Content-Type; bh=u0I2sdTyloqKEYtV9YaF0PWbiYJX+wk/M4dX7+6lcKE=; b=UpLHYdLIArJEiFwAyPq78JiwxiyXB8C21wQN/GTgyWohk92QaKVo+w1sVJVt4fJYzVhQEMK1IR/NaknyzSTmT6OcE4UOwYMMoP4MtNTaOE9td8hSJIIBhjofWT583ve5; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SgzOD-000BD6-70; Tue, 19 Jun 2012 09:26:41 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340115995-94480-94479/5/9; Tue, 19 Jun 2012 14:26:35 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-geom@freebsd.org References: <20120619131011.GA76729@neutralgood.org> Date: Tue, 19 Jun 2012 09:26:34 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120619131011.GA76729@neutralgood.org> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Cc: kpneal@pobox.com Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 14:26:45 -0000 On Tue, 19 Jun 2012 08:10:11 -0500, wrote: > You do realize that if you have a single filesystem spread across > multiple > disks with gconcat then one drive failing will kill the entire > filesystem, > right? Media files are usually categorized under "non-important data" unless they're your life's work. I'm sure he's just trying to create more storage for his FreeBSD based media player or storage backend. From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 15:22:34 2012 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 B451E1065676 for ; Tue, 19 Jun 2012 15:22:34 +0000 (UTC) (envelope-from rudi.kramer@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2C08FC12 for ; Tue, 19 Jun 2012 15:22:34 +0000 (UTC) Received: by yhgm50 with SMTP id m50so5651324yhg.13 for ; Tue, 19 Jun 2012 08:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4dAKTsD/2N3ff5/FlXcoGFwb0NsDn6ERk1Mq7Xi3PHQ=; b=05L+8u/ticeEeBl70d6cpD5Xq014BRBiumJciUvV8F8s+Un0MyV/BOcxt0S89Vf/l3 uSi/Wu0N8i/zhGu3f+MEAjjdr55rPT+eOZuszgiEtCkqvFo+fjR8KlKSzUm/9LmEBxto RNrxGbmjhInebA+UChlk8xJCfOY8kIr2+TjvRUUrLcVxFMKbcg2ewXTsisyVT7m+0x+8 W7vEA+FETWFOmtTTJjjpNhtcRynRYtj/eFTlf+p+M+7zzGv79xVhzO/KfgzlvkXfQYRs rxsR7ONzlzxo6BJaHdEngbYku9GZ8xUklbS0+hOcfdasEHRssQYAeEMV2Mx9pCZ9yNOJ YApA== Received: by 10.60.2.138 with SMTP id 10mr20068000oeu.58.1340119353834; Tue, 19 Jun 2012 08:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.58.135 with HTTP; Tue, 19 Jun 2012 08:22:12 -0700 (PDT) In-Reply-To: <20120619131011.GA76729@neutralgood.org> References: <20120619131011.GA76729@neutralgood.org> From: Rudi Kramer Date: Tue, 19 Jun 2012 17:22:12 +0200 Message-ID: To: kpneal@pobox.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 15:22:34 -0000 On 19 June 2012 15:10, wrote: > > > You do realize that if you have a single filesystem spread across multiple > disks with gconcat then one drive failing will kill the entire filesystem, > right? > > To avoid this you need either mirroring or one of the other forms of raid. > > What's the issue with raid? > Crap I thought that I would just lose the information on that drive and not the entire volume :/ I dont have any issues with raid but I want to maximise my storage and I dont really care if I lose the data. It would just be nice if I didn't loose everything cause of one disk dying. Maybe I should be looking at something like unionfs but from the man page it looks very old, out of date and slightly dangerous. All the things I like in cheese but not in file systems. Rudi From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 15:33:13 2012 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 6E9A9106564A for ; Tue, 19 Jun 2012 15:33:13 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id EA2C38FC1E for ; Tue, 19 Jun 2012 15:33:12 +0000 (UTC) Received: by eeke49 with SMTP id e49so2367334eek.13 for ; Tue, 19 Jun 2012 08:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=EBj2SDdqqzExGfa/slDeTZRvL0dHCv+r4grYBT31RwM=; b=UnJoajZ2HCWdPx8OV3y/te4iwtSjrHKmd2/TjXsyatNc48djr+iQHaj2GXCW3IYcob 7VB3zlQeJA8McdTiyWsi96LfwV8AW9gfgcgK8vF9CXHKqt2qN6tREZunDgFmxrFxDdas HF9ShBEUkQWvDzYK6+Kd2y4h5RX7hJ5qz+iXbn5LH8GtSO/NjXyzuTHxEJ+5ID9Zspjk 6L+lg0CTkCzoXMDrFyhxZPNiTAOkhExdJHpQnBeL5dxiBEYLQybfJQaEKPVQXUxZHQIO VxDdFqUpa4PytQSYlVWrhqj0Kpx6HPfaYRZqaCnRMjyNPnDptjRCYqPj0OC8cyOyiKHG NLdA== Received: by 10.14.127.202 with SMTP id d50mr4389416eei.193.1340119991764; Tue, 19 Jun 2012 08:33:11 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id t3sm77484800eeb.15.2012.06.19.08.33.10 (version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 08:33:11 -0700 (PDT) Date: Tue, 19 Jun 2012 16:33:08 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20120619163308.5cc9930d@gumby.homeunix.com> In-Reply-To: References: <20120619131011.GA76729@neutralgood.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 15:33:13 -0000 On Tue, 19 Jun 2012 09:26:34 -0500 Mark Felder wrote: > On Tue, 19 Jun 2012 08:10:11 -0500, wrote: > > > You do realize that if you have a single filesystem spread across > > multiple > > disks with gconcat then one drive failing will kill the entire > > filesystem, > > right? > > Media files are usually categorized under "non-important data" > unless they're your life's work. I'm sure he's just trying to create > more storage for his FreeBSD based media player or storage backend. That's not consistent with: " I am not too fussy about the data but I dont want one disk failing to cause me to loose all my data." From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 15:56:41 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A36D61065672 for ; Tue, 19 Jun 2012 15:56:41 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7846C8FC15 for ; Tue, 19 Jun 2012 15:56:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=9I48tGvoJoec75LmwGsVWG0s65GDJhvRcYlXK3uFHHM=; b=tAVytWU62pb7bX5YCQsW4nP0IXR14dk1CIoLtZG9r/R8+fkCocNjY6NlwPImdQeYWf/SaiuJCX4ZbFQtRxfSccZZJxyAyVnqJHLYX/Bq4r8tGL1IsfFPaUU9wglQ8uDB; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh0nF-000FNP-Eo for freebsd-geom@freebsd.org; Tue, 19 Jun 2012 10:56:41 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340121390-94480-94479/5/11; Tue, 19 Jun 2012 15:56:30 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-geom@freebsd.org References: <20120619131011.GA76729@neutralgood.org> <20120619163308.5cc9930d@gumby.homeunix.com> Date: Tue, 19 Jun 2012 10:56:30 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120619163308.5cc9930d@gumby.homeunix.com> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 15:56:41 -0000 On Tue, 19 Jun 2012 10:33:08 -0500, RW wrote: > That's not consistent with: " I am not too fussy about the data but I > dont want one disk failing to cause me to loose all my data." My brain thought what he wanted to be more along the lines of "I don't want a failed grow operation to make me lose all my data" but even that doesn't make much sense. I've no idea why I misinterpreted his original post. From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 16:52:04 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FE5C106564A for ; Tue, 19 Jun 2012 16:52:04 +0000 (UTC) (envelope-from lee@dilkie.com) Received: from data.snhdns.com (data.snhdns.com [208.76.82.136]) by mx1.freebsd.org (Postfix) with ESMTP id 127238FC17 for ; Tue, 19 Jun 2012 16:52:04 +0000 (UTC) Received: from [216.191.234.70] (port=32598 helo=[10.39.164.100]) by data.snhdns.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sh1ep-0004pu-B4; Tue, 19 Jun 2012 12:51:59 -0400 Message-ID: <4FE0AE31.20709@dilkie.com> Date: Tue, 19 Jun 2012 12:52:01 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rudi Kramer References: <20120619131011.GA76729@neutralgood.org> In-Reply-To: X-Enigmail-Version: 1.4.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - data.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dilkie.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kpneal@pobox.com, freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing 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, 19 Jun 2012 16:52:04 -0000 What I did to meet my needs of "growable but reliable" was to use a gconcat array of gmirrors. I never did add the second drives to the gmirror's so I never did get the reliability part of my dream. But at least you can create a gmirror with one drive and a gconcat of that. This was all before ZFS, which I think handles this better now (if it works). On 6/19/2012 11:22 AM, Rudi Kramer wrote: > On 19 June 2012 15:10, wrote: > >> >> You do realize that if you have a single filesystem spread across multiple >> disks with gconcat then one drive failing will kill the entire filesystem, >> right? >> >> To avoid this you need either mirroring or one of the other forms of raid. >> >> What's the issue with raid? >> > Crap I thought that I would just lose the information on that drive and not > the entire volume :/ > > I dont have any issues with raid but I want to maximise my storage and I > dont really care if I lose the data. It would just be nice if I didn't > loose everything cause of one disk dying. Maybe I should be looking at > something like unionfs but from the man page it looks very old, out of date > and slightly dangerous. All the things I like in cheese but not in file > systems. > > Rudi > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 18:24:49 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E3441065670 for ; Tue, 19 Jun 2012 18:24:49 +0000 (UTC) (envelope-from steven.haber@isilon.com) Received: from mexforwardwc.lss.emc.com (mexforwardwc.lss.emc.com [137.69.117.200]) by mx1.freebsd.org (Postfix) with ESMTP id 341338FC0A for ; Tue, 19 Jun 2012 18:24:49 +0000 (UTC) Received: from scl02-01d02-si01.isus.emc.com (scl02-01d02-si01.isus.emc.com [137.69.225.84]) by mexforwardwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5JIOgC0014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 11:24:42 -0700 Received: from mailhubwc.lss.emc.com (mailhubscprd03.lss.emc.com [137.69.224.145]) by scl02-01d02-si01.isus.emc.com (RSA Interceptor); Tue, 19 Jun 2012 11:24:23 -0700 Received: from seacasht01.desktop.isilon.com (seacasht01.isilon.com [137.69.159.79]) by mailhubwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5JIOLdv002451; Tue, 19 Jun 2012 11:24:21 -0700 Received: from seaxch01.isilon.com (137.69.158.60) by SEACASHT01.desktop.isilon.com (137.69.159.79) with Microsoft SMTP Server id 14.2.298.4; Tue, 19 Jun 2012 11:24:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2012 11:24:03 -0700 Message-ID: <56CE86D6660FF84498426FA7A33170B403589417@seaxch01.desktop.isilon.com> In-Reply-To: <20120611225304.GK2337@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geom / destroy_dev() deadlock Thread-Index: Ac1IJQoi3iwR12mRToa/jZtMD4FdHgGHgpnQ References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403429115@seaxch01.desktop.isilon.com> <20120611225304.GK2337@deviant.kiev.zoral.com.ua> From: Steven Haber To: Konstantin Belousov X-EMM-MHVC: 1 Cc: freebsd-geom@freebsd.org Subject: RE: Geom / destroy_dev() deadlock 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, 19 Jun 2012 18:24:49 -0000 > On Mon, Jun 11, 2012 at 03:27:39PM -0700, Steven Haber wrote: > > I do not understand what you are proposing. Could you, please, show > > > the patch ? > >=20 > > --- > > src/sys/geom/geom_dev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/src/sys/geom/geom_dev.c b/src/sys/geom/geom_dev.c > > index 38251e1..787235a 100644 > > --- a/src/sys/geom/geom_dev.c > > +++ b/src/sys/geom/geom_dev.c > > @@ -497,7 +497,7 @@ g_dev_orphan(struct g_consumer *cp) > > =20 > > /* Destroy the struct cdev *so we get no more requests */ > > unit =3D dev2unit(dev); > > - destroy_dev(dev); > > + destroy_dev_sched(dev); > > free_unr(unithdr, unit); > > =20 > > /* Wait for the cows to come home */ > > From: Konstantin Belousov > Sent: Monday, June 11, 2012 3:53 PM > To: Steven Haber > Cc: freebsd-geom@freebsd.org > Subject: Re: Geom / destroy_dev() deadlock > > Did you noted the comment above the block you changing ? > The patch would cause races allowing arbitrary kernel memory corruption. > > The moment when the cdev is destroyed is somewhere in future, while > structures that the cdev reference are freed synchronously. > > I tried to put some safety measures into destroy_dev_sched(9), namely > CDP_SCHED_DTR flag that somewhat reduces the possibility of usermode > accessing cdev after destroy_dev_sched(), but this cannot be eliminated > entirely. So destroy_dev_sched() is inherently racey. That explains why there aren't many examples of usage in the kernel. Without doing a scheduled destroy, can you think of any way to prevent the devdrn/geom deadlock? From the original discussion: GEOM calls destroy_dev() while holding the topology lock. Destroy_dev() wants to destroy device, but can't because there are threads that still have it open. The threads can't close it, because to close it they need the topology lock. There may be additional locking that can be done in the dev layer, like a third sleepable lock. We could also set a devdrn flag on the cdev to cause g_dev calls to return with an error prior to taking the topology lock. Steven From owner-freebsd-geom@FreeBSD.ORG Wed Jun 20 07:16:15 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACF65106564A for ; Wed, 20 Jun 2012 07:16:15 +0000 (UTC) (envelope-from rudi.kramer@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 34BB48FC08 for ; Wed, 20 Jun 2012 07:16:15 +0000 (UTC) Received: by obbun3 with SMTP id un3so604501obb.13 for ; Wed, 20 Jun 2012 00:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AB+Nr+pXsh0v++juXe3TXt2/Xyw11DGyQK9yXdYIMRk=; b=MJFR152dOHsSy9SCV7B8NlOdU/DMLKjAXdyTVaP/FFTu3f2MMeb/7POirZYNS6BY4O EIk9OXXj4zQrP2i+P3rUkF9GitfizvRLLzljxJqfSvpiCb8YtWOOM6m/myVcdu2lsKTS xtUVfBT1pWWbI66Q+hYe4qVVhPHbMmNxWB0xixJhBS/5f5u4F19STV3mYaLp0hoem8DG aDZijWpc6Kiid/hWx0lhsTfAi8OpRNaIZcRZyu+9NJQJMdPNAh98KmDeoTRLwtjpKZZJ zz7JKL0uhtfMrc+mD3NNYW1xbFTzCQ9hUXVe4Wq2BSHAt/qPjyTZjLOtgsEgelXxRywt DE5A== Received: by 10.182.207.39 with SMTP id lt7mr23099978obc.67.1340176574823; Wed, 20 Jun 2012 00:16:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.58.135 with HTTP; Wed, 20 Jun 2012 00:15:54 -0700 (PDT) In-Reply-To: <20120619165504.GA20497@neutralgood.org> References: <20120619131011.GA76729@neutralgood.org> <20120619165504.GA20497@neutralgood.org> From: Rudi Kramer Date: Wed, 20 Jun 2012 09:15:54 +0200 Message-ID: To: kpneal@pobox.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing 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, 20 Jun 2012 07:16:15 -0000 On 19 June 2012 18:55, wrote: > > Try ZFS. You can maximize your storage easily with ZFS if you want. > > With ZFS you can add multiple disks and ZFS will spread the data out > across them. ZFS also keeps track of what file is where. If you lose a > disk then ZFS is supposed to tell you what files you lost, but the > rest of the filesystem should be fine. > > ZFS can do mirroring, and it can do raid, but neither is required. If > you do neither mirroring nor raid then the amount of space you get is > the sum of the sizes of your disks. It sounds like that's what you want. > Thanks Mark, That's pretty much exactly what I was looking for. Cheers Rudi From owner-freebsd-geom@FreeBSD.ORG Wed Jun 20 07:56:44 2012 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 19795106564A for ; Wed, 20 Jun 2012 07:56:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A99A48FC0C for ; Wed, 20 Jun 2012 07:56:43 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5K7uaua034416; Wed, 20 Jun 2012 10:56:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5K7uavb071440; Wed, 20 Jun 2012 10:56:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5K7uaXg071439; Wed, 20 Jun 2012 10:56:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Jun 2012 10:56:36 +0300 From: Konstantin Belousov To: Steven Haber Message-ID: <20120620075635.GT2337@deviant.kiev.zoral.com.ua> References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403429115@seaxch01.desktop.isilon.com> <20120611225304.GK2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403589417@seaxch01.desktop.isilon.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l7itP/1EBO9PCc/O" Content-Disposition: inline In-Reply-To: <56CE86D6660FF84498426FA7A33170B403589417@seaxch01.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: Geom / destroy_dev() deadlock 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, 20 Jun 2012 07:56:44 -0000 --l7itP/1EBO9PCc/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 19, 2012 at 11:24:03AM -0700, Steven Haber wrote: > > On Mon, Jun 11, 2012 at 03:27:39PM -0700, Steven Haber wrote: > > > I do not understand what you are proposing. Could you, please, show > > > > the patch ? > > >=20 > > > --- > > > src/sys/geom/geom_dev.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > >=20 > > > diff --git a/src/sys/geom/geom_dev.c b/src/sys/geom/geom_dev.c > > > index 38251e1..787235a 100644 > > > --- a/src/sys/geom/geom_dev.c > > > +++ b/src/sys/geom/geom_dev.c > > > @@ -497,7 +497,7 @@ g_dev_orphan(struct g_consumer *cp) > > > =20 > > > /* Destroy the struct cdev *so we get no more requests */ > > > unit =3D dev2unit(dev); > > > - destroy_dev(dev); > > > + destroy_dev_sched(dev); > > > free_unr(unithdr, unit); > > > =20 > > > /* Wait for the cows to come home */ > > > > From: Konstantin Belousov > > Sent: Monday, June 11, 2012 3:53 PM > > To: Steven Haber > > Cc: freebsd-geom@freebsd.org > > Subject: Re: Geom / destroy_dev() deadlock > > > > Did you noted the comment above the block you changing ? > > The patch would cause races allowing arbitrary kernel memory > corruption. > > > > The moment when the cdev is destroyed is somewhere in future, while > > structures that the cdev reference are freed synchronously. > > > > I tried to put some safety measures into destroy_dev_sched(9), namely > > CDP_SCHED_DTR flag that somewhat reduces the possibility of usermode > > accessing cdev after destroy_dev_sched(), but this cannot be > eliminated > > entirely. >=20 > So destroy_dev_sched() is inherently racey. That explains why there > aren't many examples of usage in the kernel. It is not. I admit (and did this quite often) that correct use of destroy_dev_sched{,_cb}() is not trivial, but the KPI was designed explicitely to handle otherwise unmanageable deadlocks and races. >=20 > Without doing a scheduled destroy, can you think of any way to prevent > the devdrn/geom deadlock? From the original discussion: >=20 > GEOM calls destroy_dev() while holding the topology lock. >=20 > Destroy_dev() wants to destroy device, but can't because there > are > threads that still have it open. >=20 > The threads can't close it, because to close it they need the > topology > lock. No, destroy_dev_sched (most likely destroy_dev_sched_cb) is the right facility to defer destroy_dev. Usual technique is to set some flag that causes devsw methods to not proceed if CDP_SCHED_DTR protection is not enough for some reason, and do actual cleanup of resources in callback. >=20 > There may be additional locking that can be done in the dev layer, like > a third sleepable lock. We could also set a devdrn flag on the cdev to > cause g_dev calls to return with an error prior to taking the topology > lock. Well, if you can end up with working correct patch, feel free. --l7itP/1EBO9PCc/O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/hgjMACgkQC3+MBN1Mb4i5HQCg5ZDmxRmPFX7bb4oxfhLAX1ua UZ0AniEKVfg9JYe57IED+3w36koMoRJT =VaEY -----END PGP SIGNATURE----- --l7itP/1EBO9PCc/O--