From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 16:26:38 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0370016A4CE
for <freebsd-geom@FreeBSD.org>; Mon, 5 Jul 2004 16:26:38 +0000 (GMT)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8EEE943D39
for <freebsd-geom@FreeBSD.org>; Mon, 5 Jul 2004 16:26:37 +0000 (GMT)
(envelope-from trampith@sdf.lonestar.org)
Received: from sdf.lonestar.org (IDENT:trampith@otaku.freeshell.org
[192.94.73.2])
by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i65GQYEJ028200
for <freebsd-geom@FreeBSD.org>; Mon, 5 Jul 2004 16:26:35 GMT
Received: (from trampith@localhost)
by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i65GQYiF018283;
Mon, 5 Jul 2004 18:26:34 +0200 (CEST)
Date: Mon, 5 Jul 2004 18:26:34 +0200 (CEST)
From: tthorsten@yahoo.de
X-X-Sender: trampith@otaku.freeshell.org
To: freebsd-geom@FreeBSD.org
Message-ID: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 16:26:38 -0000
Hi,
I have a serious problem after I have done the following steps:
Initalized new encrypted disk with
gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c
-> sector_size = 2048
-> one key
Attached it to the kernel via
gbde attach ad1s1c -l /etc/gbde/ad1s1c
Created new filesystem with
newfs -U /dev/ad1s1c.bde
Mounted the filesystem with
mount /dev/ad1s1c.bde /dsk
Then I put all my private data onto the newly created encrypted disk and
unmounted and detached it from kernel before halting the system.
When I started the system again and tried to attach the disk again with
gbde attach ad1s1c -l /etc/gbde/ad1s1c
NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
The Passphrase is correct!
So I made a dd of the first 1MB of /dev/ad1s1c and did a strings on it.
See output at end of this mail.
There are Error MEssages like "Read Boot error", "not a directory", "not ufs format"
etc. I do not have such error messages in the dd output from other encrypted partitions
I use.
What went wrong? Does anybody have an answer or is all my data lost?
I would be very happy, if anybody could help me with this.
Regards,
Thorsten
Here the strings output of the first 1MB of /dev/ad1s1c:
Read
Boot
error
ad1s1
3QPh
QQQQR
D$PP
> td
>0tc
>2tk
t[[a
U0Z)
PSVW1
Y_^[X
f=SOu
PPP`
t$PV
@err
Defl
Peip
Heax
4ebx
(ecx
0edx
,esi
esp
fs
cs:eip
Hss:esp
BTX halted
UWVS
Ph;4
Wh?4
[^_]
UWVS
\$h9
L$Hu
\$@+
9\$pv
9T$4
9D$0
t$(1
;T$,
;D$(t.j
t$(1
D$01
t$@t
;T$,
;D$(t-
+\$8;\$Dv
)\$D
T[^_
/ker
UWVS
[^_]
UWVS
;WEV
[^_]
DhaCgmnPprsv
%s: not a directory.
Not ufs
format
Invalid %s
/boot.config
%s: %s
/boot/loader
FreeBSD/i386 boot
Default: %u:%s(%u,%c)%s
boot:
No %s
Keyboard: %s
slice
label
partition
error %u lba %u
/|\-
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 16:50:31 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B163D16A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 16:50:31 +0000 (GMT)
Received: from afields.ca (afields.ca [216.194.67.132])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6D54843D48
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 16:50:31 +0000 (GMT)
(envelope-from afields@afields.ca)
Received: from afields.ca (localhost.afields.ca [127.0.0.1])
by afields.ca (8.12.11/8.12.11) with ESMTP id i65GoURP074993;
Mon, 5 Jul 2004 12:50:30 -0400 (EDT)
(envelope-from afields@afields.ca)
Received: (from afields@localhost)
by afields.ca (8.12.11/8.12.11/Submit) id i65GoU4b074992;
Mon, 5 Jul 2004 12:50:30 -0400 (EDT)
(envelope-from afields)
Date: Mon, 5 Jul 2004 12:50:30 -0400
From: Allan Fields <bsd@afields.ca>
To: tthorsten@yahoo.de
Message-ID: <20040705165030.GD70272@afields.ca>
References: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV"
Content-Disposition: inline
In-Reply-To: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
User-Agent: Mutt/1.4i
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 16:50:31 -0000
--Y7xTucakfITjPcLV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jul 05, 2004 at 06:26:34PM +0200, tthorsten@yahoo.de wrote:
> Hi,
>=20
> I have a serious problem after I have done the following steps:
>=20
> Initalized new encrypted disk with
> gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c
> -> sector_size =3D 2048
> -> one key
>=20
> Attached it to the kernel via
> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>=20
> Created new filesystem with
> newfs -U /dev/ad1s1c.bde
>=20
> Mounted the filesystem with
> mount /dev/ad1s1c.bde /dsk
>=20
> Then I put all my private data onto the newly created encrypted disk and
> unmounted and detached it from kernel before halting the system.
>=20
> When I started the system again and tried to attach the disk again with
> gbde attach ad1s1c -l /etc/gbde/ad1s1c
> NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
> The Passphrase is correct!
Hmm.. you're volume may be corrupted now, see below..
>=20
> So I made a dd of the first 1MB of /dev/ad1s1c and did a strings on it.
> See output at end of this mail.
> There are Error MEssages like "Read Boot error", "not a directory", "not=
=20
> ufs format"
> etc. I do not have such error messages in the dd output from other=20
> encrypted partitions
> I use.
>=20
> What went wrong? Does anybody have an answer or is all my data lost?
Simple answer: yes, and this is one of the risks with all encrypted
file systems. Probablly quite challenging to get it back absent
backups.
> I would be very happy, if anybody could help me with this.
Is it possible you've written boot code on-top of the encrypted volume?
Those strings look to belong to boot loader.
You probably shouldn't have used the raw partition for the encrypted volume,
next time disklabel the disk and use /dev/ad1s1a . I don't know why you
want boot code on the second disk anyhow.
Just out of curiosity, what is the output of:
fdisk ad1 ?
disklabel ad1s1
> Regards,
> Thorsten
>=20
>=20
> Here the strings output of the first 1MB of /dev/ad1s1c:
> Read
> Boot
> error
> ad1s1
[..]
> Hss:esp
> BTX halted
> UWVS
> Ph;4
> Wh?4
> [^_]
[..]
> DhaCgmnPprsv
> %s: not a directory.
> Not ufs
> format
> Invalid %s
> /boot.config
> %s: %s
> /boot/loader
> FreeBSD/i386 boot
> Default: %u:%s(%u,%c)%s
> boot:
> No %s
> Keyboard: %s
> slice
> label
> partition
> error %u lba %u
> /|\-
--=20
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
--Y7xTucakfITjPcLV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQFA6YbV90UNcjm0VUERAs/aAKCfmLohkUW9REmJUeMWwGs/MP/8RACdFTIC
7p4o1PdNL6kTFwy41QQ2NSg=
=PUCs
-----END PGP SIGNATURE-----
--Y7xTucakfITjPcLV--
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 16:54:42 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 72B9F16A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 16:54:42 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP id B260A43D2F
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 16:54:41 +0000 (GMT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i65Gsddi001034;
Mon, 5 Jul 2004 18:54:39 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: tthorsten@yahoo.de
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Mon, 05 Jul 2004 18:26:34 +0200."
<Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
Date: Mon, 05 Jul 2004 18:54:39 +0200
Message-ID: <1033.1089046479@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 16:54:42 -0000
In message <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>, tthorsten@y
ahoo.de writes:
>When I started the system again and tried to attach the disk again with
> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
>The Passphrase is correct!
Despite your claim here, my money is on your pass-phrase being different
from what you type.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 17:32:01 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id ABFBE16A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 17:32:01 +0000 (GMT)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by mx1.FreeBSD.org (Postfix) with ESMTP id 17CA043D1F
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 17:32:01 +0000 (GMT)
(envelope-from trampith@sdf.lonestar.org)
Received: from sdf.lonestar.org (IDENT:trampith@otaku.freeshell.org
[192.94.73.2])
by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i65HVtuk012226;
Mon, 5 Jul 2004 17:31:55 GMT
Received: (from trampith@localhost)
by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i65HVtjt025151;
Mon, 5 Jul 2004 19:31:55 +0200 (CEST)
Date: Mon, 5 Jul 2004 19:31:55 +0200 (CEST)
From: tthorsten@yahoo.de
X-X-Sender: trampith@otaku.freeshell.org
To: Allan Fields <bsd@afields.ca>
In-Reply-To: <20040705165030.GD70272@afields.ca>
Message-ID: <Pine.NEB.4.60.0407051925140.18543@otaku.freeshell.org>
References: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
<20040705165030.GD70272@afields.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 17:32:01 -0000
> Date: Mon, 5 Jul 2004 12:50:30 -0400
> From: Allan Fields <bsd@afields.ca>
> To: tthorsten@yahoo.de
> Cc: freebsd-geom@freebsd.org
> Subject: Re: Problem in attaching newly encrypted disk
>
> On Mon, Jul 05, 2004 at 06:26:34PM +0200, tthorsten@yahoo.de wrote:
>> Hi,
>>
>> I have a serious problem after I have done the following steps:
>>
>> Initalized new encrypted disk with
>> gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c
>> -> sector_size = 2048
>> -> one key
>>
>> Attached it to the kernel via
>> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>>
>> Created new filesystem with
>> newfs -U /dev/ad1s1c.bde
>>
>> Mounted the filesystem with
>> mount /dev/ad1s1c.bde /dsk
>>
>> Then I put all my private data onto the newly created encrypted disk and
>> unmounted and detached it from kernel before halting the system.
>>
>> When I started the system again and tried to attach the disk again with
>> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>> NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
>> The Passphrase is correct!
>
> Hmm.. you're volume may be corrupted now, see below..
>
>>
>> So I made a dd of the first 1MB of /dev/ad1s1c and did a strings on it.
>> See output at end of this mail.
>> There are Error MEssages like "Read Boot error", "not a directory", "not
>> ufs format"
>> etc. I do not have such error messages in the dd output from other
>> encrypted partitions
>> I use.
>>
>> What went wrong? Does anybody have an answer or is all my data lost?
>
> Simple answer: yes, and this is one of the risks with all encrypted
> file systems. Probablly quite challenging to get it back absent
> backups.
>
>> I would be very happy, if anybody could help me with this.
>
> Is it possible you've written boot code on-top of the encrypted volume?
> Those strings look to belong to boot loader.
>
> You probably shouldn't have used the raw partition for the encrypted volume,
> next time disklabel the disk and use /dev/ad1s1a . I don't know why you
> want boot code on the second disk anyhow.
>
> Just out of curiosity, what is the output of:
>
> fdisk ad1 ?
>
> disklabel ad1s1
>
Hmm, seems really to be boot loader code. But I did not use fdisk or disklabel
after creation of the encrypted disk.
Did not know that its better to not use the raw partition :-(
Ok, thanks and here is the output of fdisk and disklabel:
root@freebsd52:/root # fdisk ad1
******* Working on device /dev/ad1 *******
parameters extracted from in-core disklabel are:
cylinders=166440 heads=16 sectors/track=63 (1008 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=166440 heads=16 sectors/track=63 (1008 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 167766732 (81917 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
root@freebsd52:/root # disklabel ad1s1
# /dev/ad1s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 167766732 0 unused 0 0 # "raw" part, don't edit
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 19:26:19 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AB69E16A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 19:26:19 +0000 (GMT)
Received: from afields.ca (afields.ca [216.194.67.132])
by mx1.FreeBSD.org (Postfix) with ESMTP id 64D3D43D46
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 19:26:19 +0000 (GMT)
(envelope-from afields@afields.ca)
Received: from afields.ca (localhost.afields.ca [127.0.0.1])
by afields.ca (8.12.11/8.12.11) with ESMTP id i65JQImv075542;
Mon, 5 Jul 2004 15:26:18 -0400 (EDT)
(envelope-from afields@afields.ca)
Received: (from afields@localhost)
by afields.ca (8.12.11/8.12.11/Submit) id i65JQIH0075541;
Mon, 5 Jul 2004 15:26:18 -0400 (EDT)
(envelope-from afields)
Date: Mon, 5 Jul 2004 15:26:18 -0400
From: Allan Fields <bsd@afields.ca>
To: tthorsten@yahoo.de
Message-ID: <20040705192618.GB74224@afields.ca>
References: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
<20040705165030.GD70272@afields.ca>
<Pine.NEB.4.60.0407051925140.18543@otaku.freeshell.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.NEB.4.60.0407051925140.18543@otaku.freeshell.org>
User-Agent: Mutt/1.4i
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 19:26:20 -0000
On Mon, Jul 05, 2004 at 07:31:55PM +0200, tthorsten@yahoo.de wrote:
> >Date: Mon, 5 Jul 2004 12:50:30 -0400
> >From: Allan Fields <bsd@afields.ca>
> >To: tthorsten@yahoo.de
> >Cc: freebsd-geom@freebsd.org
> >Subject: Re: Problem in attaching newly encrypted disk
> >
> >On Mon, Jul 05, 2004 at 06:26:34PM +0200, tthorsten@yahoo.de wrote:
> >>Hi,
> >>
> >>I have a serious problem after I have done the following steps:
> >>
> >>Initialized new encrypted disk with
> >> gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c
> >> -> sector_size = 2048
> >> -> one key
> >>
> >>Attached it to the kernel via
> >> gbde attach ad1s1c -l /etc/gbde/ad1s1c
> >>
> >>Created new filesystem with
> >> newfs -U /dev/ad1s1c.bde
> >>
> >>Mounted the filesystem with
> >> mount /dev/ad1s1c.bde /dsk
> >>
> >>Then I put all my private data onto the newly created encrypted disk and
> >>unmounted and detached it from kernel before halting the system.
> >>
> >>When I started the system again and tried to attach the disk again with
> >> gbde attach ad1s1c -l /etc/gbde/ad1s1c
> >>NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
> >>The Passphrase is correct!
> >
> >Hmm.. you're volume may be corrupted now, see below..
Before you assume so, maybe think about the password for a while.
Sometimes we can change passwords slightly depending on what hour
they were entered.
You can't totally rule it out that you just didn't remember / type
correctly.
Closer examination of the usr.sbin/gbde code and some debugging could
narrow down where you are running out of luck during attach.
> >>What went wrong? Does anybody have an answer or is all my data lost?
> >
> >Simple answer: yes, and this is one of the risks with all encrypted
> >file systems. Probablly quite challenging to get it back absent
> >backups.
> >>I would be very happy, if anybody could help me with this.
> >
> >Is it possible you've written boot code on-top of the encrypted volume?
> >Those strings look to belong to boot loader.
> >
> >You probably shouldn't have used the raw partition for the encrypted
> >volume,
> >next time disklabel the disk and use /dev/ad1s1a . I don't know why you
> >want boot code on the second disk anyhow.
> >
> Hmm, seems really to be boot loader code. But I did not use fdisk or
> disklabel
> after creation of the encrypted disk.
Maybe it isn't overwritten then and you just have boot code left-over
from when you originally labeled the disk.. unless something could
have over-writen, it's hard to think of other likely scenarios.
> Did not know that its better to not use the raw partition :-(
Well, I guess it doesn't matter unless something assumes that it
can write over the first sectors containing your data.
The good news is you still have your lock selector file (-L/-l).
PHK: wouldn't the BDE class / GEOM prevent boot code from being
written to the underlying partition (provider) if it were attached
at the time?
--
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 19:29:10 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C395216A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 19:29:10 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP id EC2CC43D2D
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 19:29:09 +0000 (GMT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i65JT7O3003706;
Mon, 5 Jul 2004 21:29:07 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Allan Fields <bsd@afields.ca>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Mon, 05 Jul 2004 15:26:18 EDT."
<20040705192618.GB74224@afields.ca>
Date: Mon, 05 Jul 2004 21:29:07 +0200
Message-ID: <3705.1089055747@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: tthorsten@yahoo.de
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 19:29:10 -0000
In message <20040705192618.GB74224@afields.ca>, Allan Fields writes:
>> Did not know that its better to not use the raw partition :-(
>
>Well, I guess it doesn't matter unless something assumes that it
>can write over the first sectors containing your data.
>
>The good news is you still have your lock selector file (-L/-l).
>
>
>PHK: wouldn't the BDE class / GEOM prevent boot code from being
>written to the underlying partition (provider) if it were attached
>at the time?
yes, it would not be able to over write it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 20:21:43 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 683D016A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 20:21:43 +0000 (GMT)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by mx1.FreeBSD.org (Postfix) with ESMTP id C258F43D1F
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 20:21:42 +0000 (GMT)
(envelope-from trampith@sdf.lonestar.org)
Received: from sdf.lonestar.org (IDENT:trampith@otaku.freeshell.org
[192.94.73.2])
by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i65KLYA8009982;
Mon, 5 Jul 2004 20:21:34 GMT
Received: (from trampith@localhost)
by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i65KLWtN025594;
Mon, 5 Jul 2004 22:21:32 +0200 (CEST)
Date: Mon, 5 Jul 2004 22:21:32 +0200 (CEST)
From: tthorsten@yahoo.de
X-X-Sender: trampith@otaku.freeshell.org
To: Allan Fields <bsd@afields.ca>
In-Reply-To: <20040705192618.GB74224@afields.ca>
Message-ID: <Pine.NEB.4.60.0407052213370.18484@otaku.freeshell.org>
References: <Pine.NEB.4.60.0407051813340.29828@otaku.freeshell.org>
<Pine.NEB.4.60.0407051925140.18543@otaku.freeshell.org>
<20040705192618.GB74224@afields.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 20:21:43 -0000
On Mon, 5 Jul 2004, Allan Fields wrote:
> Date: Mon, 5 Jul 2004 15:26:18 -0400
> From: Allan Fields <bsd@afields.ca>
> To: tthorsten@yahoo.de
> Cc: freebsd-geom@freebsd.org
> Subject: Re: Problem in attaching newly encrypted disk
>
> On Mon, Jul 05, 2004 at 07:31:55PM +0200, tthorsten@yahoo.de wrote:
>>> Date: Mon, 5 Jul 2004 12:50:30 -0400
>>> From: Allan Fields <bsd@afields.ca>
>>> To: tthorsten@yahoo.de
>>> Cc: freebsd-geom@freebsd.org
>>> Subject: Re: Problem in attaching newly encrypted disk
>>>
>>> On Mon, Jul 05, 2004 at 06:26:34PM +0200, tthorsten@yahoo.de wrote:
>>>> Hi,
>>>>
>>>> I have a serious problem after I have done the following steps:
>>>>
>>>> Initialized new encrypted disk with
>>>> gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c
>>>> -> sector_size = 2048
>>>> -> one key
>>>>
>>>> Attached it to the kernel via
>>>> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>>>>
>>>> Created new filesystem with
>>>> newfs -U /dev/ad1s1c.bde
>>>>
>>>> Mounted the filesystem with
>>>> mount /dev/ad1s1c.bde /dsk
>>>>
>>>> Then I put all my private data onto the newly created encrypted disk and
>>>> unmounted and detached it from kernel before halting the system.
>>>>
>>>> When I started the system again and tried to attach the disk again with
>>>> gbde attach ad1s1c -l /etc/gbde/ad1s1c
>>>> NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount.
>>>> The Passphrase is correct!
>>>
>>> Hmm.. you're volume may be corrupted now, see below..
>
> Before you assume so, maybe think about the password for a while.
> Sometimes we can change passwords slightly depending on what hour
> they were entered.
>
> You can't totally rule it out that you just didn't remember / type
> correctly.
>
I first tried that. I created a list with now 146 entries and put it
through gbde via the -p option. No success. I'm quite sure, that I
typed it in correctly. I use the same one on my laptop and I typed
it two times when initializing the disk.
>
> Closer examination of the usr.sbin/gbde code and some debugging could
> narrow down where you are running out of luck during attach.
Ok, sounds logical for me, but how to debug the process of attach the disk
with gbde? Manpages don't show a switch for debugging and in /var/log
there are no entries.
>
>
>>>> What went wrong? Does anybody have an answer or is all my data lost?
>>>
>>> Simple answer: yes, and this is one of the risks with all encrypted
>>> file systems. Probablly quite challenging to get it back absent
>>> backups.
>
>
>>>> I would be very happy, if anybody could help me with this.
>>>
>>> Is it possible you've written boot code on-top of the encrypted volume?
>>> Those strings look to belong to boot loader.
>>>
>>> You probably shouldn't have used the raw partition for the encrypted
>>> volume,
>>> next time disklabel the disk and use /dev/ad1s1a . I don't know why you
>>> want boot code on the second disk anyhow.
>>>
>> Hmm, seems really to be boot loader code. But I did not use fdisk or
>> disklabel
>> after creation of the encrypted disk.
>
> Maybe it isn't overwritten then and you just have boot code left-over
> from when you originally labeled the disk.. unless something could
> have over-writen, it's hard to think of other likely scenarios.
>
>
>> Did not know that its better to not use the raw partition :-(
>
> Well, I guess it doesn't matter unless something assumes that it
> can write over the first sectors containing your data.
>
> The good news is you still have your lock selector file (-L/-l).
What can I do with it? Is it possible to rescue the data when I
have the lock selector file?
Thanks a lot for your support.
Regards,
Thorsten
From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 20:24:28 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 53A1616A4CE
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 20:24:28 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9E7E343D48
for <freebsd-geom@freebsd.org>; Mon, 5 Jul 2004 20:24:27 +0000 (GMT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i65KOOBg004614;
Mon, 5 Jul 2004 22:24:24 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: tthorsten@yahoo.de
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Mon, 05 Jul 2004 22:21:32 +0200."
<Pine.NEB.4.60.0407052213370.18484@otaku.freeshell.org>
Date: Mon, 05 Jul 2004 22:24:24 +0200
Message-ID: <4613.1089059064@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: Allan Fields <bsd@afields.ca>
cc: freebsd-geom@freebsd.org
Subject: Re: Problem in attaching newly encrypted disk
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2004 20:24:28 -0000
In message <Pine.NEB.4.60.0407052213370.18484@otaku.freeshell.org>, tthorsten@y
ahoo.de writes:
>> The good news is you still have your lock selector file (-L/-l).
>
>
>What can I do with it? Is it possible to rescue the data when I
>have the lock selector file?
It doesn't really help you I'm afraid.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From owner-freebsd-geom@FreeBSD.ORG Tue Jul 6 11:32:44 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 47F4816A4CE
for <geom@freebsd.org>; Tue, 6 Jul 2004 11:32:44 +0000 (GMT)
Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id EC3C843D2D
for <geom@freebsd.org>; Tue, 6 Jul 2004 11:32:43 +0000 (GMT)
(envelope-from pjd@darkness.comp.waw.pl)
Received: by darkness.comp.waw.pl (Postfix, from userid 1009)
id BFBD6ACAEE; Tue, 6 Jul 2004 13:32:42 +0200 (CEST)
Date: Tue, 6 Jul 2004 13:32:42 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: geom@freebsd.org
Message-ID: <20040706113242.GK12007@darkness.comp.waw.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="T0VxxuQkR4DcuMht"
Content-Disposition: inline
User-Agent: Mutt/1.4.2i
X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc
X-OS: FreeBSD 5.2.1-RC2 i386
Subject: GEOM and retaste.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2004 11:32:44 -0000
--T0VxxuQkR4DcuMht
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi.
I'm still fighting with 'stop' command for geom_mirror class.
It should works, just like in my other class: turn off the given
geom/provider/device.
But for geom_mirror, I need to open all disks with r1w1e1 perms,
so when I call 'stop' command and I close those disks, they are
retasted and mirror is created once again.
I don't want to touch metadata to mark all disks as inactve, because
after kld module is unloaded and loaded again I want this mirror
to be setup automatically.
Any ideas?
I don't want to introduce any hacks to do it, for example I can create
a list of disks which I'm planing to close and on retaste ignore them
and remove from the list (but probably there could be a race, because
retaste event may be canceled, so there will be a memory leak).
I proposed to not send retaste event to class which made the last close
for provider, but phk disagree with it. So maybe we can do something
in the middle? We can pass a flag for retaste which will tell me, that
I was the one who made the last close?
--=20
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd@FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
--T0VxxuQkR4DcuMht
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA6o3aForvXbEpPzQRAnB8AKCcljc7eIUuFNb5c1QC07yWbhZc1wCdE7hu
uN5idtMHSodH8D4Q+0onWX0=
=YLTJ
-----END PGP SIGNATURE-----
--T0VxxuQkR4DcuMht--
From owner-freebsd-geom@FreeBSD.ORG Tue Jul 6 17:55:56 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5BE3A16A4CE
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 17:55:56 +0000 (GMT)
Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2E8E543D2D
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 17:55:56 +0000 (GMT)
(envelope-from jmg@hydrogen.funkthat.com)
Received: (qmail 21572 invoked from network); 6 Jul 2004 17:55:55 -0000
Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168])
(envelope-sender <jmg@hydrogen.funkthat.com>)
by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
for <pjd@FreeBSD.org>; 6 Jul 2004 17:55:55 -0000
Received: from hydrogen.funkthat.com (pqbqjy@localhost.funkthat.com
[127.0.0.1])i66HttHX014843; Tue, 6 Jul 2004 10:55:55 -0700 (PDT)
(envelope-from jmg@hydrogen.funkthat.com)
Received: (from jmg@localhost)
by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i66HttsR014841;
Tue, 6 Jul 2004 10:55:55 -0700 (PDT)
Date: Tue, 6 Jul 2004 10:55:54 -0700
From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Message-ID: <20040706175554.GP57659@funkthat.com>
References: <20040706113242.GK12007@darkness.comp.waw.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040706113242.GK12007@darkness.comp.waw.pl>
User-Agent: Mutt/1.4.1i
X-Operating-System: FreeBSD 4.2-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html
cc: geom@FreeBSD.org
Subject: Re: GEOM and retaste.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2004 17:55:56 -0000
Pawel Jakub Dawidek wrote this message on Tue, Jul 06, 2004 at 13:32 +0200:
> I'm still fighting with 'stop' command for geom_mirror class.
> It should works, just like in my other class: turn off the given
> geom/provider/device.
> But for geom_mirror, I need to open all disks with r1w1e1 perms,
> so when I call 'stop' command and I close those disks, they are
> retasted and mirror is created once again.
> I don't want to touch metadata to mark all disks as inactve, because
> after kld module is unloaded and loaded again I want this mirror
> to be setup automatically.
>
> Any ideas?
Add state to the geom_mirror class to know what mirrors are disabled...
then when they appear, you just ignore them... and make sure the
memory used by the state table is destroyed upon unload... and then
reload, they'll be back...
I can't think of any other way since geom itself doesn't know enough
information about the class to prevent you from tasting the devices
(and possibly coming up with only part of the mirror)...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
From owner-freebsd-geom@FreeBSD.ORG Tue Jul 6 18:13:27 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 1358016A4CE
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 18:13:27 +0000 (GMT)
Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id B184243D55
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 18:13:26 +0000 (GMT)
(envelope-from pjd@darkness.comp.waw.pl)
Received: by darkness.comp.waw.pl (Postfix, from userid 1009)
id 13914ACAEE; Tue, 6 Jul 2004 20:13:25 +0200 (CEST)
Date: Tue, 6 Jul 2004 20:13:25 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Message-ID: <20040706181325.GM12007@darkness.comp.waw.pl>
References: <20040706113242.GK12007@darkness.comp.waw.pl>
<20040706175554.GP57659@funkthat.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="IkUYAkBqujFk6FKo"
Content-Disposition: inline
In-Reply-To: <20040706175554.GP57659@funkthat.com>
User-Agent: Mutt/1.4.2i
X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc
X-OS: FreeBSD 5.2.1-RC2 i386
cc: geom@FreeBSD.org
Subject: Re: GEOM and retaste.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2004 18:13:27 -0000
--IkUYAkBqujFk6FKo
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 06, 2004 at 10:55:54AM -0700, John-Mark Gurney wrote:
+> Pawel Jakub Dawidek wrote this message on Tue, Jul 06, 2004 at 13:32 +02=
00:
+> > I'm still fighting with 'stop' command for geom_mirror class.
+> > It should works, just like in my other class: turn off the given
+> > geom/provider/device.
+> > But for geom_mirror, I need to open all disks with r1w1e1 perms,
+> > so when I call 'stop' command and I close those disks, they are
+> > retasted and mirror is created once again.
+> > I don't want to touch metadata to mark all disks as inactve, because
+> > after kld module is unloaded and loaded again I want this mirror
+> > to be setup automatically.
+> >=20
+> > Any ideas?
+>=20
+> Add state to the geom_mirror class to know what mirrors are disabled...
+> then when they appear, you just ignore them... and make sure the
+> memory used by the state table is destroyed upon unload... and then
+> reload, they'll be back...
Imagine that box have few years of uptime and there were many mirrors
enabled/disabled...
+> I can't think of any other way since geom itself doesn't know enough
+> information about the class to prevent you from tasting the devices
+> (and possibly coming up with only part of the mirror)...
But it does know that I was the one who made the last close of provider
(then retaste event is send) and it could pass some flag to taste
function to tell me about it.
--=20
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd@FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
--IkUYAkBqujFk6FKo
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA6uvFForvXbEpPzQRAuktAJ9/4gQwlisb1VCSp8+cbQeDxyiMywCcDVZK
MDWcV0UekvuT1Doqzhx+MB4=
=9obG
-----END PGP SIGNATURE-----
--IkUYAkBqujFk6FKo--
From owner-freebsd-geom@FreeBSD.ORG Tue Jul 6 18:48:11 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 3E81E16A4CF
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 18:48:11 +0000 (GMT)
Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1F0C143D5C
for <geom@FreeBSD.org>; Tue, 6 Jul 2004 18:48:11 +0000 (GMT)
(envelope-from jmg@hydrogen.funkthat.com)
Received: (qmail 29065 invoked from network); 6 Jul 2004 18:48:10 -0000
Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168])
(envelope-sender <jmg@hydrogen.funkthat.com>)
by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP
for <pjd@FreeBSD.org>; 6 Jul 2004 18:48:10 -0000
Received: from hydrogen.funkthat.com (wxklmr@localhost.funkthat.com
[127.0.0.1])i66ImAHX015640; Tue, 6 Jul 2004 11:48:10 -0700 (PDT)
(envelope-from jmg@hydrogen.funkthat.com)
Received: (from jmg@localhost)
by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i66ImA52015639;
Tue, 6 Jul 2004 11:48:10 -0700 (PDT)
Date: Tue, 6 Jul 2004 11:48:10 -0700
From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Message-ID: <20040706184810.GQ57659@funkthat.com>
References: <20040706113242.GK12007@darkness.comp.waw.pl>
<20040706175554.GP57659@funkthat.com>
<20040706181325.GM12007@darkness.comp.waw.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040706181325.GM12007@darkness.comp.waw.pl>
User-Agent: Mutt/1.4.1i
X-Operating-System: FreeBSD 4.2-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html
cc: geom@FreeBSD.org
Subject: Re: GEOM and retaste.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2004 18:48:11 -0000
Pawel Jakub Dawidek wrote this message on Tue, Jul 06, 2004 at 20:13 +0200:
> On Tue, Jul 06, 2004 at 10:55:54AM -0700, John-Mark Gurney wrote:
> +> Pawel Jakub Dawidek wrote this message on Tue, Jul 06, 2004 at 13:32 +0200:
> +> > I'm still fighting with 'stop' command for geom_mirror class.
> +> > It should works, just like in my other class: turn off the given
> +> > geom/provider/device.
> +> > But for geom_mirror, I need to open all disks with r1w1e1 perms,
> +> > so when I call 'stop' command and I close those disks, they are
> +> > retasted and mirror is created once again.
> +> > I don't want to touch metadata to mark all disks as inactve, because
> +> > after kld module is unloaded and loaded again I want this mirror
> +> > to be setup automatically.
> +> >
> +> > Any ideas?
> +>
> +> Add state to the geom_mirror class to know what mirrors are disabled...
> +> then when they appear, you just ignore them... and make sure the
> +> memory used by the state table is destroyed upon unload... and then
> +> reload, they'll be back...
>
> Imagine that box have few years of uptime and there were many mirrors
> enabled/disabled...
Well, when you enable a mirror, you just delete the entry... and I
can't imagine a box that you attached 100's of mirrors to it... You
could time out entries, but that would be against POLA...
> +> I can't think of any other way since geom itself doesn't know enough
> +> information about the class to prevent you from tasting the devices
> +> (and possibly coming up with only part of the mirror)...
>
> But it does know that I was the one who made the last close of provider
> (then retaste event is send) and it could pass some flag to taste
> function to tell me about it.
And it could be argued, that even if someone else opened and closed it,
you still want it disabled if you support that... and then you wouldn't
get said flag the second time around....
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
From owner-freebsd-geom@FreeBSD.ORG Tue Jul 6 19:49:00 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 0D44916A4CE; Tue, 6 Jul 2004 19:49:00 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 570EB43D39; Tue, 6 Jul 2004 19:48:59 +0000 (GMT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i66JmvZC020838;
Tue, 6 Jul 2004 21:48:57 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Tue, 06 Jul 2004 20:37:27 +0200."
<20040706183727.GN12007@darkness.comp.waw.pl>
Date: Tue, 06 Jul 2004 21:48:57 +0200
Message-ID: <20837.1089143337@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: geom@FreeBSD.org
cc: Scott Long <scottl@FreeBSD.org>
Subject: Re: Design and implementation of GEOM_MIRROR:)
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2004 19:49:00 -0000
In message <20040706183727.GN12007@darkness.comp.waw.pl>, Pawel Jakub Dawidek w
rites:
>
>--GiGP7OV2v0ywwcSZ
>Content-Type: text/plain; charset=iso-8859-2
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Tue, Jul 06, 2004 at 10:46:10AM -0600, Scott Long wrote:
>+> This sounds reasonable. Don't forget that you might want to deal with
>+> both global spares and spares that are dedicated to a certain array.
>
>Ok, I implement GEOM_SPARE class already. It works as follow:
OK, I made a cup of tea and thought about what I have learned about
hot spares over the years: What you propose here would have had
me cursing your name in many late night and morning hours over the
years. It is not the way we will do it.
Lets get some thoughts down about how we want hot sparing to work
before we rush in with an implementation. Here is my analysis:
First, there are two kinds of hot sparing: dedicated and pooled.
Dedicated hot sparing is when an array has an extra disk member
which is dedicated as a hot spare and nobody else can use it. This
is what you use to have when you have very strict rules for which
bits are the most important etc.
Any policy can be implemented with dedicated hot spares, but at a
cost in disk-space.
It is straightforward to implement and I think that it would be
fair to require all of our array classes to support it.
Pooled hot spares on the other hand are tricky to get right:
1. I want us to have a prioritization of the arrays, so that the
administrator gets to control what gets hot spared in a major
loosage. This also means that we should not assign hot spares
right away, but (at least) have a (configurable) waiting period
during which higher-priority arrays get to pull rank. Ideally
higher ranks should be able to reposses already assigned hot
spares, as long as this doesn't make the previous owner go critical.
2. I want the arrays to have a say in which hot spare they get.
Selecting the wrong hot spare (automagically) can be much worse
than running without a hot spare. Putting two strips on the
same physical disk is a catastrophy for instance.
3. We need some way to partition hot spares. If I dedicate an
entire 72G disk as hot spare and an array need only 10G of
hot spare, the remaining 62G should be available for other
hot sparing uses.
Considering the complexity of this, I am pretty sure that pooled
spares do not belong in the kernel. It would be much better handled
by a userland process where the user could configure (using a
scripting language ?) how hot sparing decisions are to be made.
To do it in userland, would require standardization of the g_ctl()
messages to the arrays and a way for the arrays to signal to the
userland process that they are in distress. The former is merely
a matter of discipline, the latter we can use the XML output for.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From owner-freebsd-geom@FreeBSD.ORG Wed Jul 7 00:57:20 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 72A6C16A4CE; Wed, 7 Jul 2004 00:57:20 +0000 (GMT)
Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 14B2643D53; Wed, 7 Jul 2004 00:57:20 +0000 (GMT)
(envelope-from pjd@darkness.comp.waw.pl)
Received: by darkness.comp.waw.pl (Postfix, from userid 1009)
id 7B499ACAF1; Wed, 7 Jul 2004 02:57:18 +0200 (CEST)
Date: Wed, 7 Jul 2004 02:57:18 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Message-ID: <20040707005718.GO12007@darkness.comp.waw.pl>
References: <20040706183727.GN12007@darkness.comp.waw.pl>
<20837.1089143337@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="wMeKMKLo7/XXP2hN"
Content-Disposition: inline
In-Reply-To: <20837.1089143337@critter.freebsd.dk>
User-Agent: Mutt/1.4.2i
X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc
X-OS: FreeBSD 5.2.1-RC2 i386
cc: geom@FreeBSD.org
cc: Scott Long <scottl@FreeBSD.org>
Subject: Re: Design and implementation of GEOM_MIRROR:)
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2004 00:57:20 -0000
--wMeKMKLo7/XXP2hN
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 06, 2004 at 09:48:57PM +0200, Poul-Henning Kamp wrote:
+> Dedicated hot sparing is when an array has an extra disk member
+> which is dedicated as a hot spare and nobody else can use it. This
+> is what you use to have when you have very strict rules for which
+> bits are the most important etc.
+>=20
+> Any policy can be implemented with dedicated hot spares, but at a
+> cost in disk-space.
+>=20
+> It is straightforward to implement and I think that it would be
+> fair to require all of our array classes to support it.
But it still will be good to have generalized API to do it and
we can also support dedication to more than one array.
For example I've disks da0, da1, da2, da3, I run mirror on da0+da1
and da2+da3 and I stripe da0+da1 with da2+da3. I've also da4 which
I want to use as a spare disk for da0+da1 mirror _or_ da2+da3
mirror, but not for other mirrors in the system.
+> 3. We need some way to partition hot spares. If I dedicate an
+> entire 72G disk as hot spare and an array need only 10G of
+> hot spare, the remaining 62G should be available for other
+> hot sparing uses.
I thought about this and I have to disagree. It'll be just too complex.
Imagine a situation when we need those 10G for mirror1, so first 10G
is reserved for it, then we need 40G for mirror2, so we give it,
then another 10G is requested by mirror3, ok go ahead and then mirror2
doesn't need his spare any more, so we have a hole in our spare
provider. What should we do if someone requests for 50G?
(And I don't think, that concatenating all fragments is a good way to go.)
So, in my opinion, administrator should be just aware of this and prepare
providers which can be needed.
+> Considering the complexity of this, I am pretty sure that pooled
+> spares do not belong in the kernel. It would be much better handled
+> by a userland process where the user could configure (using a
+> scripting language ?) how hot sparing decisions are to be made.
+>=20
+> To do it in userland, would require standardization of the g_ctl()
+> messages to the arrays and a way for the arrays to signal to the
+> userland process that they are in distress. The former is merely
+> a matter of discipline, the latter we can use the XML output for.
I'm not sure about this...
--=20
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd@FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
--wMeKMKLo7/XXP2hN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA60puForvXbEpPzQRAtneAJ9GpluNRi4aLa3o2Wi4/N2wo1hd/QCggFou
9QlAq3TJ6NOpMhA3pPLAuhw=
=hsPC
-----END PGP SIGNATURE-----
--wMeKMKLo7/XXP2hN--
From owner-freebsd-geom@FreeBSD.ORG Wed Jul 7 01:29:06 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 25B9516A4CE
for <geom@freebsd.org>; Wed, 7 Jul 2004 01:29:06 +0000 (GMT)
Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id A952143D46
for <geom@freebsd.org>; Wed, 7 Jul 2004 01:29:05 +0000 (GMT)
(envelope-from pjd@darkness.comp.waw.pl)
Received: by darkness.comp.waw.pl (Postfix, from userid 1009)
id 871FAACAF1; Wed, 7 Jul 2004 03:29:04 +0200 (CEST)
Date: Wed, 7 Jul 2004 03:29:04 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: geom@freebsd.org
Message-ID: <20040707012904.GP12007@darkness.comp.waw.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="rElBCCUBH2Mj3Q5T"
Content-Disposition: inline
User-Agent: Mutt/1.4.2i
X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc
X-OS: FreeBSD 5.2.1-RC2 i386
Subject: Current GEOM problems.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2004 01:29:06 -0000
--rElBCCUBH2Mj3Q5T
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi.
Because those bugs prevent me from moving forward, I'm sending again
problems that currently exists in GEOM.
1. Wrong KASSERT()s in geom_subr.c:
KASSERT(dcr <=3D 0, ("spoiled but dcr =3D %d", dcr));
KASSERT(dcw <=3D 0, ("spoiled but dcw =3D %d", dcw));
KASSERT(dce <=3D 0, ("spoiled but dce =3D %d", dce));
Let's see why: We have two provider: md0 and md0.nop. Consumer related
to md0.nop is connected to md0. Now if new class is loaded GEOM gives
md0 for taste first. Let's say that md0 is what we were looking for,
so we open it for writing (it is marked as beeing spoiled). Now GEOM
gives md0.nop for taste, I open md0.nop for reading and NOP class opens
md0 for reading and panic, because all consumers connected to md0 were
marked as beeing spoiled.
So we could use:
http://people.freebsd.org/~pjd/patches/geom_subr.c.17.patch
Or we can jusr replace those KASSERT()s with:
if (dcr > 0 || dcw > 0 || dce > 0)
return (EPERM);
2. Every class which use geom_slice cannot be unload when it has geoms
(actually providers), because g_slice_destroy_geom() calls
g_slice_spoiled() and g_slice_spoiled() calls g_wither_geom().
If there are providers, geom will not be imediately destroyed,
but orphan event will be send, so next time when g_slice_destroy_geom()
will be called for the same geom it will panic, because gp->softc is
NULL.
3. Problem which I reported not long ago: once_is_enough should be
replaced.
When those bugs are going to be fixed? How can I help?
--=20
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd@FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
--rElBCCUBH2Mj3Q5T
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA61HgForvXbEpPzQRAl3RAKCE31CEb7UQ75hB9yK+8t5KMJE9swCg80BB
XstSJVAN8nk1V3Nc7X//S0c=
=7z6N
-----END PGP SIGNATURE-----
--rElBCCUBH2Mj3Q5T--
From owner-freebsd-geom@FreeBSD.ORG Thu Jul 8 17:15:45 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 2A9E716A52C; Thu, 8 Jul 2004 17:15:45 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 562AF43D64; Thu, 8 Jul 2004 17:15:44 +0000 (GMT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i68HFhao003839;
Thu, 8 Jul 2004 19:15:43 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Pawel Jakub Dawidek <pjd@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Wed, 07 Jul 2004 03:29:04 +0200."
<20040707012904.GP12007@darkness.comp.waw.pl>
Date: Thu, 08 Jul 2004 19:15:43 +0200
Message-ID: <3838.1089306943@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: geom@freebsd.org
Subject: Re: Current GEOM problems.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2004 17:15:45 -0000
In message <20040707012904.GP12007@darkness.comp.waw.pl>, Pawel Jakub Dawidek w
rites:
>2. Every class which use geom_slice cannot be unload when it has geoms
> (actually providers), because g_slice_destroy_geom() calls
> g_slice_spoiled() and g_slice_spoiled() calls g_wither_geom().
> If there are providers, geom will not be imediately destroyed,
> but orphan event will be send, so next time when g_slice_destroy_geom()
> will be called for the same geom it will panic, because gp->softc is
> NULL.
can you try this untested patch ?
Index: geom_slice.c
===================================================================
RCS file: /home/ncvs/src/sys/geom/geom_slice.c,v
retrieving revision 1.54
diff -u -r1.54 geom_slice.c
--- geom_slice.c 4 Jul 2004 13:44:48 -0000 1.54
+++ geom_slice.c 8 Jul 2004 17:15:12 -0000
@@ -439,8 +439,13 @@
int
g_slice_destroy_geom(struct gctl_req *req, struct g_class *mp, struct g_geom *gp)
{
+ struct g_slicer *gsp;
- g_slice_spoiled(LIST_FIRST(&gp->consumer));
+ g_topology_assert();
+ gsp = gp->softc;
+ gp->softc = NULL;
+ g_slice_free(gsp);
+ g_wither_geom(gp, ENXIO);
return (0);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From owner-freebsd-geom@FreeBSD.ORG Thu Jul 8 18:19:11 2004
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 543BC16A4CE
for <geom@freebsd.org>; Thu, 8 Jul 2004 18:19:11 +0000 (GMT)
Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id 005EE43D1D
for <geom@freebsd.org>; Thu, 8 Jul 2004 18:19:11 +0000 (GMT)
(envelope-from pjd@darkness.comp.waw.pl)
Received: by darkness.comp.waw.pl (Postfix, from userid 1009)
id 63F42ACAE3; Thu, 8 Jul 2004 20:19:09 +0200 (CEST)
Date: Thu, 8 Jul 2004 20:19:09 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Message-ID: <20040708181909.GT12007@darkness.comp.waw.pl>
References: <20040707012904.GP12007@darkness.comp.waw.pl>
<3838.1089306943@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="s1V7GiNVmT/EiLBY"
Content-Disposition: inline
In-Reply-To: <3838.1089306943@critter.freebsd.dk>
User-Agent: Mutt/1.4.2i
X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc
X-OS: FreeBSD 5.2.1-RC2 i386
cc: geom@freebsd.org
Subject: Re: Current GEOM problems.
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: GEOM-specific discussions and implementations
<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2004 18:19:11 -0000
--s1V7GiNVmT/EiLBY
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jul 08, 2004 at 07:15:43PM +0200, Poul-Henning Kamp wrote:
+> >2. Every class which use geom_slice cannot be unload when it has geoms
+> > (actually providers), because g_slice_destroy_geom() calls
+> > g_slice_spoiled() and g_slice_spoiled() calls g_wither_geom().
+> > If there are providers, geom will not be imediately destroyed,
+> > but orphan event will be send, so next time when g_slice_destroy_geo=
m()
+> > will be called for the same geom it will panic, because gp->softc is
+> > NULL.
+>=20
+>=20
+> can you try this untested patch ?
Nope, it doesn't work. I'll try to explain the problem more precise.
When g_wither_geom() is called from g_unload_class() via destroy_geom
method AND provider exists on this geom we can choose: panic or deadlock,
because:
- g_unload_class() is called from the event queue in blocking mode.
- g_wither_geom() calls g_orphan_provider().
- g_orphan_provider() sends event, but the event queue is blocked,
so provider can't be destroyed, so geom can't be withered.
- g_unload_class() tries to destroy this geom in loop, but it can't be
definitely destroyed.
The simplest solution which cames to my mind is to skip geoms that are
marked as beeing withered in g_unload_class().
BTW. You reproduce this panic by doing:
# glabel create foo <some_provider>
# glabel unload
--=20
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd@FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
--s1V7GiNVmT/EiLBY
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA7ZAdForvXbEpPzQRAiT+AJ9y1vfC5vHxoT6XTQqFwmfYS6qevgCfYa6h
QSIOvqz82AvoJ6kYcPKHXTc=
=b//M
-----END PGP SIGNATURE-----
--s1V7GiNVmT/EiLBY--