From owner-freebsd-geom@FreeBSD.ORG Mon Mar 29 11:06:55 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 D1B57106567F for ; Mon, 29 Mar 2010 11:06:55 +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 BFA328FC15 for ; Mon, 29 Mar 2010 11:06:55 +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 o2TB6tsO057988 for ; Mon, 29 Mar 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2TB6tQx057986 for freebsd-geom@FreeBSD.org; Mon, 29 Mar 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Mar 2010 11:06:55 GMT Message-Id: <201003291106.o2TB6tQx057986@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, 29 Mar 2010 11:06:55 -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/145042 geom [geom] System stops booting after printing message "GE o kern/144962 geom [geom] panic when accessing GPT disk with a large numb 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 55 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 29 14:37:00 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 085181065678 for ; Mon, 29 Mar 2010 14:37:00 +0000 (UTC) (envelope-from nonsolosoft@diff.org) Received: from smtpi4.ngi.it (smtpi4.ngi.it [88.149.128.34]) by mx1.freebsd.org (Postfix) with ESMTP id BFC9E8FC18 for ; Mon, 29 Mar 2010 14:36:59 +0000 (UTC) Received: from lap.diff.org (81-174-26-135.static.ngi.it [81.174.26.135]) by smtpi4.ngi.it (Postfix) with ESMTP id F3CBE421E1 for ; Mon, 29 Mar 2010 16:36:57 +0200 (CEST) Message-ID: <4BB0BB09.4000000@diff.org> Date: Mon, 29 Mar 2010 16:36:57 +0200 From: Ferruccio Zamuner Organization: NonSoLoSoft User-Agent: Thunderbird 2.0.0.23 (X11/20100121) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: multipart/mixed; boundary="------------040102050903050308080606" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: gmirror and disk failure 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, 29 Mar 2010 14:37:00 -0000 This is a multi-part message in MIME format. --------------040102050903050308080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit kernel: ad6: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) 246989210 kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) 247031443 kernel: ad6: TIMEOUT - READ_DMA retrying (1 retry left) 50334911 Why such errors make freebsd 8.0 to reboot? I suppose that gmirror has to mark ad6 broken and bring the mirror in degraded mode. Isn't it? After reboot: ad6: FAILURE - READ_DMA us=51 error=40 LBA=25293375 GEOM_MIRROR: request failed (error=5) . ad6s1[READ(offset=12950175744, lenght 131072)] GEOM_MIRROR: Synchronization request failed (error=5). mirror/gm0[READ(offset=12950175744, lenght 131072)] /sbin/gmirror status Name Status Components mirror/gm0 DEGRADED ad4s1 (26%) ad6s1 If the error is on ad6s1, why ad4s1 has to sycronize with the fault one? --------------040102050903050308080606-- From owner-freebsd-geom@FreeBSD.ORG Wed Mar 31 14:54:11 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 5257D106566C; Wed, 31 Mar 2010 14:54:11 +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 636398FC1A; Wed, 31 Mar 2010 14:54:10 +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 RAA21421; Wed, 31 Mar 2010 17:54:08 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB36210.5040102@freebsd.org> Date: Wed, 31 Mar 2010 17:54:08 +0300 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: <4BA8CD21.3000803@freebsd.org> In-Reply-To: <4BA8CD21.3000803@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 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: Wed, 31 Mar 2010 14:54:11 -0000 on 23/03/2010 16:16 Andriy Gapon said the following: > 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); If no one has objections, suggestions or opinions, I am going to commit this. I will probably change the scary comment too. > > 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 Wed Mar 31 14:54:46 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 D915F106566C; Wed, 31 Mar 2010 14:54:46 +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 EB2EA8FC08; Wed, 31 Mar 2010 14:54:45 +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 RAA21430; Wed, 31 Mar 2010 17:54:44 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB36234.8070907@freebsd.org> Date: Wed, 31 Mar 2010 17:54:44 +0300 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: <4BA7B9E3.3080003@freebsd.org> In-Reply-To: <4BA7B9E3.3080003@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 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: Wed, 31 Mar 2010 14:54:46 -0000 If no one has objections, suggestions or opinions, I am going to commit this. on 22/03/2010 20:41 Andriy Gapon said the following: > 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 Thu Apr 1 17:38:09 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 7B0FE106566B; Thu, 1 Apr 2010 17:38:09 +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 557AA8FC15; Thu, 1 Apr 2010 17:38:07 +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 UAA17181; Thu, 01 Apr 2010 20:38:04 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB4D9FB.3000706@freebsd.org> Date: Thu, 01 Apr 2010 20:38:03 +0300 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: <201003261528.o2QFSAuI037251@chez.mckusick.com> In-Reply-To: <201003261528.o2QFSAuI037251@chez.mckusick.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , Kostik Belousov , Poul-Henning Kamp , Bruce Evans 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: Thu, 01 Apr 2010 17:38:09 -0000 Some bad news. Apparently I missed the fact that in some places bo_bsize is used as sectorsize value of underlying provider. That is, there is code that assumes that devvp's bo_bsize == sectorsize. One such place is vnode_pager_generic_getpages() in sys/vm/vnode_pager.c. That code directly calls bstrategy() on bufobj of devvp and because of that it wants to round up read size to media sectorsize (there would be a KASSERT panic in GEOM if I/O size is not multiple of sectorsize). Thus the code needs to know sectorsize. The other possible place is ffs_rawread. I am not sure how to get sectorsize value in those places in a nice way, i.e. without kludges or violating logical layering. I.e. I could access bo_private->provider->sectorsize, but that seems to be too hack-ish. If anyone knows of a proper way to do this, please let me know. For now I am thinking about resorting to a different, slightly less kludgy (IMO) approach. Leave devvp's bo_bsize to mean provider's sectorsize, but instead in getblk() account for devvp's blkno being in units of DEV_BSIZE: --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -2700,7 +2700,7 @@ */ if (flags & GB_NOCREAT) return NULL; - bsize = bo->bo_bsize; + bsize = vn_isdisk(vp, NULL) ? DEV_BSIZE : bo->bo_bsize; offset = blkno * bsize; vmio = vp->v_object != NULL; maxsize = vmio ? size + (offset & PAGE_MASK) : size; -- Andriy Gapon