From owner-freebsd-geom@FreeBSD.ORG Mon Mar 22 00:44:16 2010 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 7D23B106566B; Mon, 22 Mar 2010 00:44:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54AB68FC1E; Mon, 22 Mar 2010 00:44:16 +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 o2M0iG9J051335; Mon, 22 Mar 2010 00:44:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2M0iGGu051331; Mon, 22 Mar 2010 00:44:16 GMT (envelope-from linimon) Date: Mon, 22 Mar 2010 00:44:16 GMT Message-Id: <201003220044.o2M0iGGu051331@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/144943: [geom] gconcat(8) randomly "loses" all knowledge of JBOD set 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, 22 Mar 2010 00:44:16 -0000 Old Synopsis: gconcat randomly "loses" all knowledge of JBOD set New Synopsis: [geom] gconcat(8) randomly "loses" all knowledge of JBOD set Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 22 00:43:45 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144943 From owner-freebsd-geom@FreeBSD.ORG Mon Mar 22 06:10:04 2010 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 23C381065675 for ; Mon, 22 Mar 2010 06:10:04 +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 E8A5F8FC1D for ; Mon, 22 Mar 2010 06:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2M6A3wd027348 for ; Mon, 22 Mar 2010 06:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2M6A3w8027345; Mon, 22 Mar 2010 06:10:03 GMT (envelope-from gnats) Date: Mon, 22 Mar 2010 06:10:03 GMT Message-Id: <201003220610.o2M6A3w8027345@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Alexander Motin Cc: Subject: Re: bin/144943: [geom] gconcat(8) randomly "loses" all knowledge of JBOD set X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Motin List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 06:10:04 -0000 The following reply was made to PR bin/144943; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, freebspr@sensation.net.au Cc: Subject: Re: bin/144943: [geom] gconcat(8) randomly "loses" all knowledge of JBOD set Date: Mon, 22 Mar 2010 08:09:24 +0200 `gconcat create... ` creates array on-flight. It doesn't saves any meta-data to the components, so reboot will make system to forget everything. To make arrays restore after reboot you should use `gconcat label ...`. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Mon Mar 22 11:07:03 2010 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 24516106567D for ; Mon, 22 Mar 2010 11:07:03 +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 083AC8FC2F for ; Mon, 22 Mar 2010 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2MB72Qd015037 for ; Mon, 22 Mar 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2MB727f015035 for freebsd-geom@FreeBSD.org; Mon, 22 Mar 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Mar 2010 11:07:02 GMT Message-Id: <201003221107.o2MB727f015035@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, 22 Mar 2010 11:07:03 -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 bin/144943 geom [geom] gconcat(8) randomly "loses" all knowledge of JB o kern/144905 geom [geom][gpart] panic in gpart_ctlreq when unplugging ca o kern/144732 geom [geom] [patch] geom_cache erroneously decodes its on-d o bin/144521 geom geom(1) tool parsing non-subclass command broken o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool f kern/142365 geom [geom] FreeBSD RAID1 (gmirror) is much slower than Lin o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/139847 geom [geom_mbr] [patch] load/unload causes system to hang o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used 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 f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile 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 p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/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/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 53 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 22 18:41:42 2010 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 D18B8106564A; Mon, 22 Mar 2010 18:41:42 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7858FC18; Mon, 22 Mar 2010 18:41:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA00928; Mon, 22 Mar 2010 20:41:39 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4BA7B9E3.3080003@freebsd.org> Date: Mon, 22 Mar 2010 20:41:39 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , Poul-Henning Kamp Subject: geom_vfs: disallow multiple readonly mounts of a device 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, 22 Mar 2010 18:41:42 -0000 Currently FreeBSD allows multiple readonly mounts of the same device. This feature seems to be introduced along with GEOM. Before that, only one mount of a device was allowed, whether readonly or not. Other (major) BSDs still work that way. Unfortunately, the feature has never really worked correctly because of some architectural/design issues in our buffer cache layer/interface. Multiple shared mounts are allowed to happen but later on, during filesystem access or at unmount time, a system would crash. Because of this, I propose to disable shared mounting feature for time being. In my opinion it is very unlikely that anybody depends on this feature now, but nullfs can be used as its replacement. In fact, it could be even more efficient if the same files are access via different mount points. The proposed patch is a greatly reduced version of a patch by Pawel Jakub Dawidek: http://people.freebsd.org/~pjd/patches/mro_mount.patch Pawel's patch, in fact, fixes the shared mounting feature. Unfortunately, at least one filesystem (FFS) is quite intrusive at what it does with a device vnode (or rather its bufobj) when it attempts mounting. So, in some edge cases (synthetic or accidental) a system may still crash even with the Pawel's patch. So, I think that it should not be committed until after all filesystems in the tree are made to play nice. Otherwise, I like it. As an afterthought, perhaps it is the Pawel's patch that we should actually use with one change - add a sysctl that enables/disables shared mounts and make them disabled by default. Thank you very for the feedback. --- a/sys/geom/geom_vfs.c +++ b/sys/geom/geom_vfs.c @@ -161,6 +161,10 @@ g_vfs_open g_topology_assert(); *cpp = NULL; + bo = &vp->v_bufobj; + if (bo->bo_private != vp) + return (EBUSY); + pp = g_dev_getprovider(vp->v_rdev); if (pp == NULL) return (ENOENT); @@ -176,6 +180,6 @@ g_vfs_open vnode_create_vobject(vp, pp->mediasize, curthread); VFS_UNLOCK_GIANT(vfslocked); *cpp = cp; - bo = &vp->v_bufobj; + cp->private = vp; bo->bo_ops = g_vfs_bufops; bo->bo_private = cp; @@ -196,5 +200,6 @@ g_vfs_close gp = cp->geom; bo = gp->softc; bufobj_invalbuf(bo, V_SAVE, 0, 0); + bo->bo_private = cp->private; g_wither_geom_close(gp, ENXIO); } -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Mar 22 19:03:03 2010 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 DE5271065677; Mon, 22 Mar 2010 19:03:03 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B4FDC8FC08; Mon, 22 Mar 2010 19:03:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2MJ33iC036770; Mon, 22 Mar 2010 19:03:03 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2MJ33lC036766; Mon, 22 Mar 2010 19:03:03 GMT (envelope-from brucec) Date: Mon, 22 Mar 2010 19:03:03 GMT Message-Id: <201003221903.o2MJ33lC036766@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries 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, 22 Mar 2010 19:03:04 -0000 Synopsis: [geom] panic when accessing GPT disk with a large number of entries Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 22 19:02:27 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144962 From owner-freebsd-geom@FreeBSD.ORG Tue Mar 23 00:10:05 2010 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 21C08106566C for ; Tue, 23 Mar 2010 00:10:05 +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 10C2A8FC17 for ; Tue, 23 Mar 2010 00:10:05 +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 o2N0A4R8093401 for ; Tue, 23 Mar 2010 00:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2N0A4P7093400; Tue, 23 Mar 2010 00:10:04 GMT (envelope-from gnats) Date: Tue, 23 Mar 2010 00:10:04 GMT Message-Id: <201003230010.o2N0A4P7093400@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Alexander Best Cc: Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 00:10:05 -0000 The following reply was made to PR kern/144962; it has been noted by GNATS. From: Alexander Best To: Cc: Bruce Cran Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries Date: Tue, 23 Mar 2010 01:09:01 +0100 (CET) tried this too under HEAD (r205390): `gpart create -s gpt -n 1000000 /dev/da0` gave me "gpart: provider: No space left on device" so i did `gpart create -s gpt -n 1000000 /dev/da0` instead which worked. reattaching the device caused no problem. when i tried to create a label with `glabel label usb da0` i got: GEOM: da0: the secondary GPT table is corrupt or invalid. GEOM: da0: using the primary only -- recovery suggested. GEOM: da0: the secondary GPT table is corrupt or invalid. GEOM: da0: using the primary only -- recovery suggested. GEOM: label/usb: the secondary GPT table is corrupt or invalid. GEOM: label/usb: using the primary only -- recovery suggested. seems -n 1000000 is not enough to fill up kernel virtual memory in my case. -- Alexander Best From owner-freebsd-geom@FreeBSD.ORG Tue Mar 23 00:20:08 2010 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 42FB81065672 for ; Tue, 23 Mar 2010 00:20:08 +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 17DEA8FC0A for ; Tue, 23 Mar 2010 00:20:08 +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 o2N0K7c5002721 for ; Tue, 23 Mar 2010 00:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2N0K7qO002720; Tue, 23 Mar 2010 00:20:07 GMT (envelope-from gnats) Date: Tue, 23 Mar 2010 00:20:07 GMT Message-Id: <201003230020.o2N0K7qO002720@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Alexander Best Cc: Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 00:20:08 -0000 The following reply was made to PR kern/144962; it has been noted by GNATS. From: Alexander Best To: Cc: Bruce Cran Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries Date: Tue, 23 Mar 2010 01:19:20 +0100 (CET) sorry. the command i used was `gpart create -s gpt -n 100000 /dev/da0`. -- Alexander Best From owner-freebsd-geom@FreeBSD.ORG Tue Mar 23 07:50:04 2010 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 65600106566B for ; Tue, 23 Mar 2010 07:50:04 +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 3BE4F8FC0C for ; Tue, 23 Mar 2010 07:50:04 +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 o2N7o3kZ019629 for ; Tue, 23 Mar 2010 07:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2N7o3Kh019617; Tue, 23 Mar 2010 07:50:03 GMT (envelope-from gnats) Date: Tue, 23 Mar 2010 07:50:03 GMT Message-Id: <201003230750.o2N7o3Kh019617@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 07:50:04 -0000 The following reply was made to PR kern/144962; it has been noted by GNATS. From: Bruce Cran To: Alexander Best Cc: bug-followup@FreeBSD.org, Bruce Cran Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries Date: Tue, 23 Mar 2010 07:46:22 +0000 I've just recreated the panic - it seems 10,000,000 entries are required to fill virtual memory, not 1,000,000. It takes a very long time for gpart to create them, but on reboot after the disk is detected the system will wait for a couple of minutes before panicing. -- Bruce Cran From owner-freebsd-geom@FreeBSD.ORG Tue Mar 23 14:16:05 2010 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 BF00B106566B; Tue, 23 Mar 2010 14:16:05 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 993DF8FC17; Tue, 23 Mar 2010 14:16:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA19353; Tue, 23 Mar 2010 16:16:01 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4BA8CD21.3000803@freebsd.org> Date: Tue, 23 Mar 2010 16:16:01 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , Bruce Evans Subject: on st_blksize value 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, 23 Mar 2010 14:16:05 -0000 First, what I am proposing: --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -790,11 +790,11 @@ vn_stat(vp, sb, active_cred, file_cred, td) * to file" * Default to PAGE_SIZE after much discussion. * XXX: min(PAGE_SIZE, vp->v_bufobj.bo_bsize) may be more correct. */ - sb->st_blksize = PAGE_SIZE; + sb->st_blksize = max(PAGE_SIZE, vap->va_blocksize); sb->st_flags = vap->va_flags; if (priv_check(td, PRIV_VFS_GENERATION)) sb->st_gen = 0; else Explanation: 1. IMO it is not nice that we totally ignore va_blocksize value that can be set by a filesystem. This takes away flexibility. That va_blocksize value might really turn out to be optimal given the filesystem implementation. 2. As currently st_blksize is always PAGE_SIZE, it is playing safe to not use any smaller value. For some case this might not be optimal (which I personally doubt), but at least nothing should get broken. One practical benefit can be with ZFS: if a filesystem has recordsize > PAGE_SIZE (e.g. default 128K) and it has checksums or compression enabled, then (over-)writing in blocks smaller than recordsize would require reading of a whole record first. And some applications do use st_blksize as a hint (just for the record: some other use f_iosize instead, and yet some use a hardcoded value). BTW, some torrent-like applications can serve as a good example of applications that overwrite chunks of existing files. Additionally, here's a little bit of history that explains the PAGE_SIZE ("much discussion") comment in vn_stat. It seems that the comment may be misleading nowadays. It was introduced in r89784 and at that time it applied only to the case of non-VREG and non-vn_isdisk vnodes. Then, almost 3 years later, in revision 136966 code for VREG vnodes and vn_isdisk vnodes was dropped, the XXX comment was introduced, and we ended up with the current state of matters. BTW, I am not sure about the XXX comment either. Using bo_bsize may be a nice shortcut, but it would also take away some flexibility. Filesystems can already set bo_bsize and va_blocksize to the same value, but there could be special cases where they not need be the same. Thanks a lot for opinions and suggestions! P.S. Yes, I have read the following interesting thread _completely_: http://lists.freebsd.org/pipermail/freebsd-fs/2007-May/003155.html And this one too: http://freebsd.monkey.org/freebsd-fs/200810/msg00059.html Unfortunately, the discussions didn't result in any action. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Tue Mar 23 19:20:03 2010 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 8C110106566B for ; Tue, 23 Mar 2010 19:20:03 +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 7A8628FC0A for ; Tue, 23 Mar 2010 19:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2NJK3G7020124 for ; Tue, 23 Mar 2010 19:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2NJK3CS020123; Tue, 23 Mar 2010 19:20:03 GMT (envelope-from gnats) Date: Tue, 23 Mar 2010 19:20:03 GMT Message-Id: <201003231920.o2NJK3CS020123@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Christopher Key Cc: Subject: Re: kern/113957: [gmirror] gmirror is intermittently reporting a degraded mirror array upon reboot. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christopher Key List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 19:20:03 -0000 The following reply was made to PR kern/113957; it has been noted by GNATS. From: Christopher Key To: bug-followup@FreeBSD.org, ayochum@pair.com Cc: Subject: Re: kern/113957: [gmirror] gmirror is intermittently reporting a degraded mirror array upon reboot. Date: Tue, 23 Mar 2010 19:17:59 +0000 I am suffering very similar symptoms. I have two mirrors, gm0 (ad4+ad6) and gm1 (ad8+ad10). On every restart, gm1 gets rebuilt, but never gm0. The problem appears to stem from gm1 not being closed cleanly at shutdown. I consistently see: GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed GEOM_MIRROR: Device gm0 destroyed. but never a corresponding message for gm1. I think that this is a problem with reference counts, and that something is keeping gm1 open. Immediately before shutdown, I have (trimmed): # gmirror list Geom name: gm0 State: COMPLETE Components: 2 Providers: 1. Name: mirror/gm0 Mode: r5w5e9 Geom name: gm1 State: COMPLETE Components: 2 Balance: round-robin Providers: 1. Name: mirror/gm1 Mode: r3w3e4 gm0 has 6 GPT partitions. Four have mounted UFS filesystems one is used for swap and one is a boot partition. I assume that the mounted partitions contribute r1w1e2 to the ref count, and the swap r1w1e1, leading to r5w5e9. When shutting down with kern.geom.mirror.debug=2, I get: GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w-1e-2 GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w-1e-2 GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w-1e-2 GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w-1e-2 GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w-1e-1 which appears to confirm this. After this, the refcount becomes r0w0e0, and the devices gets destroyed. gm1 has 3 MBR slices. Two have mounted UFS filesystems, and the third slice is used for a ZFS pool. Here, I assume that the mounted partitions contribute r1w1e1 to the ref count, and the partition used by ZFS contributes r1w1e2. I'm not sure why UFS mounted from a GPT partition should contribute r1w1e2, but mounted from a MBR slice should contribute r1w1e1, but testing with memory disks does appear to confirm that this is the case. When shutting down with kern.geom.mirror.debug=2, I get: GEOM_MIRROR[2]: Access request for mirror/gm1: r-1w-1e-1 GEOM_MIRROR[2]: Access request for mirror/gm1: r-1w-1e-1 This seems to suggest that the problem is ZFS not releasing gm1 at shutdown. Testing with memory disk based mirrors appears to show the same result, with ZFS not releasing the mirror, resulting in the mirror not being cleanly destroyed. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 25 13:26:51 2010 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 4F1441065673 for ; Thu, 25 Mar 2010 13:26:51 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id AC4DA8FC33 for ; Thu, 25 Mar 2010 13:26:50 +0000 (UTC) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 2701C8B141D for ; Thu, 25 Mar 2010 14:15:12 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=-0.126, TW_EV=0.077, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id peMkjMQsgS8x for ; Thu, 25 Mar 2010 14:15:07 +0100 (CET) Received: from [192.168.100.30] (p54B0E90D.dip.t-dialin.net [84.176.233.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 424F38B141C for ; Thu, 25 Mar 2010 14:15:07 +0100 (CET) Message-ID: <4BAB61CE.9070101@executive-computing.de> Date: Thu, 25 Mar 2010 14:14:54 +0100 From: Marco Steinbach User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: 7.2/i386: newfs: wtfs: 512 bytes at sector 1917873520: No such file or directory 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, 25 Mar 2010 13:26:51 -0000 Hi, I'm trying to re-newfs a formerly used partition on a gmirror since I need more i-nodes. Maybe someone else has an idea about the cause of this message, since all sizes and offsets look correct to me. There is no vital data left on the machine, so I'm open to experimentation. I'm working remotely, but can get on site if neccessary. # uname -a FreeBSD [...] 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Dec 29 05:13:44 CET 2009 [...] i386 # mount /dev/mirror/fs01s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/mirror/fs01s1d on /u (ufs, local, noatime, soft-updates) # umount /dev/mirror/fs01s1d # newfs /dev/mirror/fs01s1d newfs: wtfs: 512 bytes at sector 1917873520: No such file or directory newfs fails, the former filesystem is still intact, and the logs I had a look at (including console.log) were unchanged. # disklabel /dev/mirror/fs01s1 # /dev/mirror/fs01s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 31457280 0 4.2BSD 2048 16384 28552 b: 4194304 31457280 swap c: 1953525105 0 unused 0 0 # "raw" part, don't edit d: 1917873521 35651584 4.2BSD 2048 16384 49408 # gmirror list Geom name: fs01 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NOAUTOSYNC GenID: 0 SyncID: 3 ID: 1234616142 Providers: 1. Name: mirror/fs01 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r3w3e4 Consumers: 1. Name: ad4 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY, HARDCODED GenID: 0 SyncID: 3 ID: 2392863806 2. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY, HARDCODED GenID: 0 SyncID: 3 ID: 3751075103 # dmesg | grep ^ad ad4: 953869MB at ata2-master SATA150 ad6: 953869MB at ata3-master SATA150 # gmirror dump /dev/ad4 Metadata on /dev/ad4: magic: GEOM::MIRROR version: 4 name: fs01 mid: 1234616142 did: 2392863806 all: 2 genid: 0 syncid: 3 priority: 0 slice: 4096 balance: load mediasize: 1000204885504 sectorsize: 512 syncoffset: 0 mflags: NOAUTOSYNC dflags: DIRTY hcprovider: ad4 provsize: 1000204886016 MD5 hash: ed2072f20157b354117e27713062a550 # gmirror dump /dev/ad5 Can't read metadata from /dev/ad5: No such file or directory. gmirror: Not fully done. fs01# gmirror dump /dev/ad6 Metadata on /dev/ad6: magic: GEOM::MIRROR version: 4 name: fs01 mid: 1234616142 did: 3751075103 all: 2 genid: 0 syncid: 3 priority: 0 slice: 4096 balance: load mediasize: 1000204885504 sectorsize: 512 syncoffset: 0 mflags: NOAUTOSYNC dflags: DIRTY hcprovider: ad6 provsize: 1000204886016 MD5 hash: 4ad26f391807cb8afcc632b18fe17bf4 I've retried with kern.geom.debugflags=17, here's what /var/log/messages says: Mar 25 13:38:41 [...] kernel: g_post_event_x(0xc07b1670, 0xc4454500, 2, 0) Mar 25 13:38:41 [...] kernel: ref 0xc4454500 Mar 25 13:38:41 [...] kernel: g_slice_spoiled(0xc46a48c0/mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4685880(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_orphan_provider(0xc4685500(ufsid/4b4a0d33d28fa442), 6) Mar 25 13:38:41 [...] kernel: g_orphan_register(ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_dev_orphan(0xc46a4a80(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4a80) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4a80) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685300(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a48c0) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a48c0) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685880(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_post_event_x(0xc07b1470, 0xc4454500, 2, 0) Mar 25 13:38:41 [...] kernel: ref 0xc4454500 Mar 25 13:38:41 [...] kernel: g_mirror_taste(MIRROR, mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a44c0) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a44c0) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685380(mirror:taste)) Mar 25 13:38:41 [...] kernel: g_part_taste(PART,mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4684900(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: bsd_taste(BSD,mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_slice_spoiled(0xc46a4640/mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4685580(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_label_taste(LABEL, mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_slice_config(mirror/[...]s1d, 0, 1) Mar 25 13:38:41 [...] kernel: g_post_event_x(0xc07b1470, 0xc4684500, 2, 0) Mar 25 13:38:41 [...] kernel: ref 0xc4684500 Mar 25 13:38:41 [...] kernel: ref 0xc4684d00 Mar 25 13:38:41 [...] kernel: g_detach(0xc46a45c0) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a45c0) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685100(label:taste)) Mar 25 13:38:41 [...] kernel: mbr_taste(MBR,mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_slice_spoiled(0xc46a46c0/mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4684e80(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_mbrext_taste(MBREXT,mirror/[...]s1d) Mar 25 13:38:41 [...] kernel: g_mirror_taste(MIRROR, ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4680) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4680) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc447c500(mirror:taste)) Mar 25 13:38:41 [...] kernel: dev_taste(DEV,ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_part_taste(PART,ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4684380(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: bsd_taste(BSD,ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_slice_spoiled(0xc46a4c40/ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4685000(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_label_taste(LABEL, ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: mbr_taste(MBR,ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_slice_spoiled(0xc46a5240/ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_wither_geom(0xc4684880(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_mbrext_taste(MBREXT,ufsid/4b4a0d33d28fa442) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4780) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4780) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4684380(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4800) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4800) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4684900(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4c40) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4c40) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685000(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a4640) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a4640) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4685580(mirror/[...]s1d)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a5240) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a5240) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4684880(ufsid/4b4a0d33d28fa442)) Mar 25 13:38:41 [...] kernel: g_detach(0xc46a46c0) Mar 25 13:38:41 [...] kernel: g_destroy_consumer(0xc46a46c0) Mar 25 13:38:41 [...] kernel: g_destroy_geom(0xc4684e80(mirror/[...]s1d)) MfG CoCo From owner-freebsd-geom@FreeBSD.ORG Thu Mar 25 14:29:40 2010 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 3A0581065673 for ; Thu, 25 Mar 2010 14:29:40 +0000 (UTC) (envelope-from dbehterev@gmail.com) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by mx1.freebsd.org (Postfix) with ESMTP id 12AF88FC16 for ; Thu, 25 Mar 2010 14:29:39 +0000 (UTC) Received: by pzk37 with SMTP id 37so1794396pzk.7 for ; Thu, 25 Mar 2010 07:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=FiSHQsuKKy7rJf7Q2wrka9diGOUjsMYVQ2uznEnIZ+M=; b=mU0v6MkrbJFevaoy8/a7gybw50XhEYAAkVpB0RBqDqiOFKb5qEYd6lC45eVWCfqZJg q7gX1qWoiM2h7b9iG4nYotwp5WPPM5sSQhv8B7xrrAUB5GgOoebftlXKnIXyKoJErMqC G76NgG1SOUIhb0KRGFHUJY7oOkQa8e2TmXCyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ZWPDiSyjsmMWBaCyNszpQZITTwveA5o3gfJQ1E4hVc0mzRDABDnYqyU7tdeI5WBeqQ wo1I/KNYobv5AeFCi9Zj4Qnj/01LGVTqjfX7BLbQCCaPfX3O0HmtVvmFCOMH7dERXoF4 xsQipvVHV4DUnP7HuOrgClgcwd8vPsLVR1gOY= MIME-Version: 1.0 Received: by 10.140.251.3 with SMTP id y3mr6612496rvh.227.1269525837088; Thu, 25 Mar 2010 07:03:57 -0700 (PDT) From: =?KOI8-R?B?5M3J1NLJyiDixcjUxdLF1w==?= Date: Thu, 25 Mar 2010 17:03:37 +0300 Message-ID: <7aaa60421003250703hf24d3c1icae624982210c094@mail.gmail.com> To: freebsd-geom@freebsd.org X-Mailman-Approved-At: Thu, 25 Mar 2010 16:50:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Create GMIRROR only one slice 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, 25 Mar 2010 14:29:40 -0000 Hello all! I have problem with creating GMIRROR on select slice. So, I have two slice: ls /dev | grep ad4 ad4 ad4s1 ad4s1a ad4s1b ad4s1c ad4s2 ad4s2p1 fdisk /dev/ad4 ... The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 29350692 (14331 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 29350755, size 595786590 (290911 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: The data for partition 4 is: On first slice I created ufs slice and on second - ZFS pool (I build it with glabel): mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) tank on /tank (zfs, local) tank/usr on /usr (zfs, local) ... tank/var on /var (zfs, local) glabel list Geom name: ad4s2p1 ... I want GMIRROR'ing /dev/ad4s1: gmirror label -v -b round-robin gm0 /dev/ad4s1 but I get error "Operation not permitted" (although I set sysctl kern.geom.debugflags=16). MY OS: FreeBSD 7.3 Stable. What should I do to do this? Thanks all. From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 13:17:44 2010 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 6F585106564A; Fri, 26 Mar 2010 13:17:44 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 72A788FC19; Fri, 26 Mar 2010 13:17:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA01998; Fri, 26 Mar 2010 15:17:42 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4BACB3F5.7010905@freebsd.org> Date: Fri, 26 Mar 2010 15:17:41 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org References: <4BA0A660.3000902@freebsd.org> In-Reply-To: <4BA0A660.3000902@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 13:17:44 -0000 Will an offer of a beer help reviewing this change? :-) on 17/03/2010 11:52 Andriy Gapon said the following: > I've given a fresh look to the issue of g_vfs_open and bread(devvp, ...) in > filesystem code. This time I hope to present my reasoning more clearly than I did > in my previous attempts. > For this reason I am omitting historical references and dramatic > examples/demonstrations but they are still available upon request (and in archives). > I hope that my shortened notation in references to the code and data structures > will not be confusing. > > bread() and the API family it belongs to is an interface to buffer cache system. > Buffer cache system can be roughly divided into two parts: cache part and I/O path > part. > I think that it is understood that both parts must have the same notion of a block > size when translating a block number to a byte offset. (If this point is not > clear, I can follow up with another essay). > > In the case of cache code the translation is explicit and simple: > A) offset = blkno * bo_bsize > > In the case of I/O code the translation is not that straightforward, because it > can be altered/overridden by bop_strategy which can in turn hook vop_strategy, etc. > > Let's consider a simple case of a filesystem that: > a) connects to a geom provider via g_vfs_open > b) doesn't modify anything in devvp->v_bufobj (in particular bo_ops and bo_bsize) > c) uses bread(devvp) (e.g. to access an equivalent of superblock, etc) > > Short overview of geom_vfs glue: > 1) g_vfs_open sets devvp->v_bufobj.bo_ops to g_vfs_bufops, where bop_strategy is > g_vfs_strategy > 2) bo_bsize is set to pp->sectorsize > 3) g_vfs_strategy doesn't perform any block-to-offset translation of its own, it > expects b_iooffset to be correctly set and passes its value to bio_offset > > When a filesystem issues bread(devvp) the following happens in the I/O path: > I) bread() calls breadn() > II) in breadn(): bp->b_iooffset = dbtob(bp->b_blkno), that is b_iooffset is set to > blkno * DEV_BSIZE (where DEV_BSIZE is 512) > III) breadn() then calls bstrategy() which is a simple wrapper around BO_STRATEGY > IV) g_vfs_strategy gets called and, as described in (3) above, it simply passes on > b_iooffset value to bio_offset > V) thus, a block size used for I/O operation is 512 (DEV_BSIZE) > VI) on the other hand, as stated in (A) above, block size used in caching code is > bo_bsize > > Thus, if bo_bsize != DEV_BSIZE, or alternatively said, pp->sectorsize != 512, we > have a trouble of data getting cached with incorrect offsets. > > Additionally, from (V) above we must conclude that a filesystem must specify block > numbers in DEV_BSIZE units to bread(devvp, blkno, ...) if the conditions (a), (b), > (c) are met. In fact, all such filesystems already do that, because otherwise > they would read incorrect data from the media. > > So, the problem is only with the caching of the data. > As such, this issue has little practical effects, because only a small number of > reads is done via devvp and only for sufficiently small chunks of data (I hope). > fs/udf used to be greatly affected by this issue when it was reading directory > nodes via devvp, but that was in the past (prior to 189082). > > Still I think that we should fix this issue for general code correctness/quality > reasons. And also to avoid possible future bugs. > > As demonstrated by (V) and (VI) above, obvious and easiest fix is to (always) set > bo_bsize to DEV_BSIZE in g_vfs_open(): > --- a/sys/geom/geom_vfs.c > +++ b/sys/geom/geom_vfs.c > @@ -179,7 +179,7 @@ g_vfs_open(struct vnode *vp, struct g_consumer **cpp, const > char *fsname, int wr > bo = &vp->v_bufobj; > bo->bo_ops = g_vfs_bufops; > bo->bo_private = cp; > - bo->bo_bsize = pp->sectorsize; > + bo->bo_bsize = DEV_BSIZE; > gp->softc = bo; > > return (error); > > I tested this change with ufs, udf and cd9660 and haven't observed any regressions. > > P.S. > There might something to changing bread(devvp) convention, so that blkno is > expected in sectorsize units. But setting bo_bsize to sectorsize is only a tiny > portion of what needs to be changed to make it actually work. > -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 15:44:43 2010 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 DFB1E1065675; Fri, 26 Mar 2010 15:44:43 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id B01AC8FC13; Fri, 26 Mar 2010 15:44:43 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id o2QFSAuI037251; Fri, 26 Mar 2010 08:28:10 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201003261528.o2QFSAuI037251@chez.mckusick.com> To: Andriy Gapon In-reply-to: <4BACB3F5.7010905@freebsd.org> Date: Fri, 26 Mar 2010 08:28:10 -0700 From: Kirk McKusick Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 15:44:44 -0000 I have reviewed your change and I believe that your analysis is correct. I am in agreement with your making the change. As disk sector sizes will be growing in the near future, it would be desirable to get away from having DEV_BSIZE hard-coded. But as you note, that is a far bigger change than this one. Kirk McKusick From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 16:28:58 2010 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 32ABF1065679 for ; Fri, 26 Mar 2010 16:28:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id D4BEC8FC1A for ; Fri, 26 Mar 2010 16:28:57 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id xo6G1d00A1c6gX856sFigL; Fri, 26 Mar 2010 16:15:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.westchester.pa.mail.comcast.net with comcast id xsK31d0033S48mS3jsK3N3; Fri, 26 Mar 2010 16:19:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F35ED9B436; Fri, 26 Mar 2010 09:15:39 -0700 (PDT) Date: Fri, 26 Mar 2010 09:15:39 -0700 From: Jeremy Chadwick To: Kirk McKusick Message-ID: <20100326161539.GA10618@icarus.home.lan> References: <4BACB3F5.7010905@freebsd.org> <201003261528.o2QFSAuI037251@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003261528.o2QFSAuI037251@chez.mckusick.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Andriy Gapon , freebsd-geom@freebsd.org Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 16:28:58 -0000 On Fri, Mar 26, 2010 at 08:28:10AM -0700, Kirk McKusick wrote: > I have reviewed your change and I believe that your analysis is > correct. I am in agreement with your making the change. > > As disk sector sizes will be growing in the near future, it would > be desirable to get away from having DEV_BSIZE hard-coded. But as > you note, that is a far bigger change than this one. I should note that they already have grown: Western Digital, as of a few months ago, began shipping drives that use 4KByte sectors. They're known as the "EARS" drives, due to their model string ending with "EARS": WD20EARS: http://www.wdc.com/en/products/Products.asp?DriveID=773 WD15EARS: http://www.wdc.com/en/products/products.asp?driveid=772 WD10EARS: http://www.wdc.com/en/products/products.asp?driveid=763 (I should warn folks these are Caviar Green drives, which may suffer from excessive Load Cycles (parking/unparking actuator arm). I don't have one of these drives so I can't validate if the issue happens on this model or not) A discussion and an including an incredibly cheesy video review are below. The video review does discuss the 4KB sector size, in addition to jumpers that revert the drive to using 512-byte sectors for older OSes such as Windows XP -- and presumably FreeBSD. http://www.tomshardware.com/reviews/wd-4k-sector,2554.html http://www.youtube.com/watch?v=QeFj2QTaA3Y -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 18:21:22 2010 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 7D2C5106564A; Fri, 26 Mar 2010 18:21:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0BCB48FC17; Fri, 26 Mar 2010 18:21:22 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8009:ab55:dc54:fb7f] (unknown [IPv6:2001:7b8:3a7:0:8009:ab55:dc54:fb7f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 50D8C5C59; Fri, 26 Mar 2010 19:21:20 +0100 (CET) Message-ID: <4BACFB20.6070601@andric.com> Date: Fri, 26 Mar 2010 19:21:20 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100311 Lanikai/3.1b2pre MIME-Version: 1.0 To: Jeremy Chadwick References: <4BACB3F5.7010905@freebsd.org> <201003261528.o2QFSAuI037251@chez.mckusick.com> <20100326161539.GA10618@icarus.home.lan> In-Reply-To: <20100326161539.GA10618@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , freebsd-fs@freebsd.org, Andriy Gapon , freebsd-geom@freebsd.org Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 18:21:22 -0000 On 2010-03-26 17:15, Jeremy Chadwick wrote: > I should note that they already have grown: Western Digital, as of a few > months ago, began shipping drives that use 4KByte sectors. ... > A discussion and an including an incredibly cheesy video review are > below. The video review does discuss the 4KB sector size, in addition > to jumpers that revert the drive to using 512-byte sectors for older > OSes such as Windows XP -- and presumably FreeBSD. Please note these drives *always* expose 512-byte sectors to any OS, at least for now. The jumper you refer to is only a hack to force sector 63 (the usual starting position for the first partition) to be aligned on a 4096-byte boundary. If you would remove it after partitioning, all sectors would shift up one sector, and there would be trouble. :) From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 18:21:42 2010 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 91576106568A for ; Fri, 26 Mar 2010 18:21:42 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f183.google.com (mail-iw0-f183.google.com [209.85.223.183]) by mx1.freebsd.org (Postfix) with ESMTP id 54BA08FC21 for ; Fri, 26 Mar 2010 18:21:41 +0000 (UTC) Received: by iwn13 with SMTP id 13so6899635iwn.14 for ; Fri, 26 Mar 2010 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=npSCHa0URS1HJZGkQAB3UtgbNSH5NfpEWdqor/Mw9V0=; b=lJHJVw0G94g8VS4szM8XttDGm/C7ErEV54JfYEtmBbOjCRjcooRpiVEHO1IScjb4EM 2jTU9K7ttEStTprPs99ce1dQ9V9lrDd3sZH7ABT++B7x2o8mdUBx0WKdoTLquJ0NiVT8 GS+CVy5mL8QuchIEC5YJ8/0EcueTG0oCGGXqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o1oWkEfLBQILx6PIOK+JQoCRzJcR2izxE4PWC+VavlS0j4SHjM1z34vJAzSTnn2Djz kL4AzU3yDkZnVrapOHGceeKoYaXsQsHN+fBBuoUGqQGiRrghmoGZElH7RLW+c/2aVD2t y7whKDn71eGWy32PuLy68MudOMWJhUU5fnXu8= MIME-Version: 1.0 Received: by 10.231.17.199 with HTTP; Fri, 26 Mar 2010 11:21:41 -0700 (PDT) In-Reply-To: <20100326161539.GA10618@icarus.home.lan> References: <4BACB3F5.7010905@freebsd.org> <201003261528.o2QFSAuI037251@chez.mckusick.com> <20100326161539.GA10618@icarus.home.lan> Date: Fri, 26 Mar 2010 13:21:41 -0500 Received: by 10.231.153.205 with SMTP id l13mr576702ibw.64.1269627701340; Fri, 26 Mar 2010 11:21:41 -0700 (PDT) Message-ID: <790a9fff1003261121p5d72e74bw61d0a66a7d418aae@mail.gmail.com> From: Scot Hetzel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , freebsd-fs@freebsd.org, Andriy Gapon , freebsd-geom@freebsd.org Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 18:21:42 -0000 On Fri, Mar 26, 2010 at 11:15 AM, Jeremy Chadwick wrote: > On Fri, Mar 26, 2010 at 08:28:10AM -0700, Kirk McKusick wrote: >> I have reviewed your change and I believe that your analysis is >> correct. I am in agreement with your making the change. >> >> As disk sector sizes will be growing in the near future, it would >> be desirable to get away from having DEV_BSIZE hard-coded. But as >> you note, that is a far bigger change than this one. > > I should note that they already have grown: Western Digital, as of a few > months ago, began shipping drives that use 4KByte sectors. =A0They're > known as the "EARS" drives, due to their model string ending with > "EARS": > > WD20EARS: http://www.wdc.com/en/products/Products.asp?DriveID=3D773 > WD15EARS: http://www.wdc.com/en/products/products.asp?driveid=3D772 > WD10EARS: http://www.wdc.com/en/products/products.asp?driveid=3D763 > > (I should warn folks these are Caviar Green drives, which may suffer > from excessive Load Cycles (parking/unparking actuator arm). =A0I don't > have one of these drives so I can't validate if the issue happens on > this model or not) > > A discussion and an including an incredibly cheesy video review are > below. =A0The video review does discuss the 4KB sector size, in addition > to jumpers that revert the drive to using 512-byte sectors for older > OSes such as Windows XP -- and presumably FreeBSD. > > http://www.tomshardware.com/reviews/wd-4k-sector,2554.html > http://www.youtube.com/watch?v=3DQeFj2QTaA3Y > After reviewing these links, my understanding of these drives that they still provide 512 Byte sectors to the O/S, but when they write to the drive, it will pack eight 512 Byte sectors into a 4K sector on the drive. When the drive needs to modify a sector it has to read the entire 4K sector before writing the change to the drive. This could lead to excessive Read-Modify-Writes if the partition is not aligned on a 4K sector as it will will reduce the performance of these drives. Each partition must be aligned to start and end on a 4K sector. The problem with Windows XP, is that it always creates the first partition starting at sector 63, which is not on a 4k boundary. When the jumpers are set, the drive adds 1 to all 512 byte sector request. For example, the OS asks for sector 63, the drive returns the contents of sector 64, thus forcing the alignment of the partitions to start at a 4K sector. The other option is to use the WD align program on Windows XP. This software re-aligns the partions and data so that they are aligned to the 4k sector. In order for FreeBSD to use these drives, you just need to ensure that all slices/partitions start at a 4k boundary. Scot From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 19:10:20 2010 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 A7923106566C; Fri, 26 Mar 2010 19:10:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 997E08FC13; Fri, 26 Mar 2010 19:10:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA09149; Fri, 26 Mar 2010 21:10:17 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NvEvB-0004Mn-BA; Fri, 26 Mar 2010 21:10:17 +0200 Message-ID: <4BAD0697.3020500@freebsd.org> Date: Fri, 26 Mar 2010 21:10:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org References: <4BACB3F5.7010905@freebsd.org> <201003261528.o2QFSAuI037251@chez.mckusick.com> <20100326161539.GA10618@icarus.home.lan> <790a9fff1003261121p5d72e74bw61d0a66a7d418aae@mail.gmail.com> In-Reply-To: <790a9fff1003261121p5d72e74bw61d0a66a7d418aae@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: g_vfs_open and bread(devvp, ...) 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, 26 Mar 2010 19:10:20 -0000 To no one in particular: guys, I think there are better threads to have a discussion on 4K HDD sectors. This one was started on something only tangentially related. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Mar 27 05:02:34 2010 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 18A28106564A; Sat, 27 Mar 2010 05:02:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E1A268FC15; Sat, 27 Mar 2010 05:02:33 +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 o2R52XiL026918; Sat, 27 Mar 2010 05:02:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2R52Xwt026914; Sat, 27 Mar 2010 05:02:33 GMT (envelope-from linimon) Date: Sat, 27 Mar 2010 05:02:33 GMT Message-Id: <201003270502.o2R52Xwt026914@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145042: [geom] System stops booting after printing message "GEOM_MIRROR: Force device gm0 start due to timeout." 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, 27 Mar 2010 05:02:34 -0000 Old Synopsis: System stops booting after printing message "GEOM_MIRROR: Force device gm0 start due to timeout." New Synopsis: [geom] System stops booting after printing message "GEOM_MIRROR: Force device gm0 start due to timeout." Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 27 05:01:26 UTC 2010 Responsible-Changed-Why: Take a guess and assign this to the geom mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=145042