From owner-freebsd-geom@FreeBSD.ORG Sun Sep 7 16:37:53 2008 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 EC4BB1065674 for ; Sun, 7 Sep 2008 16:37:53 +0000 (UTC) (envelope-from daniel.scheibli@edelbyte.org) Received: from m61s16.vlinux.de (m61s16.vlinux.de [83.151.21.178]) by mx1.freebsd.org (Postfix) with ESMTP id B93C18FC17 for ; Sun, 7 Sep 2008 16:37:53 +0000 (UTC) (envelope-from daniel.scheibli@edelbyte.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by m61s16.vlinux.de (Postfix) with ESMTP id EEE73288F1 for ; Sun, 7 Sep 2008 16:08:45 +0000 (UTC) Message-ID: <48C47AD0.50905@edelbyte.org> Date: Sun, 07 Sep 2008 18:07:28 -0700 From: Daniel Scheibli User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Interaction of geom_vinum & geom_eli X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 16:37:54 -0000 Hi all, I'am currently considering setting up a FreeBSD based file server using geom_vinum and geom_eli. The stackable approach of GEOM sounds very powerful, so I would like to better understand (a) if the planned setup is sound and (b) how the classes would interact in case of an error. The configuration I'am looking for is the following stack: o UFS2 on top of the crypted RAID volume o geom_eli on top of the RAID volume (encrytion only, no data authentication) o geom_vinum on top - spanning all 4 disks (RAID5 setup) o geom_eli on top - separate for each disk (no encryption, only data authentication) o 4x 750 GB HDD (2x PATA, 2x SATA) So the intention is to use geom_eli on the device level to detect bit rot like errors. On the SW RAID level it is used to encrypt all data. Reading geli(8), the data authentication section at the end states that "When data corruption/modification is detected, geli will not return any data, but instead will return an error (EINVAL)." My question is how does geom_vinum react on this? I suspect it will reconstruct the data from the parity written to the other disks to service the request. But how is the disk - with the corrupt block - handled? Is the entire disk marked as bad? Or does it only mark that single block? Does it attempt to rewrite the corrupt data with the reconstructed data? Thank you very much Daniel From owner-freebsd-geom@FreeBSD.ORG Mon Sep 8 02:22:20 2008 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 B2F871065679 for ; Mon, 8 Sep 2008 02:22:20 +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 A0B848FC1E for ; Mon, 8 Sep 2008 02:22:20 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m882MKSN006678 for ; Mon, 8 Sep 2008 02:22:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m882MKUQ006674 for freebsd-geom@FreeBSD.org; Mon, 8 Sep 2008 02:22:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Sep 2008 02:22:20 GMT Message-Id: <200809080222.m882MKUQ006674@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, 08 Sep 2008 02:22:20 -0000 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/126902 geom [geom] [geom_label] Kernel panic during install boot 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/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 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/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/119743 geom [geom] geom label for cds is keeped after dismount and f 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 o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm 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/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach 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 a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown 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 38 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From owner-freebsd-geom@FreeBSD.ORG Mon Sep 8 13:58:21 2008 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 C95831065670 for ; Mon, 8 Sep 2008 13:58:21 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 200308FC21 for ; Mon, 8 Sep 2008 13:58:20 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 1CD97400A; Mon, 8 Sep 2008 15:58:19 +0200 (CEST) Received: from nobby (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 96B4D4007; Mon, 8 Sep 2008 15:58:18 +0200 (CEST) Date: Mon, 8 Sep 2008 15:57:41 +0200 From: Ulf Lilleengen To: Daniel Scheibli Message-ID: <20080908135741.GA2567@nobby.lan> References: <48C47AD0.50905@edelbyte.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C47AD0.50905@edelbyte.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-geom@freebsd.org Subject: Re: Interaction of geom_vinum & geom_eli X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "..."@nobby.lan List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 13:58:21 -0000 On Sun, Sep 07, 2008 at 06:07:28PM -0700, Daniel Scheibli wrote: > > Hi all, > > I'am currently considering setting up a FreeBSD based file server > using geom_vinum and geom_eli. > > The stackable approach of GEOM sounds very powerful, so I would > like to better understand (a) if the planned setup is sound and > (b) how the classes would interact in case of an error. > > The configuration I'am looking for is the following stack: > [...] > > My question is how does geom_vinum react on this? > > I suspect it will reconstruct the data from the parity written > to the other disks to service the request. > > But how is the disk - with the corrupt block - handled? Is the > entire disk marked as bad? Or does it only mark that single block? > Does it attempt to rewrite the corrupt data with the reconstructed > data? > Hi, Gvinum will set the state of the drive to "down" (And you will get a "GEOM_VINUM: lost drive XXX" message). It will then as you say reconstruct the data if it's part of a RAID-5 plex. It will not however "salvage" the data on the drive like for instance ZFS. -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Mon Sep 8 15:02:09 2008 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 355A6106566C for ; Mon, 8 Sep 2008 15:02:09 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id E72308FC13 for ; Mon, 8 Sep 2008 15:02:08 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local (calvin.pai.local [10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.13.8) with ESMTP id m88Chf9D034304 for ; Mon, 8 Sep 2008 08:43:42 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Authentication-Results: mx2.confluenttech.com from=mikej@paymentallianceintl.com; sender-id=neutral; spf=neutral X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Sep 2008 08:43:36 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SUBSCRIBE Thread-Index: AckRsIL7jKkmDelPRQCVCGPubTGdOw== From: "Michael Jung" Importance: normal Priority: normal To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SUBSCRIBE 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, 08 Sep 2008 15:02:09 -0000 SUBSCRIBE CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 10:54:14 2008 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 587F81065675 for ; Wed, 10 Sep 2008 10:54:14 +0000 (UTC) (envelope-from nuno.martinho@mail.pt) Received: from front4.netvisao.pt (front4.netvisao.pt [213.228.128.37]) by mx1.freebsd.org (Postfix) with SMTP id 74D368FC13 for ; Wed, 10 Sep 2008 10:54:13 +0000 (UTC) (envelope-from nuno.martinho@mail.pt) Received: (qmail 14539 invoked from network); 10 Sep 2008 10:27:31 -0000 Received: from av-front2.netvisao.pt (213.228.128.153) by front4.netvisao.pt with SMTP; 10 Sep 2008 10:27:31 -0000 Received: (qmail 24858 invoked from network); 10 Sep 2008 10:27:34 -0000 Received: from ff1-84-90-15-76.netvisao.pt (HELO www.trote.org) (ngmartinho@[84.90.15.76]) (envelope-sender ) by av-front2.netvisao.pt (qmail-ldap-1.03) with SMTP for ; 10 Sep 2008 10:27:34 -0000 Received: from 192.168.1.10 ([192.168.1.10]) by www.trote.org (Kerio MailServer 6.4.1) for freebsd-geom@freebsd.org; Wed, 10 Sep 2008 11:27:40 +0100 To: freebsd-geom@freebsd.org From: "Nuno Martinho" Message-ID: <20080910102740.4b1dab5d@www.trote.org> Date: Wed, 10 Sep 2008 11:27:40 +0100 X-Mailer: Kerio MailServer 6.4.1 WebMail X-User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GEOM_MIRROR Errors 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, 10 Sep 2008 10:54:14 -0000 =20 I have a RAID 1 that was working fine without errors reported. The RAID = was not on Degraded state. =20 When i shutdown Freenas, GEOM=5FMIRROR start to report errors during shu= tdown. =20 I=E2=80=99ve checked SMART and there are no problems with the disks. =20 =20 During shutdown: =20 Sep 10 07:33:15 kernel: ad6: TIMEOUT - WRITE=5FDMA48 retr= ying (1 retry left) LBA=3D976773167 =20 Sep 10 07:33:20 kernel: ad6: TIMEOUT - WRITE=5FDMA48 retr= ying (0 retries left) LBA=3D976773167 =20 Sep 10 07:33:25 kernel: ad6: FAILURE - WRITE=5FDMA48 time= d out LBA=3D976773167 =20 Sep 10 07:33:25 kernel: GEOM=5FMIRROR: Cannot write metad= ata on ad6 (device=3Draid1, error=3D5). =20 Sep 10 07:33:25 kernel: GEOM=5FMIRROR: Cannot update meta= data on disk ad6 (error=3D5). =20 Sep 10 07:33:32 kernel: ad7: TIMEOUT - WRITE=5FDMA48 retr= ying (1 retry left) LBA=3D976773167 =20 =20 During startup: =20 Sep 10 07:47:47 kernel: ad6: 476940MB at ata3-master UDMA100 =20 Sep 10 07:47:47 kernel: ad7: 476940MB at ata3-slave UDMA100 =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Device raid1 creat= ed (id=3D3401427605). =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Device raid1: prov= ider ad7 detected. =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Device raid1: prov= ider ad6 detected. =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Component ad6 (dev= ice raid1) broken, skipping. =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Device raid1: prov= ider ad7 activated. =20 Sep 10 07:47:47 kernel: GEOM=5FMIRROR: Device raid1: prov= ider mirror/raid1 launched. =20 =20 If i try to insert disk =E2=80=9Cad6=E2=80=9D in the mirror: =20 Sep 10 07:49:40 kernel: GEOM=5FMIRROR: Component ad6 (dev= ice raid1) broken, skipping. =20 Sep 10 07:49:40 kernel: GEOM=5FMIRROR: Cannot add disk ad= 6 to raid1 (error=3D22). =20 =20 The only solution was rebuild the mirror. =20 =20 Why this errors=3F =20 =20 =20 Best Regards, =20 Martinho. From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 12:58:41 2008 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 641C1106566B for ; Wed, 10 Sep 2008 12:58:41 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5AC8FC1B for ; Wed, 10 Sep 2008 12:58:41 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local (calvin.pai.local [10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.13.8) with ESMTP id m8ACwboS011916 for ; Wed, 10 Sep 2008 08:58:37 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Authentication-Results: mx2.confluenttech.com from=mikej@paymentallianceintl.com; sender-id=neutral; spf=neutral X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 10 Sep 2008 08:58:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to FSCK GEOM GELI image Importance: normal Priority: normal Thread-Index: AckQ+hSx466ByfxCQwOmXG2Ff9pO5gAuZicw From: "Michael Jung" To: Subject: How to FSCK GEOM GELI image 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, 10 Sep 2008 12:58:41 -0000 FreeBSD 6.3-RELEASE-p2 #15 I've been using the image for some time and was well until a UPS failure. Here is the script I use to mount the encrypted file image ++++++++++++ mdconfig -a -t vnode -f /home/staff/mikej/image md0 geli attach -k /etc/gli/image.key /dev/md0c mount /dev/md0c.eli /private ++++++++++++ It fails to mount and I see this is dmesg GEOM_ELI: Device md0c.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software WARNING: R/W mount of /private denied. Filesystem is not clean - run fsck ++++++++++++ So... I mount -ro mount -o ro /dev/md0c.eli /private (root@firewall) /home/staff/mikej/bin# fsck -t ufs /dev/md0c.eli ** /dev/md0c.eli (NO WRITE) ** Last Mounted on /private ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 16 files, 254176 used, 1034826 free (14 frags, 258703 blocks, 0.0% fragmentation) (root@firewall) /home/staff/mikej/bin# But this does not mark the file system clean. If I then un-mount /dev/md0c.eli it still refuses to mount R/W. (root@firewall) /private# df -h Filesystem Size Used Avail Capacity Mounted on /dev/twed0s1a 1.1T 883G 109G 89% / devfs 1.0K 1.0K 0B 100% /dev linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc devfs 1.0K 1.0K 0B 100% /var/named/dev /dev/md0c.eli 4.9G 993M 3.6G 21% /private (root@firewall) /private# When mount R/O I can read data fine. How do you fsck a GELI image? Thanks --mikej CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 13:23:21 2008 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 C82AD1065672 for ; Wed, 10 Sep 2008 13:23:21 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4578FC1C for ; Wed, 10 Sep 2008 13:23:21 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KdPfE-0003JD-GM for freebsd-geom@freebsd.org; Wed, 10 Sep 2008 13:23:20 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2008 13:23:20 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2008 13:23:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Wed, 10 Sep 2008 15:23:22 +0200 Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63A1A4E3ADA2A3B43FD738E6" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: How to FSCK GEOM GELI image 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, 10 Sep 2008 13:23:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63A1A4E3ADA2A3B43FD738E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Jung wrote: > FreeBSD 6.3-RELEASE-p2 #15 >=20 > I've been using the image for some time and was well until a UPS > failure. >=20 > Here is the script I use to mount the encrypted file image >=20 > ++++++++++++ >=20 > mdconfig -a -t vnode -f /home/staff/mikej/image md0 > geli attach -k /etc/gli/image.key /dev/md0c Try fsck after this step, before you mount it: fsck /dev/md0c.eli > mount /dev/md0c.eli /private >=20 > ++++++++++++ >=20 > It fails to mount and I see this is dmesg >=20 > GEOM_ELI: Device md0c.eli created. > GEOM_ELI: Encryption: AES-CBC 128 > GEOM_ELI: Crypto: software > WARNING: R/W mount of /private denied. Filesystem is not clean - run > fsck --------------enig63A1A4E3ADA2A3B43FD738E6 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIx8pKldnAQVacBcgRAuADAJ9jynAbz2KSCZRMUKQHT4MNKlXetQCfc/bv UDeM0I16k4HTBYBO7Htchuc= =ecBg -----END PGP SIGNATURE----- --------------enig63A1A4E3ADA2A3B43FD738E6-- From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 13:44:55 2008 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 37E2E1065672 for ; Wed, 10 Sep 2008 13:44:55 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id F169D8FC1F for ; Wed, 10 Sep 2008 13:44:54 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local (calvin.pai.local [10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.13.8) with ESMTP id m8ADirvJ017484 for ; Wed, 10 Sep 2008 09:44:53 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Authentication-Results: mx2.confluenttech.com from=mikej@paymentallianceintl.com; sender-id=neutral; spf=neutral X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 10 Sep 2008 09:44:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: How to FSCK GEOM GELI image Thread-Index: AckTSIP2sdfoa8geRT60QJLX5tRF3QAArBkg From: "Michael Jung" To: Subject: RE: How to FSCK GEOM GELI image 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, 10 Sep 2008 13:44:55 -0000 -----Original Message----- From: owner-freebsd-geom@freebsd.org [mailto:owner-freebsd-geom@freebsd.org] On Behalf Of Ivan Voras Sent: Wednesday, September 10, 2008 9:23 AM To: freebsd-geom@freebsd.org Subject: Re: How to FSCK GEOM GELI image Michael Jung wrote: > FreeBSD 6.3-RELEASE-p2 #15 > > I've been using the image for some time and was well until a UPS > failure. > > Here is the script I use to mount the encrypted file image > > ++++++++++++ > > mdconfig -a -t vnode -f /home/staff/mikej/image md0 > geli attach -k /etc/gli/image.key /dev/md0c Try fsck after this step, before you mount it: fsck /dev/md0c.eli > mount /dev/md0c.eli /private > > ++++++++++++ > > It fails to mount and I see this is dmesg > > GEOM_ELI: Device md0c.eli created. > GEOM_ELI: Encryption: AES-CBC 128 > GEOM_ELI: Crypto: software > WARNING: R/W mount of /private denied. Filesystem is not clean - run > fsck mdconfig -a -t vnode -f /home/staff/mikej/image md0 geli attach -k /etc/gli/image.key /dev/md0c mount /dev/md0c.eli /private (root@firewall) /home/staff/mikej/bin# mdconfig -a -t vnode -f /home/staff/mikej/image md0 md0 (root@firewall) /home/staff/mikej/bin# geli attach -k /etc/gli/image.key /dev/md0c Enter passphrase: (root@firewall) /home/staff/mikej/bin# fsck /dev/md0c.eli fsck: Could not determine filesystem type <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (root@firewall) /home/staff/mikej/bin# CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 13:48:50 2008 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 6D1281065672 for ; Wed, 10 Sep 2008 13:48:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id E8A098FC08 for ; Wed, 10 Sep 2008 13:48:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 76A4019E02F; Wed, 10 Sep 2008 15:29:40 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E0F4319E02D; Wed, 10 Sep 2008 15:29:37 +0200 (CEST) Message-ID: <48C7CBE2.1000904@quip.cz> Date: Wed, 10 Sep 2008 15:30:10 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Nuno Martinho References: <20080910102740.4b1dab5d@www.trote.org> In-Reply-To: <20080910102740.4b1dab5d@www.trote.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-geom@freebsd.org Subject: Re: GEOM_MIRROR Errors 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, 10 Sep 2008 13:48:50 -0000 Nuno Martinho wrote: > > I have a RAID 1 that was working fine without errors reported. The RAID was not on Degraded state. > When i shutdown Freenas, GEOM_MIRROR start to report errors during shutdown. > I’ve checked SMART and there are no problems with the disks. > > During shutdown: > Sep 10 07:33:15 kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=976773167 > Sep 10 07:33:20 kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (0 retries left) LBA=976773167 > Sep 10 07:33:25 kernel: ad6: FAILURE - WRITE_DMA48 timed out LBA=976773167 > Sep 10 07:33:25 kernel: GEOM_MIRROR: Cannot write metadata on ad6 (device=raid1, error=5). > Sep 10 07:33:25 kernel: GEOM_MIRROR: Cannot update metadata on disk ad6 (error=5). > Sep 10 07:33:32 kernel: ad7: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=976773167 > > > During startup: > Sep 10 07:47:47 kernel: ad6: 476940MB at ata3-master UDMA100 > Sep 10 07:47:47 kernel: ad7: 476940MB at ata3-slave UDMA100 > Sep 10 07:47:47 kernel: GEOM_MIRROR: Device raid1 created (id=3401427605). > Sep 10 07:47:47 kernel: GEOM_MIRROR: Device raid1: provider ad7 detected. > Sep 10 07:47:47 kernel: GEOM_MIRROR: Device raid1: provider ad6 detected. > Sep 10 07:47:47 kernel: GEOM_MIRROR: Component ad6 (device raid1) broken, skipping. > Sep 10 07:47:47 kernel: GEOM_MIRROR: Device raid1: provider ad7 activated. > Sep 10 07:47:47 kernel: GEOM_MIRROR: Device raid1: provider mirror/raid1 launched. > > If i try to insert disk “ad6” in the mirror: > Sep 10 07:49:40 kernel: GEOM_MIRROR: Component ad6 (device raid1) broken, skipping. > Sep 10 07:49:40 kernel: GEOM_MIRROR: Cannot add disk ad6 to raid1 (error=22). > > The only solution was rebuild the mirror. > > Why this errors? It can be caused by bad cables or controller. I had similar problems on ASUS RS-120 with Intel controller, somebody have same problems with Silicon Image chips. You can re-use ad6 by: gmirror forget raid1 [it will not destroy your mirror data, just remove info about disconnected devices (ad6 in this case)] gmirror clear ad6 [remove metadata from ad6] gmirror insert raid1 ad6 [reinsert ad6 in to raid1 and start resync] Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 16:24:25 2008 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 876491065692 for ; Wed, 10 Sep 2008 16:24:25 +0000 (UTC) (envelope-from gcr+freebsd-geom@tharned.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 6580C8FC15 for ; Wed, 10 Sep 2008 16:24:25 +0000 (UTC) (envelope-from gcr+freebsd-geom@tharned.org) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id CySb1a00F16AWCUA948RPT; Wed, 10 Sep 2008 16:08:25 +0000 Received: from packrat.tharned.org ([75.145.12.185]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id D48M1a00M3zZBGT8S48Qvs; Wed, 10 Sep 2008 16:08:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=SbD4DCLfUV8fTMdKc-sA:9 a=YVLHBmxIezYvC1RvkI4R8zBxQOMA:4 a=LY0hPdMaydYA:10 Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.2/8.14.2) with ESMTP id m8AG8JhO090275; Wed, 10 Sep 2008 11:08:19 -0500 (CDT) (envelope-from gcr+freebsd-geom@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.2/8.14.2/Submit) with ESMTP id m8AG8Hpq090272; Wed, 10 Sep 2008 11:08:19 -0500 (CDT) (envelope-from gcr+freebsd-geom@tharned.org) Date: Wed, 10 Sep 2008 11:08:16 -0500 (CDT) From: Greg Rivers To: Michael Jung In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-geom@freebsd.org Subject: Re: How to FSCK GEOM GELI image 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, 10 Sep 2008 16:24:25 -0000 On Wed, 10 Sep 2008, Michael Jung wrote: > [snip] > (root@firewall) /home/staff/mikej/bin# fsck /dev/md0c.eli > > fsck: Could not determine filesystem type > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > That's because there's no label on that volume. Give it the type with '-t': fsck -t ufs /dev/md0c.eli Note that this has nothing to do with geli per se; fsck behaves this way with any unlabeled volume. You might want to run in preen mode instead of answering "yes" or using '-y'. This will safely fix all non-critical errors automatically: fsck -t ufs -fp /dev/md0c.eli -- Greg From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 16:56:10 2008 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 E4EB91065670 for ; Wed, 10 Sep 2008 16:56:10 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id 97CAC8FC0C for ; Wed, 10 Sep 2008 16:56:10 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local (calvin.pai.local [10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.13.8) with ESMTP id m8AGu7kY041404; Wed, 10 Sep 2008 12:56:07 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Authentication-Results: mx2.confluenttech.com from=mikej@paymentallianceintl.com; sender-id=neutral; spf=neutral X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 10 Sep 2008 12:56:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: How to FSCK GEOM GELI image Thread-Index: AckTX8QwZwtPpnvTTi6g8BY0OxMZNgABjQBg From: "Michael Jung" To: "Greg Rivers" Cc: freebsd-geom@freebsd.org Subject: RE: How to FSCK GEOM GELI image 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, 10 Sep 2008 16:56:11 -0000 -----Original Message----- From: Greg Rivers [mailto:gcr+freebsd-geom@tharned.org] Sent: Wednesday, September 10, 2008 12:08 PM To: Michael Jung Cc: freebsd-geom@freebsd.org Subject: Re: How to FSCK GEOM GELI image On Wed, 10 Sep 2008, Michael Jung wrote: > [snip] > (root@firewall) /home/staff/mikej/bin# fsck /dev/md0c.eli > > fsck: Could not determine filesystem type > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > That's because there's no label on that volume. Give it the type with '-t': fsck -t ufs /dev/md0c.eli Note that this has nothing to do with geli per se; fsck behaves this way with any unlabeled volume. You might want to run in preen mode instead of answering "yes" or using '-y'. This will safely fix all non-critical errors automatically: fsck -t ufs -fp /dev/md0c.eli -- Greg ++++++++++++++++++++++++++++++++++++ I thought I had tried that :-( Thanks - this solved the issue. --mikej CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-geom@FreeBSD.ORG Wed Sep 10 22:57:49 2008 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 9F5B9106566B for ; Wed, 10 Sep 2008 22:57:49 +0000 (UTC) (envelope-from daniel.scheibli@edelbyte.org) Received: from m61s16.vlinux.de (m61s16.vlinux.de [83.151.21.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6488A8FC27 for ; Wed, 10 Sep 2008 22:57:49 +0000 (UTC) (envelope-from daniel.scheibli@edelbyte.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by m61s16.vlinux.de (Postfix) with ESMTP id BD849288F2; Wed, 10 Sep 2008 22:59:03 +0000 (UTC) Message-ID: <48C8CF48.1060808@edelbyte.org> Date: Thu, 11 Sep 2008 00:56:56 -0700 From: Daniel Scheibli User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: lulf@stud.ntnu.no References: <48C47AD0.50905@edelbyte.org> <20080908135741.GA2567@nobby.lan> In-Reply-To: <20080908135741.GA2567@nobby.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: Interaction of geom_vinum & geom_eli 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, 10 Sep 2008 22:57:49 -0000 Ulf Lilleengen wrote: > On Sun, Sep 07, 2008 at 06:07:28PM -0700, Daniel Scheibli wrote: > [...] >> My question is how does geom_vinum react on this? >> >> I suspect it will reconstruct the data from the parity written >> to the other disks to service the request. >> >> But how is the disk - with the corrupt block - handled? Is the >> entire disk marked as bad? Or does it only mark that single block? >> Does it attempt to rewrite the corrupt data with the reconstructed >> data? >> > Hi, > > Gvinum will set the state of the drive to "down" (And you will get a > "GEOM_VINUM: lost drive XXX" message). It will then as you say reconstruct > the data if it's part of a RAID-5 plex. It will not however "salvage" the > data on the drive like for instance ZFS. Hi, thanks for your reply, thats what I feared. I tend to run a "checksum all data" script every time I do a backup (to ensure that the backup worked, but also to check that only expected file changed since the last checksum run). If a single corrupt block result in the entire disk being flagged "down", then I worry that I'am only 1 more corrupt block (on any other disk) away from the entire plex being considered broken. Are there any future plans to rewrite the reconstructed data down to the "failed" disk (in geom_vinum or geom_raid5) or is this then something where one should look towards the ZFS port? Also would it be of interest to have the "escalation" mode configurable? From owner-freebsd-geom@FreeBSD.ORG Thu Sep 11 16:36:12 2008 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 18A53106564A for ; Thu, 11 Sep 2008 16:36:12 +0000 (UTC) (envelope-from ac@belngo.info) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id D50448FC24 for ; Thu, 11 Sep 2008 16:36:11 +0000 (UTC) (envelope-from ac@belngo.info) Received: by gxk10 with SMTP id 10so16704297gxk.19 for ; Thu, 11 Sep 2008 09:36:11 -0700 (PDT) Received: by 10.142.232.20 with SMTP id e20mr1004622wfh.237.1221149466621; Thu, 11 Sep 2008 09:11:06 -0700 (PDT) Received: by 10.142.214.17 with HTTP; Thu, 11 Sep 2008 09:11:06 -0700 (PDT) Message-ID: <5709ce310809110911s7a8163c6g3ce042f8db1edf20@mail.gmail.com> Date: Thu, 11 Sep 2008 19:11:06 +0300 From: "Alaksiej C" To: freebsd-geom@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Strange behaviour of GELI integrity verification 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, 11 Sep 2008 16:36:12 -0000 Hello, I am playing with geoms configuration like this: gmirror label m0 /dev/ad1 geli label -a HMAC/SHA1 -e AES -l 256 -s 4096 /dev/mirror/m0 then I initialized m0.eli to stop messages about integrity errors: dd if=/dev/random of=/dev/mirror/m0.eli divided m0.eli in two slices and created ufs on m0.elia and zpool on m0.elid Creation of filesystems, and even populating it with files many times echoed with mesages: GEOM_ELI: mirror/m0.eli: ... bytes corrupted at offset ... It doesn't look like reasonable behaviour, I think. Could anybody please point me where's the problem? FreeBSD 7.0-RELEASE, GENERIC i386 From owner-freebsd-geom@FreeBSD.ORG Thu Sep 11 17:46:37 2008 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 96A9C1065671 for ; Thu, 11 Sep 2008 17:46:37 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from bene2.itea.ntnu.no (bene2.itea.ntnu.no [IPv6:2001:700:300:3::57]) by mx1.freebsd.org (Postfix) with ESMTP id A3C058FC22 for ; Thu, 11 Sep 2008 17:46:35 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene2.itea.ntnu.no (Postfix) with ESMTP id 89E8490002; Thu, 11 Sep 2008 19:46:33 +0200 (CEST) Received: from nobby (unknown [IPv6:2001:700:300:3::184]) by bene2.itea.ntnu.no (Postfix) with ESMTP id E47F990001; Thu, 11 Sep 2008 19:46:32 +0200 (CEST) Date: Thu, 11 Sep 2008 19:45:55 +0200 From: Ulf Lilleengen To: Daniel Scheibli Message-ID: <20080911174555.GA2992@nobby.lan> References: <48C47AD0.50905@edelbyte.org> <20080908135741.GA2567@nobby.lan> <48C8CF48.1060808@edelbyte.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C8CF48.1060808@edelbyte.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Debian amavisd-new at bene2.itea.ntnu.no Cc: freebsd-geom@freebsd.org Subject: Re: Interaction of geom_vinum & geom_eli X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "..."@nobby.lan List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 17:46:37 -0000 On Thu, Sep 11, 2008 at 12:56:56AM -0700, Daniel Scheibli wrote: > > Ulf Lilleengen wrote: > > On Sun, Sep 07, 2008 at 06:07:28PM -0700, Daniel Scheibli wrote: > > [...] > >> My question is how does geom_vinum react on this? > >> > >> I suspect it will reconstruct the data from the parity written > >> to the other disks to service the request. > >> > >> But how is the disk - with the corrupt block - handled? Is the > >> entire disk marked as bad? Or does it only mark that single block? > >> Does it attempt to rewrite the corrupt data with the reconstructed > >> data? > >> > > Hi, > > > > Gvinum will set the state of the drive to "down" (And you will get a > > "GEOM_VINUM: lost drive XXX" message). It will then as you say reconstruct > > the data if it's part of a RAID-5 plex. It will not however "salvage" the > > data on the drive like for instance ZFS. > > Hi, > > thanks for your reply, thats what I feared. > > I tend to run a "checksum all data" script every time I do > a backup (to ensure that the backup worked, but also to check > that only expected file changed since the last checksum run). > > If a single corrupt block result in the entire disk being > flagged "down", then I worry that I'am only 1 more corrupt > block (on any other disk) away from the entire plex being > considered broken. > > Are there any future plans to rewrite the reconstructed > data down to the "failed" disk (in geom_vinum or geom_raid5) > or is this then something where one should look towards > the ZFS port? Also would it be of interest to have the > "escalation" mode configurable? > That would be a neat feature to have, but I won't start on implementing it until the 2007 SoC work on gvinum have been integrated (it's hard enough to review as it is), but afterwards I might try. It would have to optional too, for not breaking the old way.. Regarding geom_raid5, you should ask the author, as it's not in the tree at the moment. For the moment, only ZFS pools provides this functionality. Remember that you can use a ZFS pool and create geom providers (ZVOLs) from it if you want to run another file system. -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Fri Sep 12 08:58:26 2008 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 8C0321065671 for ; Fri, 12 Sep 2008 08:58:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id DA5EE8FC1D for ; Fri, 12 Sep 2008 08:58:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 777AD45C9F; Fri, 12 Sep 2008 10:58:24 +0200 (CEST) Received: from localhost (kszczepanski.wheel.pl [10.0.1.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9F04545B36; Fri, 12 Sep 2008 10:58:19 +0200 (CEST) Date: Fri, 12 Sep 2008 10:58:25 +0200 From: Pawel Jakub Dawidek To: Alaksiej C Message-ID: <20080912085825.GC2951@garage.freebsd.pl> References: <5709ce310809110911s7a8163c6g3ce042f8db1edf20@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <5709ce310809110911s7a8163c6g3ce042f8db1edf20@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@FreeBSD.ORG Subject: Re: Strange behaviour of GELI integrity verification 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, 12 Sep 2008 08:58:26 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2008 at 07:11:06PM +0300, Alaksiej C wrote: > Hello, >=20 > I am playing with geoms configuration like this: >=20 > gmirror label m0 /dev/ad1 > geli label -a HMAC/SHA1 -e AES -l 256 -s 4096 /dev/mirror/m0 >=20 > then I initialized m0.eli to stop messages about integrity errors: > dd if=3D/dev/random of=3D/dev/mirror/m0.eli What was the result of this command? If you forget to call dd(1) with bs=3D4096 it will fail. > divided m0.eli in two slices and created ufs on m0.elia and zpool on m0.e= lid >=20 > Creation of filesystems, and even populating it with files many times ech= oed > with mesages: >=20 > GEOM_ELI: mirror/m0.eli: ... bytes corrupted at offset ... >=20 > It doesn't look like reasonable behaviour, I think. Could anybody please > point me where's the problem? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIyi8wForvXbEpPzQRAhDCAKCPjZ34FvrbtmoB5K5ITZPZe/DPAQCgh8Xa w8e+Rkx8G/wtnACAqLIwY9w= =7HB+ -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz--