From owner-freebsd-geom@FreeBSD.ORG Sun Oct 2 12:47:06 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C165C1065670 for ; Sun, 2 Oct 2011 12:47:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 87E648FC13 for ; Sun, 2 Oct 2011 12:47:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 560854AC1C for ; Sun, 2 Oct 2011 16:47:05 +0400 (MSD) Date: Sun, 2 Oct 2011 16:46:58 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1608987289.20111002164658@serebryakov.spb.ru> To: freebsd-geom@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: What is geom_start() and struct bio contract? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 12:47:06 -0000 Hello, Freebsd-geom. What is contract of struct bio passed to geom_start()? Why, for example, geom_nop (and all others) does clone like this: cbp =3D g_clone_bio(bp); if (cbp =3D=3D NULL) { g_io_deliver(bp, ENOMEM); return; } cbp->bio_done =3D g_std_done; cbp->bio_offset =3D bp->bio_offset + sc->sc_offset; cbp->bio_data =3D bp->bio_data; cbp->bio_length =3D bp->bio_length; pp =3D LIST_FIRST(&gp->provider); KASSERT(pp !=3D NULL, ("NULL pp")); cbp->bio_to =3D pp; G_NOP_LOGREQ(cbp, "Sending request."); g_io_request(cbp, LIST_FIRST(&gp->consumer)); And doesn't modify offset and other fields of original bio? And second question about this code. Here are lines: pp =3D LIST_FIRST(&gp->provider); KASSERT(pp !=3D NULL, ("NULL pp")); cbp->bio_to =3D pp; Which put pointer to NOP's provider to bio_to field. But later, g_io_request() reset this field to provider, which is aatached to target consumer: pp =3D cp->provider; ... bp->bio_to =3D pp; Is it Ok? What should store this field? If it should store provider, which ISSUED this bio, why g_io_request() reset it? If it should store provider, which will EXECUTE this bio, why geom_nop set it to itself provider, and why is here this field at all, as it could be derived from bio_from (it seems, that it is always set to bio_from->provider!)? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 2 12:56:43 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B978E1065675; Sun, 2 Oct 2011 12:56:43 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4278FC0C; Sun, 2 Oct 2011 12:56:43 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 20D264AC1C; Sun, 2 Oct 2011 16:56:36 +0400 (MSD) Date: Sun, 2 Oct 2011 16:56:30 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1554151528.20111002165630@serebryakov.spb.ru> To: Lev Serebryakov In-Reply-To: <1608987289.20111002164658@serebryakov.spb.ru> References: <1608987289.20111002164658@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@FreeBSD.org Subject: Re: What is geom_start() and struct bio contract? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 12:56:43 -0000 Hello, Lev. You wrote 2 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 16:46:58: > Is it Ok? What should store this field? If it should store provider, > which ISSUED this bio, why g_io_request() reset it? If it should > store provider, which will EXECUTE this bio, why geom_nop set it to > itself provider, and why is here this field at all, as it could be > derived from bio_from (it seems, that it is always set to > bio_from->provider!)? On the other hand, bio_done() is called only if bio_from is NULL, and any bio issued with g_io_request() could not have bio_form set to NULL: g_io_request(struct bio *bp, struct g_consumer *cp) { struct g_provider *pp; int first; KASSERT(cp !=3D NULL, ("NULL cp in g_io_request")); ... bp->bio_from =3D cp; ... } void g_io_deliver(struct bio *bp, int error) { struct g_consumer *cp; struct g_provider *pp; ... cp =3D bp->bio_from; if (cp =3D=3D NULL) { bp->bio_error =3D error; bp->bio_done(bp); return; } ... } I'm completely puzzled, how does it work at all! Many GEOMs set bio_done to their done utilities, and then submit bio with g_io_request() and it seems to work! But why?! I could not understand this from quoted code! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 2 13:04:00 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B61106566B for ; Sun, 2 Oct 2011 13:04:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E15F8FC0C for ; Sun, 2 Oct 2011 13:04:00 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 759E34AC1C for ; Sun, 2 Oct 2011 17:03:59 +0400 (MSD) Date: Sun, 2 Oct 2011 17:03:53 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <182680354.20111002170353@serebryakov.spb.ru> To: freebsd-geom@FreeBSD.org In-Reply-To: <1554151528.20111002165630@serebryakov.spb.ru> References: <1608987289.20111002164658@serebryakov.spb.ru> <1554151528.20111002165630@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: What is geom_start() and struct bio contract? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 13:04:00 -0000 Hello, Freebsd-geom. You wrote 2 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 16:56:30: > I'm completely puzzled, how does it work at all! Many GEOMs set > bio_done to their done utilities, and then submit bio with > g_io_request() and it seems to work! But why?! I could not understand > this from quoted code! ok, biodone() calls this unconditionally, I need more broad grep area :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 2 19:15:08 2011 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2B88106566B; Sun, 2 Oct 2011 19:15:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6182D8FC13; Sun, 2 Oct 2011 19:15:08 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 159014AC1C; Sun, 2 Oct 2011 23:15:06 +0400 (MSD) Date: Sun, 2 Oct 2011 23:14:59 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <228926402.20111002231459@serebryakov.spb.ru> To: current@freebsd.org, fs@FreeBSD.org, geom@freebsd.org In-Reply-To: <1258376930.20111002193223@serebryakov.spb.ru> References: <1258376930.20111002193223@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags()) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 19:15:09 -0000 Hello, Current. You wrote 2 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 19:32:23: It seems, that error only occurs when I call alq API from geom threads (from g_events, for example). Module, which is not GEOM class, could use this API without any problem! Is it normal, that GEOM could not use vnode API? Is it normal, that this leads to panic, and not some diagnostic messages, even with WITNESS and other diagnostic options turned on? I'm looping fs@ and geom@, as it seems to be related to them. > I'm trying to create logging queue with alq kernel API. I call > alq_open_flags() like this in my module: > error =3D alq_open_flags(&sc->sc_alq, sc->sc_vnode_name, > curthread->td_ucred, ALQ_DEFAULT_CMODE, > sizeof(struct g_log_entry), ALQ_ORDERED); > and my system (10-CURRENT) panics with this stack trace (top frames > are DDB-related, so I omit them): > #5 0xc06101c3 in kdb_trap (type=3D12, code=3D0, tf=3D0xc4e29990) > at /usr/home/lev/FreeBSD-head/sys/kern/subr_kdb.c:620 > #6 0xc08290af in trap_fatal (frame=3D0xc4e29990, eva=3D136) > at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:958 > #7 0xc08292c0 in trap_pfault (frame=3D0xc4e29990, usermode=3D0, eva=3D13= 6) > at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:880 > #8 0xc0829f46 in trap (frame=3D0xc4e29990) > at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:555 > #9 0xc0812e7c in calltrap () > at /usr/home/lev/FreeBSD-head/sys/i386/i386/exception.s:168 > #10 0xc05cafc0 in _mtx_lock_flags (m=3D0x78, opts=3D0,=20 > file=3D0xc088c140 "/usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c",= =20 > line=3D2169) at /usr/home/lev/FreeBSD-head/sys/kern/kern_mutex.c:194 > #11 0xc0672eb2 in vref (vp=3D0x0) > at /usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c:2169 > #12 0xc066932f in namei (ndp=3D0xc4e29b74) > at /usr/home/lev/FreeBSD-head/sys/kern/vfs_lookup.c:264 > #13 0xc0682900 in vn_open_cred (ndp=3D0xc4e29b74, flagp=3D0xc4e29be8, cmo= de=3D384, > vn_open_flags=3D0, cred=3D0xc50fee80, fp=3D0x0) > at /usr/home/lev/FreeBSD-head/sys/kern/vfs_vnops.c:137 > #14 0xc5c42609 in alq_open_flags (alqp=3D0xc550dc08,=20 > file=3D0xc5108d40 "/usr/ada4.log", cred=3D0xc50fee80, cmode=3D384, si= ze=3D28, > flags=3D16) > at > /usr/home/lev/FreeBSD-head/sys/modules/alq/../../kern/kern_alq.c:451 > It seems, that vref() get NULL instead of valid pointer to struct > vnode. But I have no idea -- why?! Yes, I have no such file created, > but man alq(9) says, that it will create file for me. And if I point > to existed file, it panic anyway. > What do I do wrong?! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Mon Oct 3 07:34:25 2011 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92A2106566C; Mon, 3 Oct 2011 07:34:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6468FC08; Mon, 3 Oct 2011 07:34:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 3452E4AC1C; Mon, 3 Oct 2011 11:34:24 +0400 (MSD) Date: Mon, 3 Oct 2011 11:34:17 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <349860851.20111003113417@serebryakov.spb.ru> To: current@freebsd.org, fs@FreeBSD.org, geom@freebsd.org In-Reply-To: <228926402.20111002231459@serebryakov.spb.ru> References: <1258376930.20111002193223@serebryakov.spb.ru> <228926402.20111002231459@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags()) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 07:34:25 -0000 Hello, Current. You wrote 2 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 23:14:59: > It seems, that error only occurs when I call alq API from geom > threads (from g_events, for example). Module, which is not GEOM > class, could use this API without any problem! > Is it normal, that GEOM could not use vnode API? Is it normal, that > this leads to panic, and not some diagnostic messages, even with > WITNESS and other diagnostic options turned on? not holding (explicitly release before call) topology lock doesn't help. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Mon Oct 3 11:07:07 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D8F2106566C for ; Mon, 3 Oct 2011 11:07:07 +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 E433C8FC2A for ; Mon, 3 Oct 2011 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p93B76MI033764 for ; Mon, 3 Oct 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p93B7668033762 for freebsd-geom@FreeBSD.org; Mon, 3 Oct 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Oct 2011 11:07:06 GMT Message-Id: <201110031107.p93B7668033762@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, 03 Oct 2011 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider o kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres o kern/159091 geom [geom] GEOM fails to scan nested partitions to create p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] ABI change without version bump in 8.2 o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 64 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 18:05:19 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09AE106566C; Tue, 4 Oct 2011 18:05:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0428FC19; Tue, 4 Oct 2011 18:05:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 560964AC1C; Tue, 4 Oct 2011 22:05:16 +0400 (MSD) Date: Tue, 4 Oct 2011 22:05:07 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1927112464.20111004220507@serebryakov.spb.ru> To: freebsd-geom@FreeBSD.org, current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------5D1411103A082C07" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin Subject: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:05:20 -0000 ------------5D1411103A082C07 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Freebsd-geom. I've just committed (a branch with) the project, I worked on for last month (and imagined for last two years). It is GEOM Events subsystem. What is it? We now have pretty impressive set of GEOM modules, which covers many areas: infrastructure support (like geom_part), encryption (like geom_eli) and, what is interesting me most, RAID transformations like geom_stripe, geom_mirror and geom_raid. One thing is missed from software RAIDs is spare drives and state monitoring (yes, I know, that geom_raid supports spare drivers for metadata formats which supports them, but it not universal solution). My long-standing dream was to write special daemon for this, but, when I got some time for this project, and started to design, I understood, that we have such daemon: devd(8). So, here it is. GEOM Events. Project consists of several parts (all are ready and commited to project branch!): (1) Simple kernel API, which wraps up devctl_notify() call to unify different GEOM events. Now 4 events are specified: (a) DISCONNECT -- when GEOM loses (orphans or throw away due to errors) underlying provider. (b) DESTROY -- when GEOM destorys it provider. (c) SYNCSTART -- when GEOM starts to synchronizing volume (synchronizing new mirror component or recalculate RAID3/RAID5 checksum) (d) SYNCSTOP -- wwen GEOM finishes synchronization. Each event has arguments like class of GEOM, geom itself, provider in question and some others. For details, please, see geom-events(8) man page :) (2) Simple change in devd(8) config to process events from GEOM system and forward them to geom-events(8) scirpt. (3) geom-events(8) script which processes these events. It is fully-configurable and could perform these actions in reaction to events: (a) Replace failed providers with spare ones in case of DISCONNECT events. (b) Log events to syslog(8) with logger(1) (c) Notify administrator (typically -- root) with mail(1). (4) geom-events needs one small helper binary program: ggetmode(8). ggetmode(8) takes one argument -- provider name -- and prints its access mode, like r1w1e1 or r0w0e0. geom-events(8) script determines is spare provider avail or not, comparing it access mode with "r0w0e0" string. (5) Changes in all geom classes to post these events. I've covered all "actual" base classes with some exceptions: (a) geom_mbr and other old-stlye partition classes is untouched, as they are obsolete now. (b) geom_vinum is not covered. It is too complex for me, sorry :( (c) geom_raid is covered, but changes are not trivial ones. It needs review from Alexander Motin. Commit message describes what and why was changed. I've wrote extensive documentation for all new components -- especially for geom-events(8) script, which is main source of information about this project now. I've tested all classes in virtual machine, with spare drives and all stuff. Everything work perfectly. **I really appreciate your comments, and I want to see this project committed to CURRENT and MFCed to 9-STABLE in (near) future.** Project sources are in "projects/geom-events" SVN branch. All but last commits are organized by component, so you could review only changes in your part of tree. http://svnweb.freebsd.org/base/projects/geom-events/ This branch contains fix from kern/160562, to make raid3 spare drives work. Patch against CURRENT is attached. Thank you. --=20 // Black Lion AKA Lev Serebryakov ------------5D1411103A082C07-- From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 18:09:18 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80D7106566B; Tue, 4 Oct 2011 18:09:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADBAC8FC0A; Tue, 4 Oct 2011 18:09:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id CBF904AC1C; Tue, 4 Oct 2011 22:09:17 +0400 (MSD) Date: Tue, 4 Oct 2011 22:09:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <374955202.20111004220909@serebryakov.spb.ru> To: freebsd-geom@FreeBSD.org, current@freebsd.org, Alexander Motin In-Reply-To: <1927112464.20111004220507@serebryakov.spb.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:09:19 -0000 Hello, Lev. You wrote 4 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 22:05:07: > Patch against CURRENT is attached. Oh, sorry, it seems, that patch is too big for list. http://lev.serebryakov.spb.ru/download/geom-events-1.0.head.patch.gz --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 18:35:31 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69F121065673; Tue, 4 Oct 2011 18:35:31 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1A488FC17; Tue, 4 Oct 2011 18:35:30 +0000 (UTC) Received: by vws11 with SMTP id 11so927777vws.13 for ; Tue, 04 Oct 2011 11:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qZmbxfrofu75xyBRS5lRhqi/Qeh1/lgv0+C3i/oD0q0=; b=xnY1WObi7j+d9+bOdfTkOgJ3rpvHu4/SHnUBYqoTHA15JzVwJklmFM1Xu0irqIRrD9 73NXMMTAnLg7mrw3n9qP1mFi31gXb4eSUjY4UNbdPy3/vPJrQHxvdA0PjF4jb5nC+HV2 iu2PTkIx12qp1WmSwQYFUPNba9IaBwwc08h+k= MIME-Version: 1.0 Received: by 10.52.109.170 with SMTP id ht10mr1544289vdb.206.1317751952130; Tue, 04 Oct 2011 11:12:32 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Tue, 4 Oct 2011 11:12:32 -0700 (PDT) In-Reply-To: <1927112464.20111004220507@serebryakov.spb.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> Date: Tue, 4 Oct 2011 11:12:32 -0700 Message-ID: From: Freddie Cash To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin , current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 18:35:31 -0000 2011/10/4 Lev Serebryakov > One thing is missed from software RAIDs is spare drives and state > monitoring (yes, I know, that geom_raid supports spare drivers for > metadata formats which supports them, but it not universal solution). > Sounds impressive! Will be very useful for those using GEOM-based RAID (gmirror, gstripe, graid3, graid5, etc). Just curious: would the geom-events framework, and in particular the geom-events script, be useful for ZFS setups, for initiating replacements and providing "hot-spare" support? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 19:00:28 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 065CD10656D2 for ; Tue, 4 Oct 2011 19:00:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 03F088FC27 for ; Tue, 4 Oct 2011 19:00:26 +0000 (UTC) Received: by eyg7 with SMTP id 7so1136143eyg.13 for ; Tue, 04 Oct 2011 12:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=OgaCxAxiIlhHYPHj5Cfv8wit5Fz63WP7H120yQIKBeI=; b=WetIdxAaHWDSL6zdTr6mpEf15HD9WP4h4iuOhbVKQUATS1rAh4bVMBQMp86fapf4/Y CGre0wUPv4yiLnXKVI1xMtRVfpFCpLKea1IuqSrH6vorW5ngEz2/07YAdiL8nqVFWLTv pgGNesxOinfUQyQdtYR/7iN03zDg8+0nQNXVU= Received: by 10.223.55.136 with SMTP id u8mr2173426fag.46.1317752994156; Tue, 04 Oct 2011 11:29:54 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a7sm26359391fam.22.2011.10.04.11.29.52 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 11:29:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8B5082.2080005@FreeBSD.org> Date: Tue, 04 Oct 2011 21:29:22 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Freddie Cash References: <1927112464.20111004220507@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lev@freebsd.org, current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 19:00:28 -0000 On 04.10.2011 21:12, Freddie Cash wrote: > 2011/10/4 Lev Serebryakov > > > One thing is missed from software RAIDs is spare drives and state > monitoring (yes, I know, that geom_raid supports spare drivers for > metadata formats which supports them, but it not universal solution). > > > Sounds impressive! Will be very useful for those using GEOM-based RAID > (gmirror, gstripe, graid3, graid5, etc). > > Just curious: would the geom-events framework, and in particular the > geom-events script, be useful for ZFS setups, for initiating > replacements and providing "hot-spare" support? Now there is projects/zfsd branch that is doing alike things (disk auto-insertion and hot spares) specifically for the case of ZFS. It also uses devctl interface to receive events, but user-level part (zfsd itself) is tightly hardcoded to talk to ZFS, fetching statuses and making control actions. Not sure whether this functionality could be scripted within geom-events, but having single mechanism indeed would be nice. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 19:45:36 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310C2106566B for ; Tue, 4 Oct 2011 19:45:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D863F8FC08 for ; Tue, 4 Oct 2011 19:45:35 +0000 (UTC) Received: by qadz30 with SMTP id z30so900474qad.13 for ; Tue, 04 Oct 2011 12:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0b2c4UEXC09WA4Qxr7QoTCjlH5NR/lAaQZwUqCItJMc=; b=ZlgfYIvSmlmXw0vg1vZwrZUvdIG0baQLj0bsr2U9cWzjOYgWrxSxsLneISOQUvlGf1 95SCmcpuq06e2ys44sZo7opUlNJuJK9nH94YKRDTk4FUx5BBAtlTCMSVWKkHAqO9fvx3 i9CzOxtM3WWqLxDk05oMwSsjPf/8gDxHEkcEg= Received: by 10.68.55.100 with SMTP id r4mr11800915pbp.69.1317755716432; Tue, 04 Oct 2011 12:15:16 -0700 (PDT) Received: from kruse-180.4.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id ki1sm27242056pbb.3.2011.10.04.12.15.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 12:15:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Tue, 4 Oct 2011 12:15:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71B3C40A-29FA-4965-AEC0-DEAE65276F5B@gmail.com> References: <1927112464.20111004220507@serebryakov.spb.ru> To: Freddie Cash X-Mailer: Apple Mail (2.1084) Cc: Alexander Motin , lev@freebsd.org, current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 19:45:36 -0000 On Oct 4, 2011, at 11:12 AM, Freddie Cash wrote: > 2011/10/4 Lev Serebryakov >=20 >> One thing is missed from software RAIDs is spare drives and state >> monitoring (yes, I know, that geom_raid supports spare drivers for >> metadata formats which supports them, but it not universal solution). >>=20 >=20 > Sounds impressive! Will be very useful for those using GEOM-based = RAID > (gmirror, gstripe, graid3, graid5, etc). >=20 > Just curious: would the geom-events framework, and in particular the > geom-events script, be useful for ZFS setups, for initiating = replacements > and providing "hot-spare" support? Work in the zfsd project branch already seems to do this = properly. Please note that some HBAs (like mps) don't play well with = hotswap on some branches, whereas others (mfi) might, depending on how = things are coded up and chipset support. Thanks, -Garrett= From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 20:17:24 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2089F1065670; Tue, 4 Oct 2011 20:17:24 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 846DB8FC0C; Tue, 4 Oct 2011 20:17:23 +0000 (UTC) Received: by vws11 with SMTP id 11so1064634vws.13 for ; Tue, 04 Oct 2011 13:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Us9puV0Rneav09XvL+f0piOauhUfmEzIWLY3gqxasAk=; b=COAUzqjYuBRFu8ouyz+yriDuGQWvOQByAGE8pRiyYOFa3EdMrMoHP668RJ17ewFUi/ XfrGyt0KwAq5UBpUtR0AIxTVnV2zTbFf4TLq7eBP93IWEd1ZHsPpy0csUtfWb6Guxp3o +jw7Ek6K3U0E/XuNcPdSlj1Oy/4pTMZF4dEHY= MIME-Version: 1.0 Received: by 10.52.109.170 with SMTP id ht10mr1684273vdb.206.1317759442668; Tue, 04 Oct 2011 13:17:22 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Tue, 4 Oct 2011 13:17:22 -0700 (PDT) In-Reply-To: <71B3C40A-29FA-4965-AEC0-DEAE65276F5B@gmail.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <71B3C40A-29FA-4965-AEC0-DEAE65276F5B@gmail.com> Date: Tue, 4 Oct 2011 13:17:22 -0700 Message-ID: From: Freddie Cash To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin , lev@freebsd.org, current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 20:17:24 -0000 On Tue, Oct 4, 2011 at 12:15 PM, Garrett Cooper wrote: > On Oct 4, 2011, at 11:12 AM, Freddie Cash wrote: > > > 2011/10/4 Lev Serebryakov > > > >> One thing is missed from software RAIDs is spare drives and state > >> monitoring (yes, I know, that geom_raid supports spare drivers for > >> metadata formats which supports them, but it not universal solution). > >> > > Sounds impressive! Will be very useful for those using GEOM-based RAID > > (gmirror, gstripe, graid3, graid5, etc). > > > > Just curious: would the geom-events framework, and in particular the > > geom-events script, be useful for ZFS setups, for initiating replacements > > and providing "hot-spare" support? > > Work in the zfsd project branch already seems to do this properly. > Please note that some HBAs (like mps) don't play well with hotswap on some > branches, whereas others (mfi) might, depending on how things are coded up > and chipset support. > Cool! Sounds like we're just around the corner from having a top-notch software RAID stack via GEOM/ZFS with all the automatic goodies one expects/hopes for. :) Keep up the good work people!! -- Freddie Cash fjwcash@gmail.com From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 21:27:07 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E37C106564A; Tue, 4 Oct 2011 21:27:07 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2398FC12; Tue, 4 Oct 2011 21:27:07 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BBAAB28429; Tue, 4 Oct 2011 23:27:05 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 045E028426; Tue, 4 Oct 2011 23:27:03 +0200 (CEST) Message-ID: <4E8B7A27.5070908@quip.cz> Date: Tue, 04 Oct 2011 23:27:03 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> In-Reply-To: <1927112464.20111004220507@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 21:27:07 -0000 Lev Serebryakov wrote: [...] > One thing is missed from software RAIDs is spare drives and state > monitoring (yes, I know, that geom_raid supports spare drivers for > metadata formats which supports them, but it not universal solution). I am still missing one thing - dropped provider is not marked as failed RAID provider and is accessible for anything like normal disk device. So in some edge cases, the system can boot from failed RAID component instead of degraded RAID. This can cause data loss or demage. Is it possible to fix it by something like your geom-events, or should it be done in each GEOM RAID class separately? But after all, I realy appreciate your work in this area! I hope I will have time to test it soon. Thank you! Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Tue Oct 4 21:45:53 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2271B106564A; Tue, 4 Oct 2011 21:45:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8428FC0C; Tue, 4 Oct 2011 21:45:51 +0000 (UTC) Received: by eyg7 with SMTP id 7so1355882eyg.13 for ; Tue, 04 Oct 2011 14:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=KAIzUQgM7LFsV1guEHuvEFqw7VcrvZRsvK+0l5D5/Kg=; b=t5DhNb29iXxmLczs2ONQUiqsvXaW3+oNOcuTMMZtFfSimWfZCTmA5tMhkPZjQmzDlg ng+rMGaEY+yv/UU1XCxXesEh44grU2mZqsy/VtMYUWTBIxqAsYMlbGdce3oQCeLj1Dgd Wsj0DAz6A8/jqyFaGSzzsREF5j6UeDLhWRLjw= Received: by 10.223.55.146 with SMTP id u18mr2387103fag.108.1317764750972; Tue, 04 Oct 2011 14:45:50 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c1sm27027655fab.15.2011.10.04.14.45.49 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 14:45:50 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8B7E76.5020907@FreeBSD.org> Date: Wed, 05 Oct 2011 00:45:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> In-Reply-To: <4E8B7A27.5070908@quip.cz> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: lev@FreeBSD.org, current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 04 Oct 2011 21:45:53 -0000 Miroslav Lachman wrote: > Lev Serebryakov wrote: >> One thing is missed from software RAIDs is spare drives and state >> monitoring (yes, I know, that geom_raid supports spare drivers for >> metadata formats which supports them, but it not universal solution). > > I am still missing one thing - dropped provider is not marked as failed > RAID provider and is accessible for anything like normal disk device. So > in some edge cases, the system can boot from failed RAID component > instead of degraded RAID. This can cause data loss or demage. To reliably boot from RAID array, you need help from some RAID BIOS. While booting from correctly working gmirror is possible, it may not be reliable when array is degraded. That is one of the main benefits of the graid, comparing to gmirror -- cooperation with RAID BIOS. Ability to track failed devices also depends on specific metadata format. For example, for Intel RAID BIOS, metadata stored on each disk include information about all other disks used now. As result, if some disk fails and system is unable to update it's metadata any more, that information can still be stored on other devices to prevent disk resurrection in most cases. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 05:07:19 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D57B1065687; Wed, 5 Oct 2011 05:07:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward9.mail.yandex.net (forward9.mail.yandex.net [77.88.61.48]) by mx1.freebsd.org (Postfix) with ESMTP id 353998FC17; Wed, 5 Oct 2011 05:07:19 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward9.mail.yandex.net (Yandex) with ESMTP id 3165BCE14A6; Wed, 5 Oct 2011 09:07:17 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1317791237; bh=uxuZyah2sD/7mNJwzhnDgRbwQA6mNzjVYqd7szj+mO4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SFuLSgSecbXDSaWgqGXdoIXYwzoS5kBWgnzmMSiaY4XBET3Io7EtzkIN9TQXJhpta t9XUpA6JDNpmcJqkghbk69z+I2orzgx9yNQVPIYpaZxASzeGC+kLGf84GHzfHQo4Ps y8ahXu33j9eb0HYdOzxA/GTwW5084uQbB1o0lcPU= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id EFFBA1B603D1; Wed, 5 Oct 2011 09:07:16 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1317791237; bh=uxuZyah2sD/7mNJwzhnDgRbwQA6mNzjVYqd7szj+mO4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SFuLSgSecbXDSaWgqGXdoIXYwzoS5kBWgnzmMSiaY4XBET3Io7EtzkIN9TQXJhpta t9XUpA6JDNpmcJqkghbk69z+I2orzgx9yNQVPIYpaZxASzeGC+kLGf84GHzfHQo4Ps y8ahXu33j9eb0HYdOzxA/GTwW5084uQbB1o0lcPU= Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 7GeCTr9D-7GeC1KVE; Wed, 5 Oct 2011 09:07:16 +0400 X-Yandex-Spam: 1 Message-ID: <4E8BE604.7090803@yandex.ru> Date: Wed, 05 Oct 2011 09:07:16 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> In-Reply-To: <1927112464.20111004220507@serebryakov.spb.ru> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 05:07:19 -0000 On 04.10.2011 22:05, Lev Serebryakov wrote: > So, here it is. GEOM Events. > > Project consists of several parts (all are ready and commited to > project branch!): > Hi, Lev > (5) Changes in all geom classes to post these events. It seems that you could change only geom_dev.c to get most of what you want. Actually, the part of your changes related to the DISCONNECT events, and maybe DESTROY events could be implemented in the geom_dev. -- WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 06:20:08 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BC03106564A; Wed, 5 Oct 2011 06:20:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 159088FC16; Wed, 5 Oct 2011 06:20:08 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 391F54AC1C; Wed, 5 Oct 2011 10:20:06 +0400 (MSD) Date: Wed, 5 Oct 2011 10:19:57 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <344794801.20111005101957@serebryakov.spb.ru> To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4E8B7A27.5070908@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:20:08 -0000 Hello, Miroslav. You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 1:27:03: > I am still missing one thing - dropped provider is not marked as failed > RAID provider and is accessible for anything like normal disk device. So > in some edge cases, the system can boot from failed RAID component=20 > instead of degraded RAID. This can cause data loss or demage. What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? Something else? If GEOM class drops underlying provider due to errors, it doesn't have chances to update metadata for it. But most of classes, if dropped provider attached again, will rebuild itself, as they track which components are actual and which ones are old. Do you want GEOM classes to track droppen components somewhere else and din't even try to attach them automaticaly when they re-appear? > Is it possible to fix it by something like your geom-events, or should > it be done in each GEOM RAID class separately? geom-events only process events from GEOM classes in userland. Each class should decide what happens to him by itself, as only class itself knows is this particular error fatal or not. geom-events could help, if it replaces dropped component fith spare drive, as in such case most classes prefer "latest" drive, not old one. Without spares, everything will be exactly as it is now, plus e-mails to administrator :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 06:27:20 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B277106566C; Wed, 5 Oct 2011 06:27:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 306EB8FC14; Wed, 5 Oct 2011 06:27:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id E68C34AC1C; Wed, 5 Oct 2011 10:27:18 +0400 (MSD) Date: Wed, 5 Oct 2011 10:27:10 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1822051193.20111005102710@serebryakov.spb.ru> To: "Andrey V. Elsukov" In-Reply-To: <4E8BE604.7090803@yandex.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:27:20 -0000 Hello, Andrey. You wrote 5 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 9:07:16: > It seems that you could change only geom_dev.c to get most of what you wa= nt. > Actually, the part of your changes related to the DISCONNECT events, and > maybe DESTROY events could be implemented in the geom_dev. Does geom_dev knows all needed bits of information to report? It seems to= me, that it isn't. I mean: (1) Class and name of GEOM which is affected. (2) Name of provider which is affected. (3) Name of underlying provider which is lost (consumer from reporting GEOM's point of view). (4) Resulting state of affected provider (fixable, alive, dead). Yes, geom_dev knows name of FAILED provider, but does it knows all other? I'm affraid -- not, or I don't understand how generic mechanism could now, that geom_stripe could not lose components and still be fixable, and gome_mirror could. Additionally, some GEOM classes could throw away faulty consumers before they disappear from geom_dev point of view. Actually, DESTROY could be observed without my changes at all -- message from DEVFS about removing entry :) But, again, this notification will not contain name and class of GEOM, only provider's name (devfs entry). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 06:39:55 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32BA3106566B; Wed, 5 Oct 2011 06:39:55 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB6988FC0A; Wed, 5 Oct 2011 06:39:54 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AE81A4AC1C; Wed, 5 Oct 2011 10:39:53 +0400 (MSD) Date: Wed, 5 Oct 2011 10:39:45 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1239869336.20111005103945@serebryakov.spb.ru> To: "Andrey V. Elsukov" , current@freebsd.org, In-Reply-To: <1822051193.20111005102710@serebryakov.spb.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:39:55 -0000 Hello, Andrey. You wrote 5 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 10:27:10: >> It seems that you could change only geom_dev.c to get most of what you w= ant. >> Actually, the part of your changes related to the DISCONNECT events, and >> maybe DESTROY events could be implemented in the geom_dev. > Does geom_dev knows all needed bits of information to report? It seems = to me, > that it isn't. > I mean: > (1) Class and name of GEOM which is affected. > (2) Name of provider which is affected. > (3) Name of underlying provider which is lost (consumer from > reporting GEOM's point of view). > (4) Resulting state of affected provider (fixable, alive, dead). And, I'm affraid, that geom_dev could not distinguish manual operations with geom (performed from userland by administrator) and real accidents. I don't want geoms to post DISCONNECTED or DESTROYED events when administrator knows what he does -- and it could lead to race conditions, when administrator rebuild array and forgot todisable spare drives, for example. Other example -- geom_label creates and destroys about 10 labels on boot (on my test VM) and, if DESTROYED will be reported by very generic mechanism, it will end up with 10 e-mails to administrator on every boot -- I've got this, when put notifications in too generic place for first try. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 06:42:49 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A25A106566C for ; Wed, 5 Oct 2011 06:42:49 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id F3C1F8FC0A for ; Wed, 5 Oct 2011 06:42:48 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 956AD7233 for ; Wed, 5 Oct 2011 08:26:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; s=selector1; bh=3KMNtUk5LeraP6QdWPdskDtDPNk=; b=r 7rh8tjnmVVI6j7Hk67cWtLT1j7WgiiM3SyFI0apD7x/ZGnUkKXm2WVUN22N1M5cW kBZ96cffTEpBqy0O4/pvzuxF4HGyg8wuXEaQaFZQ3fOTKqZvR5ntAJg4Qzt1SjE3 GAlBSkh5y/8kOizZ/4lxmu8aSJsimE3bnKFJ+icrVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; q=dns; s=selector1; b=yVLWf4qcwTVzsPLqicDV3glGKxj 0c2bLGVUzEQSBthoc9phdqJoU9kcabuejBNNFGrTshYYd6j/GjrfZZX6da7858Wb BbwYyzWEbZXdjUFsodZ7oZSPtb5xXfGKDZbNO6Vs6MDkacbfbZnzc2MwWuZnNr41 xTTL9l1HHtXDo32w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=selector1; t=1317795968; bh=msG/NnZprUpljEy4veDrv+h SqLdaK+4wVPkCgM9RmMU=; b=XkF8MSAaNJ7pIlsITNXg+K/GNduWfvb6CEVVSB8 t9sUjDp0WXMVNYrIC8GOxuauHxwVpfA/hFdT3ZAM9BJf+xtkIi6lUNaYCnGDTIrT OT71kyq++IR5yEqD5t7pwZ+lYENWp7BEFdXkc5EgsZ8SImMcUivfl9Ee57Y6B3Pz Oel0= Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dcl3VngR1oh5 for ; Wed, 5 Oct 2011 08:26:08 +0200 (CEST) Received: from [192.168.166.168] (unknown [210.188.173.246]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 3A6D5722C for ; Wed, 5 Oct 2011 08:26:07 +0200 (CEST) Message-ID: <4E8BF86F.4000806@darkbsd.org> Date: Wed, 05 Oct 2011 15:25:51 +0900 From: Stephane LAPIE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> In-Reply-To: <344794801.20111005101957@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig935178B8E7540EFBC0EA63ED" Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 06:42:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig935178B8E7540EFBC0EA63ED Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable On 10/05/2011 03:19 PM, Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 1:27:03: >=20 >> I am still missing one thing - dropped provider is not marked as faile= d >> RAID provider and is accessible for anything like normal disk device. = So >> in some edge cases, the system can boot from failed RAID component=20 >> instead of degraded RAID. This can cause data loss or demage. > What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? > Something else? If GEOM class drops underlying provider due to errors, > it doesn't have chances to update metadata for it. > But most of classes, if dropped provider attached again, will > rebuild itself, as they track which components are actual and which > ones are old. > Do you want GEOM classes to track droppen components somewhere else > and din't even try to attach them automaticaly when they re-appear? >=20 >> Is it possible to fix it by something like your geom-events, or should= >> it be done in each GEOM RAID class separately? > geom-events only process events from GEOM classes in userland. Each > class should decide what happens to him by itself, as only class > itself knows is this particular error fatal or not. > geom-events could help, if it replaces dropped component fith spare > drive, as in such case most classes prefer "latest" drive, not old > one. Without spares, everything will be exactly as it is now, plus > e-mails to administrator :) A bit unrelated, but are there plans to integrate hardware RAID (mps/mfi/mpt/amr) failure notification in the same way as this would be done for GEOM ? As in, "one framework and way to manage both hard and soft RAIDs". --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig935178B8E7540EFBC0EA63ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6L+HEACgkQ24Ql8u6TF2O7xACfRui1lHr3Zr45kXXTQTjn443F oOwAoIz3wZZyM90fDLpgXkVVkfmJ2fM4 =titG -----END PGP SIGNATURE----- --------------enig935178B8E7540EFBC0EA63ED-- From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 06:51:44 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 184691065670; Wed, 5 Oct 2011 06:51:44 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D0CFB8FC16; Wed, 5 Oct 2011 06:51:43 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 8E65E4AC1C; Wed, 5 Oct 2011 10:51:42 +0400 (MSD) Date: Wed, 5 Oct 2011 10:51:33 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <491799917.20111005105133@serebryakov.spb.ru> To: Stephane LAPIE , current@freebsd.org In-Reply-To: <4E8BF86F.4000806@darkbsd.org> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8BF86F.4000806@darkbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:51:44 -0000 Hello, Stephane. You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 10:25:51: > On 10/05/2011 03:19 PM, Lev Serebryakov wrote: > A bit unrelated, but are there plans to integrate hardware RAID > (mps/mfi/mpt/amr) failure notification in the same way as this would be > done for GEOM ? As in, "one framework and way to manage both hard and > soft RAIDs". I don't have such plans, as I think, only drivers authors could identify proper places to add event sending. Drivers are much more complicated, that RAID classes (I was unable to find proper places for geom_vinum, for example, and hardware drivers doesn't look simpler, that that). But from userland's point of view, there is nothing special about hardware RAIDs -- geom-events(8) needs two commands to be configured: to remove failed drive from array and to add new one, that's all. Of course, "GEOM" system name in events will looks like odd for hardware controllers. But it could be renamed to something more generic. And hardware controllers has same bits of information as software ones -- type of controller, name of failed drive, name of affected volume and resulting state, everything is the same. So, if here is interest form hardware RAID driver's authors, it could be integrated, of course. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 07:51:45 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E2FC106566C; Wed, 5 Oct 2011 07:51:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [IPv6:2a02:6b8:0:202::2]) by mx1.freebsd.org (Postfix) with ESMTP id AD4AE8FC17; Wed, 5 Oct 2011 07:51:44 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward7.mail.yandex.net (Yandex) with ESMTP id E786A1C062A; Wed, 5 Oct 2011 11:51:42 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1317801103; bh=4CrI5UidBDIQdj/nHfz8M1EbembrrFQ/AFY1jWJSBow=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZMZSICkc1wYKjEa8Rrf5JdzlMhYbBG2iVQMBUBAr24qmbemlTY3vJLjXvnp6aIyOX TasOWQFbxxUGyuLTm+ANbT4yUhU7ws0ne7TeFPOU3aZLE8gGDbXA0pwNNWPCtBN6F+ ikEhuqaqSuPGtBa9iKpVxclaPXXpNXOgvrb5O7nc= Received: from smtp6.mail.yandex.net (localhost [127.0.0.1]) by smtp6.mail.yandex.net (Yandex) with ESMTP id BD3F216403A3; Wed, 5 Oct 2011 11:51:42 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1317801102; bh=4CrI5UidBDIQdj/nHfz8M1EbembrrFQ/AFY1jWJSBow=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lQZwE4f8u/ZeV7yx+vxJy0qTrta4JV3DJOzlgAqTZ5OXsU6C9H8Le0/Je/yDg8xqu 2Eq/NHtAMLZPyzNmyAZMxjaTQAh6TrOt51WR3Y8iPFL2ClFWzjYfcWtfFeEEWBEAqe FvswhrGXxd5DWTPsiCbrY4VOdVutsIQhLkWb9mbE= Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp6.mail.yandex.net (nwsmtp/Yandex) with ESMTP id pguO8Ube-pgu0ZYvU; Wed, 5 Oct 2011 11:51:42 +0400 X-Yandex-Spam: 1 Message-ID: <4E8C0C88.7000702@yandex.ru> Date: Wed, 05 Oct 2011 11:51:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> <1239869336.20111005103945@serebryakov.spb.ru> In-Reply-To: <1239869336.20111005103945@serebryakov.spb.ru> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 07:51:45 -0000 On 05.10.2011 10:39, Lev Serebryakov wrote: >> (1) Class and name of GEOM which is affected. >> (2) Name of provider which is affected. >> (3) Name of underlying provider which is lost (consumer from >> reporting GEOM's point of view). >> (4) Resulting state of affected provider (fixable, alive, dead). All except last could be get from the consumer in the orphan method. > And, I'm affraid, that geom_dev could not distinguish manual > operations with geom (performed from userland by administrator) and > real accidents. I don't want geoms to post DISCONNECTED or DESTROYED > events when administrator knows what he does -- and it could lead to > race conditions, when administrator rebuild array and forgot todisable > spare drives, for example. > Other example -- geom_label creates and destroys about 10 labels on > boot (on my test VM) and, if DESTROYED will be reported by very > generic mechanism, it will end up with 10 e-mails to administrator on > every boot -- I've got this, when put notifications in too generic > place for first try. Ok, good point. Can you explain how your script will distinguish which actions are performed by administrator? Since change made by administrator could trigger disappearing of several child geoms. -- WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 08:00:22 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C22106566B for ; Wed, 5 Oct 2011 08:00:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AFC878FC0C for ; Wed, 5 Oct 2011 08:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9580MYW047099 for ; Wed, 5 Oct 2011 08:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9580MZO047095; Wed, 5 Oct 2011 08:00:22 GMT (envelope-from gnats) Date: Wed, 5 Oct 2011 08:00:22 GMT Message-Id: <201110050800.p9580MZO047095@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: "Serverel NOC#3" Cc: Subject: Re: kern/158197: [geom] geom_cache with size> 1000 leads to panics X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Serverel NOC#3 List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:00:23 -0000 The following reply was made to PR kern/158197; it has been noted by GNATS. From: "Serverel NOC#3" To: bug-followup@freebsd.org, bsd@kobyla.org Cc: Subject: Re: kern/158197: [geom] geom_cache with size>1000 leads to panics Date: Wed, 05 Oct 2011 07:29:12 -0000 Panics occur when more than one instance of gcache are active. So, having 2 geom caches for /usr and /usr/obj, and making install of ports with WRKDIRPREFIX=/usr/obj/work leads to panic, no matter which size of geom caches used. But single active instance of gcache for /usr/obj seems to show no problems ("inactive" instances are present, but not used to mount filesystems). From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 08:24:10 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F70106564A; Wed, 5 Oct 2011 08:24:10 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id E86BC8FC0C; Wed, 5 Oct 2011 08:24:09 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5EB2028426; Wed, 5 Oct 2011 10:24:08 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 571C728422; Wed, 5 Oct 2011 10:24:07 +0200 (CEST) Message-ID: <4E8C1426.60107@quip.cz> Date: Wed, 05 Oct 2011 10:24:06 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> In-Reply-To: <344794801.20111005101957@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 08:24:10 -0000 Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 îêòÿáðÿ 2011 ã., 1:27:03: > >> I am still missing one thing - dropped provider is not marked as failed >> RAID provider and is accessible for anything like normal disk device. So >> in some edge cases, the system can boot from failed RAID component >> instead of degraded RAID. This can cause data loss or demage. > What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? > Something else? I am mostly using geom_mirror. > If GEOM class drops underlying provider due to errors, > it doesn't have chances to update metadata for it. I understand this, but if there are (stale) metadata on provider, system can read this metadata and should disallow normal operations (for example propagating slices, partitions and labels) > But most of classes, if dropped provider attached again, will > rebuild itself, as they track which components are actual and which > ones are old. I see many times dropped provider (for example ada1) because of some DMA timeout (bad cables and so on), sometimes provider (disk ada1) detached from ATA channel and reattached after reboot. In both cases, provider has stale metadata and is marked as "broken" by geom_mirror and auto rebuild did not start. In this case, I see gm0 with all of its slices, partitions and labels and ada1 with the same slices, partitions and labels - this is the problem. Because there are two devices providing same labels and the winner is the first tasted... Even if the system (geom_mirror) knows, that ada1 is "broken disk". I think that GEOM should be more robust in this case and if metadata is found, do not publish slices, partitions, labels and so on... > Do you want GEOM classes to track droppen components somewhere else > and din't even try to attach them automaticaly when they re-appear? If some disk is removed, reinserted and synchronisation starts, then everything is OK. But situation where component is marked as "broken" and system and user can operate on it like on normal "good and clean" drive is wrong. The drive's content should be inacessible until operator do some action (for example gmirror clear on broken disk device). Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 08:51:15 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32BA3106564A; Wed, 5 Oct 2011 08:51:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C29448FC16; Wed, 5 Oct 2011 08:51:14 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id CE8C24AC1C; Wed, 5 Oct 2011 12:51:12 +0400 (MSD) Date: Wed, 5 Oct 2011 12:51:04 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <813229977.20111005125104@serebryakov.spb.ru> To: "Andrey V. Elsukov" In-Reply-To: <4E8C0C88.7000702@yandex.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> <1239869336.20111005103945@serebryakov.spb.ru> <4E8C0C88.7000702@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:51:15 -0000 Hello, Andrey. You wrote 5 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 11:51:36: > On 05.10.2011 10:39, Lev Serebryakov wrote: >>> (1) Class and name of GEOM which is affected. >>> (2) Name of provider which is affected. >>> (3) Name of underlying provider which is lost (consumer from >>> reporting GEOM's point of view). >>> (4) Resulting state of affected provider (fixable, alive, dead). > All except last could be get from the consumer in the orphan method. I'm afraid, that (2) could not be known too in generic way, as GEOM could have several providers, and only part of them could be affected by disconnection. Consumer contains geom (with class) and underlying provider, it is items (1) and (3)... >> Other example -- geom_label creates and destroys about 10 labels on >> boot (on my test VM) and, if DESTROYED will be reported by very >> generic mechanism, it will end up with 10 e-mails to administrator on >> every boot -- I've got this, when put notifications in too generic >> place for first try. > Ok, good point. Can you explain how your script will distinguish which > actions are performed by administrator? Since change made by administrator > could trigger disappearing of several child geoms. Not the script, but GEOMs themselves. They knows, why disk disappears. Of course, it work only one-level -- if administrator calls "gmirror remove gm0 ada4" geom_mirror knows, that ada4 is no failed. Yes, I understand, that if here is configuration like this: gmirror0 gstripe0 ada0 ada1 gstripe1 ada2 ada3 and administrator kills gstripe0, for example, geom_mirror will send event, because from its point of view it is not administrative action... But such situations, IMHO, are not very often ones. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 08:58:35 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72CC8106564A; Wed, 5 Oct 2011 08:58:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 369A98FC1A; Wed, 5 Oct 2011 08:58:35 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DF79A4AC1C; Wed, 5 Oct 2011 12:58:33 +0400 (MSD) Date: Wed, 5 Oct 2011 12:58:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <251861322.20111005125825@serebryakov.spb.ru> To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4E8C1426.60107@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:58:35 -0000 Hello, Miroslav. You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 12:24:06: >> What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? >> Something else? > I am mostly using geom_mirror. [SKIPPED] Oh, I see. Unfortunately, there is no GEOM metadata infrastructire, GEOMs are too generic for this. I could design some meta-meta framework, and unify all RAID classes with "intenral" metadtata (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external geom_raid5) to use it. In such case it will work -- kernel will not pass providers with "ditry" metadtata to any GEOMs, but owners, for tasting. Of course, classes like geom_part and geom_raid could not be changed in such way -- they are forced to use pre-defined metadata formats. It is good idea, but it should be separate project. And, yes, it will change metadata format for these GEOMs, so it will not be backward-compatible. And, yes, it seems to be much more intrusive change in GEOM subsystem (because it will change tasting sequence), and should be supervised by other developers from very beginning. I could write proposal in near future, with some design notes. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 09:19:08 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF21106564A; Wed, 5 Oct 2011 09:19:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6DD8FC19; Wed, 5 Oct 2011 09:19:07 +0000 (UTC) Received: by eyg7 with SMTP id 7so1905908eyg.13 for ; Wed, 05 Oct 2011 02:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=deYHTQDk1XjVSDTxGcSBLsGaFmMzgNJzJ2zt19TbIKQ=; b=XEQpabn8iW9nYSIURndiRu0CaO7clsKAlGKR6MoPFRdzHjDu1dRioGc0wpZfDijLzP 95uRtk5FrJkZKw/zGoKt1oJk9mvacacFhj5GCBYig/H7ZmomxhcxRahTekB1yeIgKB0c F6wMU6WIj7083eP6HnDDSHcvjIVQoUzhFzPlw= Received: by 10.223.47.207 with SMTP id o15mr3254687faf.88.1317806346376; Wed, 05 Oct 2011 02:19:06 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a1sm1534102fab.4.2011.10.05.02.19.04 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 02:19:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8C20EA.5060501@FreeBSD.org> Date: Wed, 05 Oct 2011 12:18:34 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> In-Reply-To: <251861322.20111005125825@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 09:19:08 -0000 On 05.10.2011 11:58, Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 îêòÿáðÿ 2011 ã., 12:24:06: > >>> What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? >>> Something else? >> I am mostly using geom_mirror. > [SKIPPED] > Oh, I see. Unfortunately, there is no GEOM metadata infrastructire, > GEOMs are too generic for this. I could design some meta-meta > framework, and unify all RAID classes with "intenral" metadtata > (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external > geom_raid5) to use it. In such case it will work -- kernel will not > pass providers with "ditry" metadtata to any GEOMs, but owners, for > tasting. Of course, classes like geom_part and geom_raid could not be > changed in such way -- they are forced to use pre-defined metadata > formats. geom_raid addresses this problem in own way. As soon as RAID BIOSes expect RAIDs to be built on raw physical devices and probe order is not discussed, geom_raid exclusively opens underlying providers immediately after detecting supported metadata. So even if volume is broken or incomplete or this disk marked failed, or in any other case, this disk won't be accessible for other GEOM classes. If administrator wishes to reuse this disk for any other purpose, he should explicitly erase on-disk metadata using graid tool or with dd after unloading geom_raid. Up to the recent time geom tools didn't report geoms without providers. Now there is special "-a" argument to report all of them. Also there is "-g" to report geoms instead of providers, that is useful in such cases. > It is good idea, but it should be separate project. And, yes, it > will change metadata format for these GEOMs, so it will not be > backward-compatible. > > And, yes, it seems to be much more intrusive change in GEOM > subsystem (because it will change tasting sequence), and should be > supervised by other developers from very beginning. > > I could write proposal in near future, with some design notes. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 09:29:51 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9076D106566B; Wed, 5 Oct 2011 09:29:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 532188FC18; Wed, 5 Oct 2011 09:29:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 063054AC2D; Wed, 5 Oct 2011 13:29:49 +0400 (MSD) Date: Wed, 5 Oct 2011 13:29:41 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1453791516.20111005132941@serebryakov.spb.ru> To: Alexander Motin In-Reply-To: <4E8C20EA.5060501@FreeBSD.org> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C20EA.5060501@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 09:29:51 -0000 Hello, Alexander. You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 13:18:34: > geom_raid addresses this problem in own way. As soon as RAID BIOSes > expect RAIDs to be built on raw physical devices and probe order is not > discussed, geom_raid exclusively opens underlying providers immediately > after detecting supported metadata. So even if volume is broken or But it could be not first, who taste component of mirror, am I right? If geom_part will be first, will it "take away" component from geom_raid? Or it could not? If it works in any case (exclusive open spoils geom_part), it could be used in all other classes without any metadata infrastructure, but it seems, that geom_mirror, for example, could pickup metadtata from last parition instead of raw device... I'm not sure here. But, in any case, maybe standard first 16 bytes of metadata in pure-GEOM classes and filter in GEOM infrastructure itself ("not pass provider for tasting to anything but class, written in first 16 bytes of last sector") looks good idea, IMHO. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 14:49:46 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F90F106566B; Wed, 5 Oct 2011 14:49:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7758FC15; Wed, 5 Oct 2011 14:49:45 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8D99328431; Wed, 5 Oct 2011 16:49:44 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9058A2842D; Wed, 5 Oct 2011 16:49:42 +0200 (CEST) Message-ID: <4E8C6E85.90005@quip.cz> Date: Wed, 05 Oct 2011 16:49:41 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> In-Reply-To: <251861322.20111005125825@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Motin , current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 14:49:46 -0000 Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 îêòÿáðÿ 2011 ã., 12:24:06: > >>> What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? >>> Something else? >> I am mostly using geom_mirror. > [SKIPPED] > Oh, I see. Unfortunately, there is no GEOM metadata infrastructure, > GEOMs are too generic for this. I could design some meta-meta > framework, and unify all RAID classes with "intenral" metadtata > (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external > geom_raid5) to use it. In such case it will work -- kernel will not > pass providers with "dirty" metadtata to any GEOMs, but owners, for > tasting. Of course, classes like geom_part and geom_raid could not be > changed in such way -- they are forced to use pre-defined metadata > formats. > > It is good idea, but it should be separate project. And, yes, it > will change metadata format for these GEOMs, so it will not be > backward-compatible. > > And, yes, it seems to be much more intrusive change in GEOM > subsystem (because it will change tasting sequence), and should be > supervised by other developers from very beginning. > > I could write proposal in near future, with some design notes. I am waiting years for the moment, when these GEOM problems will be fixed, so I am really glad to see your interest! It will be move to right direction even if changes will not be backward compatible. The current state is too fragile to be used in production. Gmirror alone can be used, glabel alone can be used, GPT alone can be used... but mix it all stacked together is way to hell. e.g. Using GPT on glabeled provider always ends with error message about corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I cannot use glable on devices and iSCSI device can have different number on each reboot? I wrote about it almost 2 years ago) GEOM layering possibilities are really amazing, but metadata, tasting and robustness in edge cases is not well done. If you are able to come with some fixes in GEOM metadata implementation / handling, I see better future :) Unfortunately, I am not a C programmer, so I cannot write patches, but I can test whatever you will need in this area. You are right, it should be separate project. I am looking forward to your proposal / wiki page. Thank you again for your work on GEOM improvements! Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 15:40:37 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5CAB106568E; Wed, 5 Oct 2011 15:40:37 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 553498FC24; Wed, 5 Oct 2011 15:40:37 +0000 (UTC) Received: by dyj4 with SMTP id 4so130322dyj.13 for ; Wed, 05 Oct 2011 08:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKitPAMJp9kvs6kOss+4IH7m1hzZb1MQS+dfgDtbidA=; b=sova6deSc3GMmByzP5vgo+AKe9yvdoY4GyGnhVM1Ob3A+hCcKfGdCV85RD6PcLT3rr jxGPQlgP+AnPsF7ID00tSU3VESFcYqFIgnw+VIjGJ/AInhmZ9GPaTnRJ11s0oVSRuvJc aDxpTt8tvfZDw5l0hnRl3/5jiR/rLDDYnVhRo= MIME-Version: 1.0 Received: by 10.223.11.23 with SMTP id r23mr1442299far.38.1317827526866; Wed, 05 Oct 2011 08:12:06 -0700 (PDT) Received: by 10.152.6.36 with HTTP; Wed, 5 Oct 2011 08:12:06 -0700 (PDT) In-Reply-To: <4E8C6E85.90005@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> Date: Wed, 5 Oct 2011 10:12:06 -0500 Message-ID: From: Scot Hetzel To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 15:40:38 -0000 2011/10/5 Miroslav Lachman <000.fbsd@quip.cz>: > I am waiting years for the moment, when these GEOM problems will be fixed, > so I am really glad to see your interest! > It will be move to right direction even if changes will not be backward > compatible. > The current state is too fragile to be used in production. Gmirror alone can > be used, glabel alone can be used, GPT alone can be used... but mix it all > stacked together is way to hell. > > e.g. Using GPT on glabeled provider always ends with error message about > corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I > cannot use glable on devices and iSCSI device can have different number on > each reboot? I wrote about it almost 2 years ago) > You don't need to use glabel on GPT disks, as gpart has it's own way to label GPT disks: Fixit# gpart create -s gpt ad0 Fixit# gpart add -s 4G -t freebsd-swap -l swap0 ad0 Fixit# gpart add -t freebsd-zfs -l disk0 ad0 This create the following in /dev: /dev/gpt/swap0 /dev/gpt/disk0 Glabel is not needed for GPT partitioned disks. What should happen is that glabel should fail when attempting to label a GPT disk. If you wish to add a GPT label after the fact use: gpart show geom gpart modify -i index -l label geom (i.e. geom = ad0) Scot From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 21:35:31 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095C6106564A; Wed, 5 Oct 2011 21:35:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA548FC12; Wed, 5 Oct 2011 21:35:29 +0000 (UTC) Received: by wwe3 with SMTP id 3so3083563wwe.31 for ; Wed, 05 Oct 2011 14:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jnLrks4nO3XwIRezoiRW1kcp/vBMiEUMVYqQhct5ZTM=; b=wsKBJDdNsLUVMyzj4UsUvhlhwTUGHOXeB3aG0gZEp3+rck+ZHGQH0uJ7vhkGWfMxTJ KypSCw3NzYE7KZnughDOTIXzhJB1ONuGzLg7Aydd2eSHkKp7MfVHwl6ySZGOsJjRbjDD hZfjLUdwNZRGQpW90ZC+rwr735f4Fz0RkHV/w= Received: by 10.227.20.67 with SMTP id e3mr3799642wbb.5.1317850529051; Wed, 05 Oct 2011 14:35:29 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (ip212-238-37-54.hotspotsvankpn.com. [212.238.37.54]) by mx.google.com with ESMTPS id y10sm5508942wbm.14.2011.10.05.14.35.26 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 14:35:27 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8CCD69.5000802@FreeBSD.org> Date: Thu, 06 Oct 2011 00:34:33 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C20EA.5060501@FreeBSD.org> <1453791516.20111005132941@serebryakov.spb.ru> In-Reply-To: <1453791516.20111005132941@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 21:35:31 -0000 On 05.10.2011 12:29, Lev Serebryakov wrote: > You wrote 5 îêòÿáðÿ 2011 ã., 13:18:34: >> geom_raid addresses this problem in own way. As soon as RAID BIOSes >> expect RAIDs to be built on raw physical devices and probe order is not >> discussed, geom_raid exclusively opens underlying providers immediately >> after detecting supported metadata. So even if volume is broken or > But it could be not first, who taste component of mirror, am I > right? If geom_part will be first, will it "take away" component from > geom_raid? Or it could not? Most of GEOM classes are less aggressive. So geom_raid will any way taste device finally and geom_part should be automatically spoiled as soon as geom_raid open device. > If it works in any case (exclusive open spoils geom_part), it could > be used in all other classes without any metadata infrastructure, That works perfect for case when class (geom_raid) is known to work on raw device. Other RAID classes can be used over partitions, so some care should be taken to avoid false positives. > but > it seems, that geom_mirror, for example, could pickup metadtata from > last parition instead of raw device... > > I'm not sure here. In that case it is helpful to include media size into the metadata. Comparing that value with provider size during taste allows to avoid these false positives. geom_mirror metadata include/check provider size since version 3. Pity that MBR and probably others don't. > But, in any case, maybe standard first 16 bytes of metadata in > pure-GEOM classes and filter in GEOM infrastructure itself ("not pass > provider for tasting to anything but class, written in first 16 bytes > of last sector") looks good idea, IMHO. And what if class is not loaded/supported? There should be a way to manage/clear that label. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 22:12:54 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC96A1065674; Wed, 5 Oct 2011 22:12:54 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8975C8FC0C; Wed, 5 Oct 2011 22:12:54 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A64732842B; Thu, 6 Oct 2011 00:12:52 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C5D432842A; Thu, 6 Oct 2011 00:12:51 +0200 (CEST) Message-ID: <4E8CD662.90202@quip.cz> Date: Thu, 06 Oct 2011 00:12:50 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Scot Hetzel References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 22:12:54 -0000 Scot Hetzel wrote: > 2011/10/5 Miroslav Lachman<000.fbsd@quip.cz>: >> I am waiting years for the moment, when these GEOM problems will be fixed, >> so I am really glad to see your interest! >> It will be move to right direction even if changes will not be backward >> compatible. >> The current state is too fragile to be used in production. Gmirror alone can >> be used, glabel alone can be used, GPT alone can be used... but mix it all >> stacked together is way to hell. >> >> e.g. Using GPT on glabeled provider always ends with error message about >> corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I >> cannot use glable on devices and iSCSI device can have different number on >> each reboot? I wrote about it almost 2 years ago) >> > You don't need to use glabel on GPT disks, as gpart has it's own way > to label GPT disks: [...] The point was that glabel on disk device is successful, gpartitioning on glabeled device is successful, but metadata handling / device tasting is wrong after reboot and this should be fixed, not worked around. Otherwise thank you for example with GPT labels, it can be useful in some cases. Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 23:15:17 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61227106564A; Wed, 5 Oct 2011 23:15:17 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id 030CC8FC1E; Wed, 5 Oct 2011 23:15:16 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p95Mrra9039436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 15:53:53 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p95MrrHh039435; Wed, 5 Oct 2011 15:53:53 -0700 (PDT) (envelope-from jmg) Date: Wed, 5 Oct 2011 15:53:53 -0700 From: John-Mark Gurney To: Lev Serebryakov Message-ID: <20111005225353.GG14645@funkthat.com> Mail-Followup-To: Lev Serebryakov , "Andrey V. Elsukov" , current@freebsd.org, freebsd-geom@freebsd.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> <1239869336.20111005103945@serebryakov.spb.ru> <4E8C0C88.7000702@yandex.ru> <813229977.20111005125104@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813229977.20111005125104@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 05 Oct 2011 15:53:53 -0700 (PDT) Cc: "Andrey V. Elsukov" , current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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, 05 Oct 2011 23:15:17 -0000 Lev Serebryakov wrote this message on Wed, Oct 05, 2011 at 12:51 +0400: > Hello, Andrey. > You wrote 5 ??????? 2011 ?., 11:51:36: > > > On 05.10.2011 10:39, Lev Serebryakov wrote: > >>> (1) Class and name of GEOM which is affected. > >>> (2) Name of provider which is affected. > >>> (3) Name of underlying provider which is lost (consumer from > >>> reporting GEOM's point of view). > >>> (4) Resulting state of affected provider (fixable, alive, dead). > > > All except last could be get from the consumer in the orphan method. > I'm afraid, that (2) could not be known too in generic way, as GEOM > could have several providers, and only part of them could be affected by > disconnection. Consumer contains geom (with class) and underlying > provider, it is items (1) and (3)... > > >> Other example -- geom_label creates and destroys about 10 labels on > >> boot (on my test VM) and, if DESTROYED will be reported by very > >> generic mechanism, it will end up with 10 e-mails to administrator on > >> every boot -- I've got this, when put notifications in too generic > >> place for first try. > > Ok, good point. Can you explain how your script will distinguish which > > actions are performed by administrator? Since change made by administrator > > could trigger disappearing of several child geoms. > Not the script, but GEOMs themselves. They knows, why disk > disappears. Of course, it work only one-level -- if administrator > calls "gmirror remove gm0 ada4" geom_mirror knows, that ada4 is no > failed. Yes, I understand, that if here is configuration like this: > > gmirror0 > gstripe0 > ada0 > ada1 > gstripe1 > ada2 > ada3 > > and administrator kills gstripe0, for example, geom_mirror will send > event, because from its point of view it is not administrative > action... > But such situations, IMHO, are not very often ones. Won't gmirror still report COMPLETE after a gmirror remove? So the script can look at the gmirror device, and see that it is still complete even though one of the providers were dropped and assume it was an administrative command that did it.. -- 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 Thu Oct 6 06:56:23 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22629106566B; Thu, 6 Oct 2011 06:56:23 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D5A978FC13; Thu, 6 Oct 2011 06:56:22 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AECE54AC32; Thu, 6 Oct 2011 10:47:21 +0400 (MSD) Date: Thu, 6 Oct 2011 10:47:12 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <592430497.20111006104712@serebryakov.spb.ru> To: John-Mark Gurney In-Reply-To: <20111005225353.GG14645@funkthat.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> <1239869336.20111005103945@serebryakov.spb.ru> <4E8C0C88.7000702@yandex.ru> <813229977.20111005125104@serebryakov.spb.ru> <20111005225353.GG14645@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: "Andrey V. Elsukov" , current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 06:56:23 -0000 Hello, John-Mark. You wrote 6 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 2:53:53: >> gmirror0 >> gstripe0 >> ada0 >> ada1 >> gstripe1 >> ada2 >> ada3 >>=20 >> and administrator kills gstripe0, for example, geom_mirror will send >> event, because from its point of view it is not administrative >> action... >> But such situations, IMHO, are not very often ones. > Won't gmirror still report COMPLETE after a gmirror remove? So the I say "kill gstripe0", not "Remove gstripe0 from gmirror0", it is different situations. gmirror0 will be DEGRADED after this action, but will send DISCONNECT message with "fixable" state and it is state when geom-events(8) try to find replacement (spare). Exactly as when it lost component due to accident. If you say "gmirror remove", yes, it will be COMPLETE after it. > script can look at the gmirror device, and see that it is still > complete even though one of the providers were dropped and assume > it was an administrative command that did it.. Here is one problem: there is no STANDARD way to understand state of provider from userland, as it is GEOM-specific. "g${class} status ${geom}"= prints almost free-form information. Not all classes names it "COMPLETE", and some classes (geom_raid, for example) could have many providers and many states, which adds complexity. So, to make it work this way I need to add knowledge about all classes and their output formats to geom-ecents(8). I don't think, that it is good design -- it is bad idea to put knowledge about GEOM classes in two places -- class itself and some script. It will hard to synchronize, etc. So, I think, GEOM class itself should decide and report its state in standard way. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 06:56:23 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F61106566C; Thu, 6 Oct 2011 06:56:23 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D5B298FC14; Thu, 6 Oct 2011 06:56:22 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 682804AC1C; Thu, 6 Oct 2011 10:39:43 +0400 (MSD) Date: Thu, 6 Oct 2011 10:39:33 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <17859561.20111006103933@serebryakov.spb.ru> To: Alexander Motin In-Reply-To: <4E8CCD69.5000802@FreeBSD.org> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C20EA.5060501@FreeBSD.org> <1453791516.20111005132941@serebryakov.spb.ru> <4E8CCD69.5000802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 06:56:23 -0000 Hello, Alexander. You wrote 6 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 1:34:33: > That works perfect for case when class (geom_raid) is known to work on > raw device. Other RAID classes can be used over partitions, so some care > should be taken to avoid false positives. Oh, yes... I see... >> I'm not sure here. > In that case it is helpful to include media size into the metadata. > Comparing that value with provider size during taste allows to avoid > these false positives. geom_mirror metadata include/check provider size > since version 3. Pity that MBR and probably others don't. Yep. > And what if class is not loaded/supported? There should be a way to > manage/clear that label. Most of classes have "clear" command which doesn't need loaded module and works completely from userland now (as "label" works from userland too for these classes). And, if such changes will be made, generic command to "geom" itself, without class at all, could be added -- of course, it will refuse to clear anything that doesn't start from "common" signature. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 12:25:39 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951CB1065739; Thu, 6 Oct 2011 12:25:39 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0260F8FC1D; Thu, 6 Oct 2011 12:25:38 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p96BkF1S051778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Oct 2011 14:46:21 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E8D9136.6040200@digsys.bg> Date: Thu, 06 Oct 2011 14:29:58 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110917 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ivan Voras References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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: Thu, 06 Oct 2011 12:25:39 -0000 On 06.10.11 14:07, Ivan Voras wrote: > > Um, you do realize this is a "physical" problem with metadata location > and cannot be solved in any meaningful way? Geom_label stores its label > in the last sector of the device, and GPT stores the "secondary" / > backup table also at the end of the device. The two can NEVER work > together. The same goes for any other GEOM class which stores metadata > and GPT. The proper way for this is to have these things store their metadata in the first/last sector of the provider, not the underlying device. This means that, if you have GPT within GLABEL, for example -- you will only see the GPT label if you first see the GLABEL. I guess the present situation was created out of laziness ;) From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 12:59:24 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B75C1065670; Thu, 6 Oct 2011 12:59:24 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id C98498FC12; Thu, 6 Oct 2011 12:59:23 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 894A628423; Thu, 6 Oct 2011 14:59:21 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 5340328429; Thu, 6 Oct 2011 14:59:20 +0200 (CEST) Message-ID: <4E8DA627.60003@quip.cz> Date: Thu, 06 Oct 2011 14:59:19 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Ivan Voras References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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: Thu, 06 Oct 2011 12:59:24 -0000 Ivan Voras wrote: >> The point was that glabel on disk device is successful, gpartitioning on >> > glabeled device is successful, but metadata handling / device tasting is >> > wrong after reboot and this should be fixed, not worked around. >> > >> > Otherwise thank you for example with GPT labels, it can be useful in >> > some cases. > Um, you do realize this is a "physical" problem with metadata location > and cannot be solved in any meaningful way? Geom_label stores its label > in the last sector of the device, and GPT stores the "secondary" / > backup table also at the end of the device. The two can NEVER work > together. The same goes for any other GEOM class which stores metadata > and GPT. > > The only way to get this sorted out is to make a label class (or adapt > glabel) which does NOT store metadata anywhere on the devices. Maybe > they can store it in the file system (a file in /etc - though you then > lose bootability, and have to somehow connect devices and labels), or > the device hardware ID can be used as a label (but not all devices have > it, and in case of "software" constructs like iSCSI the labels can be > changed). Then there should be warning in documentation or error message printed by command in the time of writing metadata. I am not a GEOM expert, but isn't it wrong concept, that glabel writes its metadata and publish original device size? If some GEOM write metadata at last sector (or first), then it should shrink the published size (or offset). Or is the problem at geom_part, that it is writing metadata past the advertised end of the device? e.g. If I have disk device with size of 100 sectors and glabel metadata is stored at the last sector, then glabel should shrink the advertised size to 99 sectors - then GPT secondary table will be at sector 99 instead of 100. I know there is problem if somebody access the device by its normal device node (e.g. /dev/ada0), then secondary GPT table will be at different place, not in last sector. But this is the mistake in glabel concept and if it cannot be solved by any other way, then glabel should not be allowed to place labels on the disk device at all. (if we cannot be sure it is non conflicting) The current state is simply wrong, because user can do something what cannot work and is not documented anywhere. Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 13:53:46 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5471065675; Thu, 6 Oct 2011 13:53:46 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 839B38FC12; Thu, 6 Oct 2011 13:53:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 904034AC2D; Thu, 6 Oct 2011 17:53:44 +0400 (MSD) Date: Thu, 6 Oct 2011 17:53:34 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <672948039.20111006175334@serebryakov.spb.ru> To: Daniel Kalchev In-Reply-To: <4E8D9136.6040200@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:53:47 -0000 Hello, Daniel. You wrote 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 15:29:= 58: > The proper way for this is to have these things store their metadata in > the first/last sector of the provider, not the underlying device. > This means that, if you have GPT within GLABEL, for example -- you will > only see the GPT label if you first see the GLABEL. > I guess the present situation was created out of laziness ;) No. GPT (and MBR) metadata placement is dictated from outside world, where is no GEOM and geom_label. They INTENDED to be used on DISKS. BIOSes should be able to find it :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 13:56:23 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A18D106566C; Thu, 6 Oct 2011 13:56:23 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B5BFD8FC12; Thu, 6 Oct 2011 13:56:22 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6C1944AC2D; Thu, 6 Oct 2011 17:56:21 +0400 (MSD) Date: Thu, 6 Oct 2011 17:56:11 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <711721489.20111006175611@serebryakov.spb.ru> To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4E8DA627.60003@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8DA627.60003@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:56:23 -0000 Hello, Miroslav. You wrote 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16:59:= 19: > I am not a GEOM expert, but isn't it wrong concept, that glabel writes > its metadata and publish original device size? If some GEOM write=20 > metadata at last sector (or first), then it should shrink the published > size (or offset). Or is the problem at geom_part, that it is writing=20 > metadata past the advertised end of the device? Good point. > e.g. If I have disk device with size of 100 sectors and glabel metadata > is stored at the last sector, then glabel should shrink the advertised > size to 99 sectors - then GPT secondary table will be at sector 99=20 > instead of 100. > The current state is simply wrong, because user can do something what > cannot work and is not documented anywhere. It is Ok in UNIX way, in general. You should be able to shoot your leg, it is good :) But if geom_label doesn't reduce its provider to count its own metadata, it looks like a bug! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 14:41:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8DFC9106567C; Thu, 6 Oct 2011 14:41:27 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D4FB61778DC; Thu, 6 Oct 2011 14:41:25 +0000 (UTC) Message-ID: <4E8DBDDA.2070405@FreeBSD.org> Date: Thu, 06 Oct 2011 18:40:26 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ivan Voras References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig72D06EE7EE699576503845D3" Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events 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: Thu, 06 Oct 2011 14:41:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72D06EE7EE699576503845D3 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 06.10.2011 16:36, Ivan Voras wrote: > 2) this makes the device unbootable as the GPT partition is per > definition not valid. It still stores the primary partition table on th= e > first sector (and the following sectors...), but its secondary table is= > stored at one sector short of device's last sector (which is used by > glabel). Any utilities and BIOSes which test for GPT will find the firs= t > table but not the last and depending on how sensitive / broken they are= , > they will either recognize a broken GPT (and/or try to fix it, > destroying the glabel label), or not work at all. Actually we support booting from GPT when secondary GPT header is not in the last LBA. Our bootcode will complain in this situation, but it works.= --=20 WBR, Andrey V. Elsukov --------------enig72D06EE7EE699576503845D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOjb3hAAoJEAHF6gQQyKF6W5AH/3HXS0y2iXBZBDKTtpaRkQS4 wlqYkeaOleUvspkQWu1hFCeKliU/SXgFxJPk2XaRKsvuIBuSVanWDHUzJg64JhUX gtp3mE/MYhSV/hI46JJU9+SLmPZS/HD5kdrEwaKqsAa1pSnzMgBj0y1dctqK7DWJ F/5k0d8cCzk6dUJXM0tkbF4Irlgl1UOj/050VftvL/R8wXqOlJiht2xFWP4FyAGZ 7JUCPAvVU7eijXT7+zXo7yo5wbY491KA/sfy06KuD5LeicYt0KrUsuH6S1k92cQc 6wR2OwT5RFzUUpkbULcTso3hF0l0DO638cgceKuJXJCREZYWuZEhZdLB9Qri3C0= =n6QK -----END PGP SIGNATURE----- --------------enig72D06EE7EE699576503845D3-- From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 07:09:21 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8EE106566B for ; Fri, 7 Oct 2011 07:09:21 +0000 (UTC) (envelope-from talbright@pcphonehome.com) Received: from qmail.frontline.net (mail.brigadoonsoftware.com [66.59.64.147]) by mx1.freebsd.org (Postfix) with ESMTP id D9DE38FC0C for ; Fri, 7 Oct 2011 07:09:20 +0000 (UTC) Received: (qmail 12657 invoked by uid 89); 7 Oct 2011 06:44:30 -0000 Received: from unknown (HELO ?192.168.1.2?) (68.193.179.224) by 0 with SMTP; 7 Oct 2011 06:44:30 -0000 Message-Id: <5joqJFb4zHuh8yLLdGEqY9C2K2y9u7OeCDXjTpwx3Yq4@pcphonehome.com> Mime-Version: 1.0 From: Tim Albright To: freebsd-geom@freebsd.org Date: Fri, 7 Oct 2011 02:44:30 -0400 X-Mailer: MBM v2.7-US X-Bounce-Tracking-Info: Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Subject: Laptop Theft in South Africa at All Time High - Software Tracks & Recovers Lost & Stolen Computers X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 07:09:21 -0000 =08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08= =08=08=08Greetings, Our award PC PhoneHome and MacPhoneHome is the NUMBER ONE stand-alone computer tracking and recovery software in the world to both the Windows and Mac communities! We are currently protecting over 1,500,000 computers worldwide=2E Unlike OTHER computer tracking products, PC PhoneHome and MacPhoneHome contain NO SPYWARE to invade your privacy=2E=2E=2E Every time a PC PhoneHome or MacPhoneHome protected computer makes an Internet connection, it sends a stealth email message containing its exact location to a pre-determined email address of the user's choice and to our Worldwide Command Center=2E In the event your computer goes missing, all you need to do is make a police report and contact us=2E We do the rest=2E Your missing computer is returned to you with the help of our recovery agents, local police services and global ISPs=2E Our lost & stolen computer recovery rate is over 99% worldwide! The SINGLE COPY version of PC PhoneHome and MacPhoneHome normally retail for $29=2E95 each=2E Our new Family/Household license which costs a one time fee of $79=2E95 USD allows the user to install PC PhoneHome and/or MacPhoneHome on as many computers in the household as is necessary, even the ones your kids may have away at college! You have 5-8-12 computers? No Problem! Our Family Household license protects them all! Only $79=2E95! No yearly monitoring fees=2E No hidden costs=2E No additional charges! We still provide full location and recovery service=2E This is the BEST deal in the industry! Our 2011 Special Bundle Deals will save you a BUNDLE of money! You can mix any combination of PC PhoneHome and/or MacPhoneHome in your deal! Please visit: http://www=2Ebrigadoonsoftware=2Ecom/purchase=2Ehtml today to= purchase and download your copy of PC PhoneHome/MacPhoneHome=2E Ask for a price quote on our CUSTOM BLANKET ENTERPRISE LICENSE for LARGE SCALE DEPLOYMENT to HUNDREDS or THOUSANDS of computers! Whether you're trying to protect one hundred computers or twenty thousand we have the right license plan for you=2E We will soon be releasing PhoneHome protection for iPods, iPhones and the NEW iPad=2E=2E=2E Version 4=2E0 will offer our users multi-lingual installation and documentation in English, Spanish, Portuguese, Italian, French and German language=2E Version 4=2E0 will OPTIONALLY snap the picture of whoever is sitting at the computer and send you a picture of the thief if your computer is lost or stolen as well as offer PhoneHome protection for your iPod, iPhone and iPad! Reseller Inquires are Invited! Information on our product line is available for download directly from our web site at: http://www=2Ebrigadoonsoftware=2Ecom If you are interested in finding out more or have any additional questions about our single copy, bundle deal or Enterprise license program, please feel free to contact me personally at 1-845-624-0909= =2E Best Regards, Tim Albright VP - Sales Brigadoon Software, Inc=2E 119 Rockland Center Suite 250 Nanuet, New York 10954 USA Tel: +1-845-624-0909 Fax: +1-845-624-0990 Email: talbright@brigadoonsoftware=2Ecom Web: http://www=2Ebrigadoonsoftware=2Ecom To be excluded from future emails, please type "Remove"=20 in the subject line and reply to this message=2E Please include all email aliases you are using=2E From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 07:13:28 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72ACF1065769; Fri, 7 Oct 2011 07:13:28 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 37AF68FC17; Fri, 7 Oct 2011 07:13:28 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p977DJvo024804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 00:13:19 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p977DJTF024803; Fri, 7 Oct 2011 00:13:19 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00305; Fri, 7 Oct 11 00:07:29 PDT Date: Fri, 07 Oct 2011 07:06:38 -0700 From: perryh@pluto.rain.com To: lev@freebsd.org Message-Id: <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> In-Reply-To: <672948039.20111006175334@serebryakov.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 07:13:28 -0000 Lev Serebryakov wrote: > GPT (and MBR) metadata placement is dictated from outside world, > where is no GEOM and geom_label. They INTENDED to be used on DISKS. > BIOSes should be able to find it :) Certainly GPT and MBR must place an instance of the partition table where the BIOS expects it, but there's no immediately obvious reason why they must regard that instance as their GEOM metadata. GPT puts a second copy in the provider's last block, and AFAICT it could just as well use _that_ instance -- or even a differently-formatted block that included the same data -- as the primary. MBR could do likewise. From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 07:28:16 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E041065670; Fri, 7 Oct 2011 07:28:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1382A8FC0A; Fri, 7 Oct 2011 07:28:16 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 735FF4AC1C; Fri, 7 Oct 2011 11:28:13 +0400 (MSD) Date: Fri, 7 Oct 2011 11:28:02 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1646032486.20111007112802@serebryakov.spb.ru> To: perryh@pluto.rain.com In-Reply-To: <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 07:28:16 -0000 Hello, Perryh. You wrote 7 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 18:06:38: >> GPT (and MBR) metadata placement is dictated from outside world, >> where is no GEOM and geom_label. They INTENDED to be used on DISKS. >> BIOSes should be able to find it :) > Certainly GPT and MBR must place an instance of the partition table > where the BIOS expects it, but there's no immediately obvious reason > why they must regard that instance as their GEOM metadata. GPT puts > a second copy in the provider's last block, and AFAICT it could just > as well use _that_ instance -- or even a differently-formatted block GPT must have backup copy in last sector by standard, it is not caprise of GEOM class author.. BIOSes could refuse to boot from it, if they don't find second copy. And it could occupies not only one sector, but up to 34 of them. > that included the same data -- as the primary. MBR could do likewise. MBR doesn;t have any additional metadata. How adding one will help it? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 19:44:25 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B62C6106566B; Fri, 7 Oct 2011 19:44:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCF78FC15; Fri, 7 Oct 2011 19:44:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 3A42C4AC1C; Fri, 7 Oct 2011 23:44:23 +0400 (MSD) Date: Fri, 7 Oct 2011 23:44:12 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1822982078.20111007234412@serebryakov.spb.ru> To: perryh@pluto.rain.com In-Reply-To: <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org, lev@freebsd.org, ivoras@freebsd.org, freebsd-current@freebsd.org, daniel@digsys.bg Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 19:44:25 -0000 Hello, Perryh. You wrote 7 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 18:06:38: >> GPT (and MBR) metadata placement is dictated from outside world, >> where is no GEOM and geom_label. They INTENDED to be used on DISKS. >> BIOSes should be able to find it :) > Certainly GPT and MBR must place an instance of the partition table > where the BIOS expects it, but there's no immediately obvious reason > why they must regard that instance as their GEOM metadata. GPT puts > a second copy in the provider's last block, and AFAICT it could just > as well use _that_ instance -- or even a differently-formatted block > that included the same data -- as the primary. MBR could do likewise. I have deja-vu, that I answered this. Please, read standard. GPT _must_ be placed twice -- at first and last sectors (really, more than one sectors). By standard. Secondary copy must be at end of disk. Period. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 20:15:19 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE51106566C; Fri, 7 Oct 2011 20:15:19 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 875608FC22; Fri, 7 Oct 2011 20:15:18 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p97KF8gK060624 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Oct 2011 23:15:13 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E8F5D82.7050906@digsys.bg> Date: Fri, 07 Oct 2011 23:13:54 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> In-Reply-To: <1822982078.20111007234412@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, perryh@pluto.rain.com, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 20:15:19 -0000 On 07.10.11 22:44, Lev Serebryakov wrote: > Hello, Perryh. > You wrote 7 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 18:06:38: > >>> GPT (and MBR) metadata placement is dictated from outside world, >>> where is no GEOM and geom_label. They INTENDED to be used on DISKS. >>> BIOSes should be able to find it :) >> Certainly GPT and MBR must place an instance of the partition table >> where the BIOS expects it, but there's no immediately obvious reason >> why they must regard that instance as their GEOM metadata. GPT puts >> a second copy in the provider's last block, and AFAICT it could just >> as well use _that_ instance -- or even a differently-formatted block >> that included the same data -- as the primary. MBR could do likewise.= > I have deja-vu, that I answered this. Please, read standard. GPT > _must_ be placed twice -- at first and last sectors (really, more > than one sectors). By standard. Secondary copy must be at end of > disk. Period. > Then, "by standard" GPT cannot coexist with GLABEL. Such setup should be = disallowed, or at least big nasty message that you have just shoot=20 yourself in the leg should be output. (period) Daniel From owner-freebsd-geom@FreeBSD.ORG Fri Oct 7 20:23:55 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DB0B106564A for ; Fri, 7 Oct 2011 20:23:55 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC7C38FC14 for ; Fri, 7 Oct 2011 20:23:54 +0000 (UTC) Received: by gyf2 with SMTP id 2so5074719gyf.13 for ; Fri, 07 Oct 2011 13:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=TTtVvydd5zeug+5gFtCK2M/mPmNBsEf9OHxAMuJuQn4=; b=e88FfREbzXmM8bJ0CRU8kbXSwe+6GSO4JgD6hWZjKHGLvGtfU0Q3O8z6RAKmvQCHR2 zCRKlJ3BcN7CSwCcfwkuLCKK8R435QgWw52fli50saAD9fFIB5S7JKqcFdJcDLNveNqx 7W13pGgfkWc5/reFpmMj6GGWwQ5glmi3zcoTA= Received: by 10.100.84.9 with SMTP id h9mr1850049anb.121.1318019034109; Fri, 07 Oct 2011 13:23:54 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.43.9 with HTTP; Fri, 7 Oct 2011 13:23:14 -0700 (PDT) In-Reply-To: <4E8F5D82.7050906@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> From: Ivan Voras Date: Fri, 7 Oct 2011 22:23:14 +0200 X-Google-Sender-Auth: TX52Df_WDbgdqBQUfIw2gn_NOyA Message-ID: To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 20:23:55 -0000 2011/10/7 Daniel Kalchev : > Then, "by standard" GPT cannot coexist with GLABEL. Such setup should be > disallowed, or at least big nasty message that you have just shoot yourself > in the leg should be output. (period) GPT cannot coexist with ANY GEOM CLASS which writes metadata to the last sector. If you think this should be explicitely handled, please file a PR which requests the modification of gpart so that it detects that a GPT is being created in anything other than a raw drive, and warns the user. From owner-freebsd-geom@FreeBSD.ORG Sat Oct 8 03:01:56 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 552C010656AA; Sat, 8 Oct 2011 03:01:56 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CFB988FC17; Sat, 8 Oct 2011 03:01:55 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p9831jRf044546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 20:01:46 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p9831jnt044545; Fri, 7 Oct 2011 20:01:45 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01736; Fri, 7 Oct 11 19:53:13 PDT Date: Sat, 08 Oct 2011 02:52:21 -0700 From: perryh@pluto.rain.com To: lev@freebsd.org Message-Id: <4e901d55.j0M8m+Tba3WC+Wrp%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1646032486.20111007112802@serebryakov.spb.ru> In-Reply-To: <1646032486.20111007112802@serebryakov.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 03:01:56 -0000 Lev Serebryakov wrote: > GPT must have backup copy in last sector by standard ... In that case, shouldn't it refuse to install on any provider that is not in fact a disk, so as not to create configurations that cannot work properly? > MBR doesn;t have any additional metadata. How adding one will help it? It would add robustness, for cases like the one that started this thread. If MBR put a GEOM metadata block at the end of its provider, it would fix the tasting race when an MBR is installed on a glabelled (or gmirrored) drive. From owner-freebsd-geom@FreeBSD.ORG Sat Oct 8 08:57:01 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D98106566B; Sat, 8 Oct 2011 08:57:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4A98FC0C; Sat, 8 Oct 2011 08:57:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 731194AC2D; Sat, 8 Oct 2011 12:55:56 +0400 (MSD) Date: Sat, 8 Oct 2011 12:55:43 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1993293883.20111008125543@serebryakov.spb.ru> To: Daniel Kalchev In-Reply-To: <4E8F5D82.7050906@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, perryh@pluto.rain.com, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 08:57:01 -0000 Hello, Daniel. You wrote 8 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 0:13:54: >>>> GPT (and MBR) metadata placement is dictated from outside world, >>>> where is no GEOM and geom_label. They INTENDED to be used on DISKS. >>>> BIOSes should be able to find it :) >>> Certainly GPT and MBR must place an instance of the partition table >>> where the BIOS expects it, but there's no immediately obvious reason >>> why they must regard that instance as their GEOM metadata. GPT puts >>> a second copy in the provider's last block, and AFAICT it could just >>> as well use _that_ instance -- or even a differently-formatted block >>> that included the same data -- as the primary. MBR could do likewise. >> I have deja-vu, that I answered this. Please, read standard. GPT >> _must_ be placed twice -- at first and last sectors (really, more >> than one sectors). By standard. Secondary copy must be at end of >> disk. Period. > Then, "by standard" GPT cannot coexist with GLABEL. Such setup should be > disallowed, or at least big nasty message that you have just shoot=20 > yourself in the leg should be output. (period) Ok, maybe adding check to geom_part, that it is used on rank-1 provider (whole disk) is not so bad idea. But it then raise question how to install FreeBSD on software mirror, what is useful. But could bite you sometimes... Hm... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sat Oct 8 08:57:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CAC210657C1; Sat, 8 Oct 2011 08:57:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DDE358FC15; Sat, 8 Oct 2011 08:57:26 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DD71D4AC32; Sat, 8 Oct 2011 12:57:25 +0400 (MSD) Date: Sat, 8 Oct 2011 12:57:14 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1427093959.20111008125714@serebryakov.spb.ru> To: lev@freebsd.org In-Reply-To: <4e901d55.j0M8m+Tba3WC+Wrp%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1646032486.20111007112802@serebryakov.spb.ru> <4e901d55.j0M8m+Tba3WC+Wrp%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 08:57:27 -0000 Hello, Lev. You wrote 8 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 13:52:21: >> GPT must have backup copy in last sector by standard ... > In that case, shouldn't it refuse to install on any provider that is > not in fact a disk, so as not to create configurations that cannot > work properly? Installation of FreeBSD on software mirror?.. >> MBR doesn;t have any additional metadata. How adding one will help it? > It would add robustness, for cases like the one that started > this thread. If MBR put a GEOM metadata block at the end of > its provider, it would fix the tasting race when an MBR is > installed on a glabelled (or gmirrored) drive. And how it should work with MBR created by non-FreeBSD tools? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sat Oct 8 09:05:14 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA7A9106566C; Sat, 8 Oct 2011 09:05:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 674618FC16; Sat, 8 Oct 2011 09:05:14 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 1B1424AC1C; Sat, 8 Oct 2011 13:05:13 +0400 (MSD) Date: Sat, 8 Oct 2011 13:05:01 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <751863274.20111008130501@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org, freebsd-current@freebsd.org, Daniel Kalchev Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 09:05:14 -0000 Hello, Ivan. You wrote 8 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 0:23:1= 4: > If you think this should be explicitely handled, please file a PR > which requests the modification of gpart so that it detects that a GPT > is being created in anything other than a raw drive, and warns the > user. It should be mentioned in documentation, at least. But how people will create bootable gmirror installation in such case? Make (many) mirrors from parts? I don't like this idea... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sat Oct 8 19:57:01 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666CE106566B; Sat, 8 Oct 2011 19:57:01 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id DDCCB8FC08; Sat, 8 Oct 2011 19:57:00 +0000 (UTC) Received: from digsys236-136.pip.digsys.bg (digsys236-136.pip.digsys.bg [193.68.136.236]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p98Jupfu064363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Oct 2011 22:56:56 +0300 (EEST) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Daniel Kalchev X-Priority: 3 (Normal) In-Reply-To: <751863274.20111008130501@serebryakov.spb.ru> Date: Sat, 8 Oct 2011 22:56:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8E10D03C-FD4E-42BB-846E-F4E657452C7D@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> <751863274.20111008130501@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-current@FreeBSD.org, Ivan Voras , freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 19:57:01 -0000 On Oct 8, 2011, at 12:05 , Lev Serebryakov wrote: > Hello, Ivan. > You wrote 8 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., = 0:23:14: >=20 >> If you think this should be explicitely handled, please file a PR >> which requests the modification of gpart so that it detects that a = GPT >> is being created in anything other than a raw drive, and warns the >> user. > It should be mentioned in documentation, at least. > But how people will create bootable gmirror installation in such > case? Make (many) mirrors from parts? I don't like this idea... Good example of what I would call laziness -- other would call it = hacking I guess. Either way, the solution we have now is permitting some = exotic setups, but is fragile and is not consistent. Most of the useful = features are actually side effects of the hack. If it should remain this way, a warning in the documentation and at = runtime is very helpful. Daniel=