From owner-freebsd-geom@FreeBSD.ORG Mon Oct 11 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 1616D10656E3 for ; Mon, 11 Oct 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 035198FC26 for ; Mon, 11 Oct 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 o9BB6sIL037554 for ; Mon, 11 Oct 2010 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9BB6slJ037552 for freebsd-geom@FreeBSD.org; Mon, 11 Oct 2010 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Oct 2010 11:06:54 GMT Message-Id: <201010111106.o9BB6slJ037552@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, 11 Oct 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 bin/151252 geom [geom] libgeom(3) manual page contains broken link in o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147852 geom [geom] [panic] graid3 panic: wrong offset 16384 for se o kern/147851 geom [geom] [panic] graid3 panic: g_read_data: invalid leng o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/147664 geom [geom] [patch] Add the ability to create linux and fat o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/144962 geom [geom] panic when accessing GPT disk with a large numb o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin f bin/144521 geom [geom] geom(8) tool parsing non-subclass command broke 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 s kern/141235 geom [geom_part] 8.0 no longer provides /dev entries for al o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/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/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de 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/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 65 problems total. From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 01:49: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 B32471065673 for ; Wed, 13 Oct 2010 01:49:58 +0000 (UTC) (envelope-from jaccen@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 72B198FC0A for ; Wed, 13 Oct 2010 01:49:58 +0000 (UTC) Received: by gxk4 with SMTP id 4so884579gxk.13 for ; Tue, 12 Oct 2010 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=K5ua7GU0Who+gz5mMXkRrRbg0MGniTBWL2NuWc2mjPQ=; b=q0rhVGOPWQemYQkOpLG5WkKsqKTkDr4+3medbXl4+8NQLHHR7gG0epSsRBxbqy3dlC bP8N27P5iG5++ar8o8FqHqzNeJGgmggvGCPmpywD0QI9Z6E9D8C+QlpVusbthSG5zZRU g8vF/8+WblsVQWfuODt3ePxoTf8moPh/bDEu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fHUajclF5hlrUWgpG8r7zDAZ8vFhwNWFDDwjU9HMLm6Zz31XWqYkRZ3c6Zce3nDdHP ygq058D7rF1acAY6+hrGfyjNk6ICUj7PlsE7L2KwVEBbHDP2B3+Y7mQAQIlxDcDuKOzM ljtrsjDt8tSjXODqIuK/0vd13EF+bh8fFjiKk= MIME-Version: 1.0 Received: by 10.151.7.12 with SMTP id k12mr17889ybi.367.1286932726488; Tue, 12 Oct 2010 18:18:46 -0700 (PDT) Received: by 10.151.84.3 with HTTP; Tue, 12 Oct 2010 18:18:46 -0700 (PDT) Date: Tue, 12 Oct 2010 21:18:46 -0400 Message-ID: From: Jaccen Steinberg To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS, RAIDZ, and Labels 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, 13 Oct 2010 01:49:58 -0000 Environment: PC-BSD 8.1 - RELEASE amd64 root Problem Description: When attempting to create a ZFS RAIDZ pool, I get the following message: [CODE] cannot create 'tank': one or more devices is currently unavailable [/CODE] Command used to make this occur: [CODE] zpool create tank raidz label/P1SG136D.eli label/P2SGY10S.eli label/P3SG3ERV.eli label/P4SGC4QY.eli label/P5SGYJSC.eli label/P6SG49JV.eli label/P7SG9H9H.eli label/P8SGDF8G.eli [/CODE] System: Asus M3N WS Athlon II X2 240 8gb Kingston DDR2 ECC 8 X 1.5tb Seagate SATA drives 60gb IDE drive HighPoint RocketRAID 2220 PCI-X PCI RivaTNT Background Reading as to how I arrived here: 1. [url=http://blog.experimentalworks.net/2008/03/setting-up-an-encrypted-zfs-with-freebsd/]Setting up an encrypted ZFS with FreeBSD[/url] 2. [url=http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211109.html]GELI file systems unusable after "glabel label" operations[/url] 3. [url=http://www.freebsd.org/cgi/man.cgi?query=geli]geli Manpage[/url] 4. [url=http://forums.freebsd.org/showthread.php?t=17129] [Solved] zpool create drives fails [/url] 5. [url=http://forums.freebsd.org/showthread.php?t=16587]ZFS Unavailable[/url] Overview of What I've Done: Reading #1 was used as a rough guideline to make a ZFS pool with geli encryption. I used Reading #4 & #5 to label my drives. I believe one should be able to create an encrypted ZFS pool using labels due to Reading #2. The commands from Reading #1 were slightly modified with help from Reading #3. Code: [CODE] glabel label -v P1SG136D /dev/da0 glabel label -v P2SGY10S /dev/da1 ... [/CODE] This labels each drive attached to my HighPoint controller with the Port # it is attached to, the company brand, and part of the serial number so that I can easily identify which drive has a problem in the future. [CODE] dd if=/dev/random of=/usr/home/THEJEW/P1SG136D.key bs=64 count=1 dd if=/dev/random of=/usr/home/THEJEW/P2SGY10S.key bs=64 count=1 ... [/CODE] Encryption keys are created and placed within my home folder. Home directory is also encrypted, but passphrase is entered at boot (ie. keys are available). [CODE] geli init -a HMAC/SHA256 -e AES -l 256 -s 4096 -K /usr/home/THEJEW/P1SG136D.key /dev/label/P1SG136D geli init -a HMAC/SHA256 -e AES -l 256 -s 4096 -K /usr/home/THEJEW/P2SGY10S.key /dev/label/P2SGY10S ... [/CODE] Preparing to attach key to label to create *.eli in "label" folder. *.eli files do appear in Dolphin. [CODE] geli attach -k /usr/home/THEJEW/P1SG136D.key /dev/label/P1SG136D geli attach -k /usr/home/THEJEW/P2SGY10S.key /dev/label/P2SGY10S ... [/CODE] Attaching. Attempting to create zpool fails (see code in Problem section). Everything attempted as root. Any help appreciated. From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 04:03:37 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 499BA1065672 for ; Wed, 13 Oct 2010 04:03:37 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id 12FDE8FC0C for ; Wed, 13 Oct 2010 04:03:36 +0000 (UTC) Received: from [149.142.124.15] (unknown [149.142.124.15]) by bonett.org (Postfix) with ESMTPSA id E3DEB12408E; Wed, 13 Oct 2010 03:44:13 +0000 (UTC) From: Greg Bonett To: Jaccen Steinberg In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Oct 2010 20:44:12 -0700 Message-ID: <1286941452.8720.32.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: ZFS, RAIDZ, and Labels 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, 13 Oct 2010 04:03:37 -0000 very strange, I think I followed a nearly identical process to set up my zpool on FreeBSD 8-STABLE. Can you try replacing "raidz" with "raidz1"? also, did you verify that everything is present with "ls -l /dev/label/" Maybe try with two or three devices first and see if you get the same problem... -Greg On Tue, 2010-10-12 at 21:18 -0400, Jaccen Steinberg wrote: > Environment: > PC-BSD 8.1 - RELEASE amd64 > root > > Problem Description: > > When attempting to create a ZFS RAIDZ pool, I get the following message: > > [CODE] > cannot create 'tank': one or more devices is currently unavailable > [/CODE] > > > Command used to make this occur: > > [CODE] > zpool create tank raidz label/P1SG136D.eli label/P2SGY10S.eli > label/P3SG3ERV.eli label/P4SGC4QY.eli label/P5SGYJSC.eli > label/P6SG49JV.eli label/P7SG9H9H.eli label/P8SGDF8G.eli > [/CODE] > > > System: > > Asus M3N WS > Athlon II X2 240 > 8gb Kingston DDR2 ECC > 8 X 1.5tb Seagate SATA drives > 60gb IDE drive > HighPoint RocketRAID 2220 PCI-X > PCI RivaTNT > > > Background Reading as to how I arrived here: > > 1. [url=http://blog.experimentalworks.net/2008/03/setting-up-an-encrypted-zfs-with-freebsd/]Setting > up an encrypted ZFS with FreeBSD[/url] > > 2. [url=http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211109.html]GELI > file systems unusable after "glabel label" operations[/url] > > 3. [url=http://www.freebsd.org/cgi/man.cgi?query=geli]geli Manpage[/url] > > 4. [url=http://forums.freebsd.org/showthread.php?t=17129] [Solved] > zpool create drives fails [/url] > > 5. [url=http://forums.freebsd.org/showthread.php?t=16587]ZFS Unavailable[/url] > > > Overview of What I've Done: > > Reading #1 was used as a rough guideline to make a ZFS pool with geli > encryption. I used Reading #4 & #5 to label my drives. I believe > one should be able to create an encrypted ZFS pool using labels due to > Reading #2. The commands from Reading #1 were slightly modified with > help from Reading #3. > > > Code: > > [CODE] > glabel label -v P1SG136D /dev/da0 > glabel label -v P2SGY10S /dev/da1 > ... > [/CODE] > > > This labels each drive attached to my HighPoint controller with the > Port # it is attached to, the company brand, and part of the serial > number so that I can easily identify which drive has a problem in the > future. > > > [CODE] > dd if=/dev/random of=/usr/home/THEJEW/P1SG136D.key bs=64 count=1 > dd if=/dev/random of=/usr/home/THEJEW/P2SGY10S.key bs=64 count=1 > ... > [/CODE] > > Encryption keys are created and placed within my home folder. Home > directory is also encrypted, but passphrase is entered at boot (ie. > keys are available). > > > [CODE] > geli init -a HMAC/SHA256 -e AES -l 256 -s 4096 -K > /usr/home/THEJEW/P1SG136D.key /dev/label/P1SG136D > geli init -a HMAC/SHA256 -e AES -l 256 -s 4096 -K > /usr/home/THEJEW/P2SGY10S.key /dev/label/P2SGY10S > ... > > [/CODE] > > Preparing to attach key to label to create *.eli in "label" folder. > *.eli files do appear in Dolphin. > > > [CODE] > geli attach -k /usr/home/THEJEW/P1SG136D.key /dev/label/P1SG136D > geli attach -k /usr/home/THEJEW/P2SGY10S.key /dev/label/P2SGY10S > ... > [/CODE] > > Attaching. > > > Attempting to create zpool fails (see code in Problem section). > Everything attempted as root. > > > > Any help appreciated. > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 09:10:02 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 EE4291065672 for ; Wed, 13 Oct 2010 09:10:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id A2FED8FC08 for ; Wed, 13 Oct 2010 09:10:02 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 37EDC21671C for ; Wed, 13 Oct 2010 11:50:26 +0300 (EEST) Date: Wed, 13 Oct 2010 11:50:26 +0300 From: Jaakko Heinonen To: freebsd-geom@FreeBSD.org Message-ID: <20101013085025.GB54686@jh> References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 09:10:03 -0000 [Posting a patch to -geom for comments.] On 2010-10-07, Jaakko Heinonen wrote: > Currently several GEOM classes (notably geom_label) allow to create > devices with invalid names. Below is a link to a patch which converts > g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not > a complete solution and essentially changes the panic to a printf. What do you think about this patch? http://people.freebsd.org/~jh/patches/geom_dev-checkname.2.diff Any better ideas how to handle this in GEOM? It doesn't seem to be trivial to propagate an error from g_dev_taste() due to asynchronous nature of the device registration in GEOM. -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 12:49:32 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 8B6EE1065679 for ; Wed, 13 Oct 2010 12:49:32 +0000 (UTC) (envelope-from andrea@ragedrecords.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2B08FC1C for ; Wed, 13 Oct 2010 12:49:32 +0000 (UTC) Received: by iwn8 with SMTP id 8so7794888iwn.13 for ; Wed, 13 Oct 2010 05:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.76 with SMTP id t12mr6767570ibc.161.1286972705776; Wed, 13 Oct 2010 05:25:05 -0700 (PDT) Received: by 10.231.19.65 with HTTP; Wed, 13 Oct 2010 05:25:05 -0700 (PDT) X-Originating-IP: [217.133.83.163] Date: Wed, 13 Oct 2010 14:25:05 +0200 Message-ID: From: Andrea Brancatelli To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GEOM_Journal - "Taste"-order 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, 13 Oct 2010 12:49:32 -0000 Hello everybody. I'm facing a funny issue with GEOM_Journal and an ASUS MB with integrated Raid. For reason I cannot clearly understand, after creating an hardware mirror, the "standard" devices (ad0 and ad4 if I can remember correctly) didn't "disappear" and only a new device, ar0 appeared, representing the HW Mirror. I then geom_journaled a partition inside ar0, inserted geom_journal_load="YES" in the usual places but when the machine booted geom_journal found the journaling on ad0 instead of ar0 -- and actually started it! Obviously fstab was referring to ar0 and thus the boot stopped. I tried some different approaches but none worked. The only convenient way to make everything work was to disable geom_journal_load and have a script run in the end of the boot doing a gjournal load and a manual mount -- but this obviously sucks. I tried searching for a way to "disable" tasting for ad0 or ad4 or change the order of the devices so that ar0 would be tasted first, but could not find anything related. Does anyone have any suggestion? From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 15:09:57 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 173ED106564A for ; Wed, 13 Oct 2010 15:09:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 831228FC1A for ; Wed, 13 Oct 2010 15:09:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9DEXWY6068019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 17:33:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9DEXWVn083954; Wed, 13 Oct 2010 17:33:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9DEXW2X083953; Wed, 13 Oct 2010 17:33:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Oct 2010 17:33:32 +0300 From: Kostik Belousov To: Jaakko Heinonen Message-ID: <20101013143332.GC2392@deviant.kiev.zoral.com.ua> References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MQFtUQAofEP4Ac/o" Content-Disposition: inline In-Reply-To: <20101013085025.GB54686@jh> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 15:09:57 -0000 --MQFtUQAofEP4Ac/o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2010 at 11:50:26AM +0300, Jaakko Heinonen wrote: >=20 > [Posting a patch to -geom for comments.] >=20 > On 2010-10-07, Jaakko Heinonen wrote: > > Currently several GEOM classes (notably geom_label) allow to create > > devices with invalid names. Below is a link to a patch which converts > > g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not > > a complete solution and essentially changes the panic to a printf. >=20 > What do you think about this patch? >=20 > http://people.freebsd.org/~jh/patches/geom_dev-checkname.2.diff >=20 > Any better ideas how to handle this in GEOM? It doesn't seem to be > trivial to propagate an error from g_dev_taste() due to asynchronous > nature of the device registration in GEOM. You might consider creating some well-controlled name instead of failed one, and printing a diagnostic describing what happen. /dev/reservation/ could be an example, also demonstrating my lack of imagination. --MQFtUQAofEP4Ac/o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAky1wzwACgkQC3+MBN1Mb4hXbACdHwMPcm6DaXhkZfbdbAmUKjy4 fIYAn3AqkWxqBwQmzXw1Kg7TnE7IIqVt =J8XA -----END PGP SIGNATURE----- --MQFtUQAofEP4Ac/o-- From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 16:53:57 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 BA9FD106566B for ; Wed, 13 Oct 2010 16:53:57 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8446D8FC12 for ; Wed, 13 Oct 2010 16:53:57 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9DGfppA085606 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Oct 2010 09:41:52 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CB5E14B.9070308@feral.com> Date: Wed, 13 Oct 2010 09:41:47 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> In-Reply-To: <20101013085025.GB54686@jh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 13 Oct 2010 09:41:52 -0700 (PDT) Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 16:53:57 -0000 I think this seems good. Perhaps you could also fix devfs to not panic when somebody tries to make a device that already exists and just return an error with a diagnostic while you're at it? On 10/13/2010 1:50 AM, Jaakko Heinonen wrote: > [Posting a patch to -geom for comments.] > > On 2010-10-07, Jaakko Heinonen wrote: >> Currently several GEOM classes (notably geom_label) allow to create >> devices with invalid names. Below is a link to a patch which converts >> g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not >> a complete solution and essentially changes the panic to a printf. > What do you think about this patch? > > http://people.freebsd.org/~jh/patches/geom_dev-checkname.2.diff > > Any better ideas how to handle this in GEOM? It doesn't seem to be > trivial to propagate an error from g_dev_taste() due to asynchronous > nature of the device registration in GEOM. > From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 18:22:48 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 C2CE91065673 for ; Wed, 13 Oct 2010 18:22:48 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5A58FC08 for ; Wed, 13 Oct 2010 18:22:48 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id A4847151424; Wed, 13 Oct 2010 21:22:44 +0300 (EEST) Date: Wed, 13 Oct 2010 21:22:42 +0300 From: Jaakko Heinonen To: Matthew Jacob Message-ID: <20101013182242.GA1988@a91-153-123-205.elisa-laajakaista.fi> References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> <4CB5E14B.9070308@feral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB5E14B.9070308@feral.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 18:22:48 -0000 On 2010-10-13, Matthew Jacob wrote: > I think this seems good. Thanks for looking at. > Perhaps you could also fix devfs to not panic when somebody tries to > make a device that already exists and just return an error with a > diagnostic while you're at it? I am not sure if I understand what you mean with this. make_dev(9), make_dev_cred(9) and make_dev_credf(9) can't return an error code. -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 18:32:01 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 3DF0B1065672 for ; Wed, 13 Oct 2010 18:32:01 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 072EC8FC08 for ; Wed, 13 Oct 2010 18:32:00 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9DIVa9t086428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Oct 2010 11:32:00 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CB5FB05.3040609@feral.com> Date: Wed, 13 Oct 2010 11:31:33 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> <4CB5E14B.9070308@feral.com> <20101013182242.GA1988@a91-153-123-205.elisa-laajakaista.fi> In-Reply-To: <20101013182242.GA1988@a91-153-123-205.elisa-laajakaista.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 13 Oct 2010 11:32:00 -0700 (PDT) Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 18:32:01 -0000 Oh, duh. Yes, but the panic seems harsh. On 10/13/2010 11:22 AM, Jaakko Heinonen wrote: > >> Perhaps you could also fix devfs to not panic when somebody tries to >> make a device that already exists and just return an error with a >> diagnostic while you're at it? > I am not sure if I understand what you mean with this. > make_dev(9), make_dev_cred(9) and make_dev_credf(9) can't return an > error code. > From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 18:48:21 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 EAC5D106564A for ; Wed, 13 Oct 2010 18:48:21 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id A4A378FC08 for ; Wed, 13 Oct 2010 18:48:21 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id B0F8A1515CB; Wed, 13 Oct 2010 21:48:18 +0300 (EEST) Date: Wed, 13 Oct 2010 21:48:17 +0300 From: Jaakko Heinonen To: Kostik Belousov Message-ID: <20101013184817.GB1988@a91-153-123-205.elisa-laajakaista.fi> References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> <20101013143332.GC2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101013143332.GC2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 18:48:22 -0000 On 2010-10-13, Kostik Belousov wrote: > You might consider creating some well-controlled name instead of failed > one, and printing a diagnostic describing what happen. Couldn't this cause a security problem or POLA violation with devfs rules? Name based rules may be used to hide devices or change device permissions. -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Wed Oct 13 19:35:08 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 3E88F106566C; Wed, 13 Oct 2010 19:35:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A6F2D8FC12; Wed, 13 Oct 2010 19:35:07 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9DJZ3PQ095157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 22:35:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9DJZ3il085882; Wed, 13 Oct 2010 22:35:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9DJZ3I3085881; Wed, 13 Oct 2010 22:35:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Oct 2010 22:35:03 +0300 From: Kostik Belousov To: Jaakko Heinonen Message-ID: <20101013193503.GF2392@deviant.kiev.zoral.com.ua> References: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> <20101013085025.GB54686@jh> <20101013143332.GC2392@deviant.kiev.zoral.com.ua> <20101013184817.GB1988@a91-153-123-205.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LpQWWJpWf1Eem63" Content-Disposition: inline In-Reply-To: <20101013184817.GB1988@a91-153-123-205.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: HEADS UP: device name checking on device registration 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, 13 Oct 2010 19:35:08 -0000 --1LpQWWJpWf1Eem63 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2010 at 09:48:17PM +0300, Jaakko Heinonen wrote: > On 2010-10-13, Kostik Belousov wrote: > > You might consider creating some well-controlled name instead of failed > > one, and printing a diagnostic describing what happen. >=20 > Couldn't this cause a security problem or POLA violation with devfs > rules? Name based rules may be used to hide devices or change device > permissions. Fair enough. You can add a flag that allows make_dev() to do name change. This way, the rules can be applied still, before doing name change. Specific error code might be returned to inform the caller about the issue. Probably, that would require keeping the original name around, so the change may be too radical for little gain. --1LpQWWJpWf1Eem63 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAky2CecACgkQC3+MBN1Mb4ge8wCeIQwqgym3qwVhTqeDNBlxIK1f EUIAoImPOASWXVDMGinl9KmE0jNY1Rrh =equd -----END PGP SIGNATURE----- --1LpQWWJpWf1Eem63-- From owner-freebsd-geom@FreeBSD.ORG Thu Oct 14 10:09:59 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 C74B2106566B for ; Thu, 14 Oct 2010 10:09:59 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8839F8FC17 for ; Thu, 14 Oct 2010 10:09:59 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A5F4619E122; Thu, 14 Oct 2010 12:09:57 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4650C19E0B9; Thu, 14 Oct 2010 12:04:42 +0200 (CEST) Message-ID: <4CB6D5B9.9020301@quip.cz> Date: Thu, 14 Oct 2010 12:04:41 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 MIME-Version: 1.0 To: Andrea Brancatelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: GEOM_Journal - "Taste"-order 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, 14 Oct 2010 10:09:59 -0000 Andrea Brancatelli wrote: > Hello everybody. > > I'm facing a funny issue with GEOM_Journal and an ASUS MB with integrated > Raid. > > For reason I cannot clearly understand, after creating an hardware mirror, > the "standard" devices (ad0 and ad4 if I can remember correctly) didn't > "disappear" and only a new device, ar0 appeared, representing the HW Mirror. > > I then geom_journaled a partition inside ar0, inserted > geom_journal_load="YES" in the usual places but when the machine booted > geom_journal found the journaling on ad0 instead of ar0 -- and actually > started it! > > Obviously fstab was referring to ar0 and thus the boot stopped. > > I tried some different approaches but none worked. The only convenient way > to make everything work was to disable geom_journal_load and have a script > run in the end of the boot doing a gjournal load and a manual mount -- but > this obviously sucks. > > I tried searching for a way to "disable" tasting for ad0 or ad4 or change > the order of the devices so that ar0 would be tasted first, but could not > find anything related. > > Does anyone have any suggestion? It is the same issue as discussed in thread: it's a race between gmirror and UFS labels http://lists.freebsd.org/pipermail/freebsd-geom/2010-September/004381.html AFAIK there is no solution. GEOM classes are "buggy" in several things. 1] gmirror is dropping disks instead of holding them as "broken" 2] taste ordering priority 3] getting GPT even if it should be considered as "broken" (if gpt is on dropped disk from gmirror - and it can be easily detected, because there is known gmirror metadata in place where gpt/gpart is looking for secondary table) 4] impossibility of stopping gjournal tasting for some device (on systems with more then one journal, one cannot prevent loading of journal just for one device, gjournal must be stopped on all and kernel modul unloaded) This is problem for iSCSI devices (I posted about this issue 9 month ago) So some of the "nice" features (as mounting by labels instead of device names) can't be used seriously in production, because it is too risky in the case of disk failure in gmirror or in your case with ar0 RAID. Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Thu Oct 14 10:55:29 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 80DD010656C0 for ; Thu, 14 Oct 2010 10:55:29 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 344E28FC14 for ; Thu, 14 Oct 2010 10:55:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P6LT3-0000iV-V7 for freebsd-geom@freebsd.org; Thu, 14 Oct 2010 12:55:25 +0200 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 ; Thu, 14 Oct 2010 12:55:25 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Oct 2010 12:55:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Thu, 14 Oct 2010 12:55:10 +0200 Lines: 23 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: GEOM_Journal - "Taste"-order 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, 14 Oct 2010 10:55:29 -0000 On 10/13/10 14:25, Andrea Brancatelli wrote: > Hello everybody. > > I'm facing a funny issue with GEOM_Journal and an ASUS MB with integrated > Raid. > > For reason I cannot clearly understand, after creating an hardware mirror, > the "standard" devices (ad0 and ad4 if I can remember correctly) didn't > "disappear" and only a new device, ar0 appeared, representing the HW Mirror. > > I then geom_journaled a partition inside ar0, inserted > geom_journal_load="YES" in the usual places but when the machine booted > geom_journal found the journaling on ad0 instead of ar0 -- and actually > started it! > > Obviously fstab was referring to ar0 and thus the boot stopped. > > I tried some different approaches but none worked. The only convenient way Have you tried using "-h" argument to "gjournal label"? (you will need to create the gjournal on the ar0 device) From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 13:18:10 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 9CAA3106566C for ; Fri, 15 Oct 2010 13:18:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id EE3108FC14 for ; Fri, 15 Oct 2010 13:18:09 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward15.mail.yandex.net (Yandex) with ESMTP id 524E65140032; Fri, 15 Oct 2010 17:03:02 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287147782; bh=sFKr+DkrMvA1uba/THUS66gEcz2B/RWR3E6EhploFwQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=npV1Ud/kzIrcg/Yr9gAh8qOl3mfdHUtnUZGso3KMMOITvENYZECN6LunDKRbgXJb6 lSpSUoSsvIcV/z/lDdNRgD36yF0acQfkJYoEo45139MZhXj40bwOC9nH4tqIywqNU5 iVptJRkbF91aOFQc579BXUV69SyOSS6FWUpn/iKc= Received: from [10.43.163.197] (nat-77-130.kirovnet.ru [92.39.77.130]) by smtp14.mail.yandex.net (Yandex) with ESMTPSA id 8A94919B80A3; Fri, 15 Oct 2010 17:03:01 +0400 (MSD) Message-ID: <4CB850CC.4040206@yandex.ru> Date: Fri, 15 Oct 2010 17:02:04 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-geom@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2733AF13F5EA54DBBCE0745" X-Yandex-TimeMark: 1287147782 X-Yandex-Spam: 1 X-Yandex-Front: smtp14.mail.yandex.net Cc: Konstantin Belousov , Alexander Motin , Marcel Moolenaar , Pawel Jakub Dawidek Subject: [RFC][patch] GPT recovering support 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, 15 Oct 2010 13:18:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2733AF13F5EA54DBBCE0745 Content-Type: multipart/mixed; boundary="------------080108010201050905060301" This is a multi-part message in MIME format. --------------080108010201050905060301 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi All, GPT supports primary and secondary partition tables for redundancy. Some of them can be corrupted but GPART class is able to detect and work with corrupt table. Corrupt GPT should be recovered because further corruption can lead to lost ability to work with partitions. GPT's meta-data consists from primary and secondary headers and tables. Also to work with GPT first sector (LBA 0) should contains PMBR. If you have wiped first several sectors first of you should restore PMBR, otherwise GPART will not able to detect GPT even when you have proper secondary GPT header and table. Any other cases can be recovered with 'gpart recover' command. But it will work only if GPT still able to detected by GPART class. So, about patch. It add following changes: sbin/geom/class/part/geom_part.c * add recover verb to class_commands. * show "[CORRUPT]" mark for corrupt tables, for example: # gpart show =3D> 34 488397101 ad4 GPT (233G) [CORRUPT] sys/geom/part/g_part.h * add gpt_corrupt flag to struct g_part_table that indicates about detected corruption. sys/geom/part/g_part_if.m * add new kobj method G_PART_RECOVER sys/geom/part/g_part.c * implement recover verb ctl handler. * deny any modifications of corrupt tables. Only recover and destroy allowed. * add table state reporting to dumpconf. sys/geom/part/g_part_gpt.c * add new kobj method g_part_gpt_recover. * remove some spaces amd style(9) fixes. * s/tlbsz/tblsz/g for g_part_gpt_write. * teach gpt_read_hdr to read secondary GPT header from AlternateLBA. * replace magic number with macro. * before wiping last sector check that it contains secondary header. This can protect from destroying another GEOM's meta-data. * set gpt_corrupt =3D 1 when 1. Primary table or header is corrupt. 2. Secondary table or header is corrupt. 3. Secondary header is not in the last LBA. * implement g_part_gpt_recover kobj method. This method only corrects in memory copy of GPT. This changes can be committed later and all changes will be saved to disk. Since we able to call `gpart recover` we already have detected GPT and most of meta-data should be valid. When we call `gpart recover` it restores location of all 4 blobs (2 header and 2 tables). Also it corrects partitions area bounds. It seems all other information should be correct, otherwise this GPT will not be detected. TODO: * update man page; * add ability to detect GPT on medium with reduced mediasize --=20 WBR, Andrey V. Elsukov --------------080108010201050905060301 Content-Type: text/plain; name="gpart_recover.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gpart_recover.diff" Index: head/sbin/geom/class/part/geom_part.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sbin/geom/class/part/geom_part.c (revision 213888) +++ head/sbin/geom/class/part/geom_part.c (working copy) @@ -167,6 +167,11 @@ struct g_command PUBSYM(class_commands)[] =3D { G_OPT_SENTINEL }, "[-s size] -i index [-f flags] geom" }, + { "recover", 0, gpart_issue, { + { 'f', "flags", GPART_FLAGS, G_TYPE_STRING }, + G_OPT_SENTINEL }, + "[-f flags] geom" + }, G_CMD_SENTINEL }; =20 @@ -539,13 +544,17 @@ gpart_show_geom(struct ggeom *gp, const char *elem s =3D find_geomcfg(gp, "last"); last =3D (off_t)strtoimax(s, NULL, 0); wblocks =3D strlen(s); + s =3D find_geomcfg(gp, "state"); + if (s !=3D NULL && *s !=3D 'C') + s =3D NULL; wname =3D strlen(gp->lg_name); pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; secsz =3D pp->lg_sectorsize; - printf("=3D>%*jd %*jd %*s %s (%s)\n", + printf("=3D>%*jd %*jd %*s %s (%s)%s\n", wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), wname, gp->lg_name, - scheme, fmtsize(pp->lg_mediasize)); + scheme, fmtsize(pp->lg_mediasize), + s ? " [CORRUPT]": ""); =20 while ((pp =3D find_provider(gp, first)) !=3D NULL) { s =3D find_provcfg(pp, "start"); Index: head/sys/geom/part/g_part.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/geom/part/g_part.h (revision 213888) +++ head/sys/geom/part/g_part.h (working copy) @@ -132,6 +132,7 @@ struct g_part_table { int gpt_modified:1; /* Table changes have been made. */ int gpt_opened:1; /* Permissions obtained. */ int gpt_fixgeom:1; /* Geometry is fixed. */ + int gpt_corrupt:1; /* Table is corrupt. */ }; =20 struct g_part_entry *g_part_new_entry(struct g_part_table *, int, quad_t= , Index: head/sys/geom/part/g_part_if.m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/geom/part/g_part_if.m (revision 213888) +++ head/sys/geom/part/g_part_if.m (working copy) @@ -65,6 +65,12 @@ CODE { { return (ENOSYS); } + + static int + default_recover(struct g_part_table *t __unused) + { + return (ENOSYS); + } }; =20 # add() - scheme specific processing for the add verb. @@ -163,6 +169,11 @@ METHOD int read { struct g_consumer *cp; }; =20 +# recover() - scheme specific processing for the recover verb. +METHOD int recover { + struct g_part_table *table; +} DEFAULT default_recover; + # setunset() - set or unset partition entry attributes. METHOD int setunset { struct g_part_table *table; Index: head/sys/geom/part/g_part_gpt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/geom/part/g_part_gpt.c (revision 213888) +++ head/sys/geom/part/g_part_gpt.c (working copy) @@ -94,7 +94,7 @@ static int g_part_gpt_destroy(struct g_part_table static void g_part_gpt_dumpconf(struct g_part_table *, struct g_part_ent= ry *, struct sbuf *, const char *); static int g_part_gpt_dumpto(struct g_part_table *, struct g_part_entry = *); -static int g_part_gpt_modify(struct g_part_table *, struct g_part_entry = *, =20 +static int g_part_gpt_modify(struct g_part_table *, struct g_part_entry = *, struct g_part_parms *); static const char *g_part_gpt_name(struct g_part_table *, struct g_part_= entry *, char *, size_t); @@ -107,6 +107,7 @@ static const char *g_part_gpt_type(struct g_part_t static int g_part_gpt_write(struct g_part_table *, struct g_consumer *);= static int g_part_gpt_resize(struct g_part_table *, struct g_part_entry = *, struct g_part_parms *); +static int g_part_gpt_recover(struct g_part_table *); =20 static kobj_method_t g_part_gpt_methods[] =3D { KOBJMETHOD(g_part_add, g_part_gpt_add), @@ -120,6 +121,7 @@ static kobj_method_t g_part_gpt_methods[] =3D { KOBJMETHOD(g_part_name, g_part_gpt_name), KOBJMETHOD(g_part_probe, g_part_gpt_probe), KOBJMETHOD(g_part_read, g_part_gpt_read), + KOBJMETHOD(g_part_recover, g_part_gpt_recover), KOBJMETHOD(g_part_setunset, g_part_gpt_setunset), KOBJMETHOD(g_part_type, g_part_gpt_type), KOBJMETHOD(g_part_write, g_part_gpt_write), @@ -170,7 +172,7 @@ static struct uuid gpt_uuid_unused =3D GPT_ENT_TYPE_ =20 static struct g_part_uuid_alias { struct uuid *uuid; - int alias; =09 + int alias; } gpt_uuid_alias_match[] =3D { { &gpt_uuid_apple_boot, G_PART_ALIAS_APPLE_BOOT }, { &gpt_uuid_apple_hfs, G_PART_ALIAS_APPLE_HFS }, @@ -217,8 +219,16 @@ gpt_read_hdr(struct g_part_gpt_table *table, struc =20 pp =3D cp->provider; last =3D (pp->mediasize / pp->sectorsize) - 1; - table->lba[elt] =3D (elt =3D=3D GPT_ELT_PRIHDR) ? 1 : last; table->state[elt] =3D GPT_STATE_MISSING; + /* + * If the primary header is valid look for secondary + * header in AlternateLBA, otherwise in the last medium's LBA. + */ + if (elt =3D=3D GPT_ELT_SECHDR) { + if (table->state[GPT_ELT_PRIHDR] !=3D GPT_STATE_OK) + table->lba[elt] =3D last; + } else + table->lba[elt] =3D 1; buf =3D g_read_data(cp, table->lba[elt] * pp->sectorsize, pp->sectorsiz= e, &error); if (buf =3D=3D NULL) @@ -244,12 +254,15 @@ gpt_read_hdr(struct g_part_gpt_table *table, struc =20 table->state[elt] =3D GPT_STATE_INVALID; hdr->hdr_revision =3D le32toh(buf->hdr_revision); - if (hdr->hdr_revision < 0x00010000) + if (hdr->hdr_revision < GPT_HDR_REVISION) goto fail; hdr->hdr_lba_self =3D le64toh(buf->hdr_lba_self); if (hdr->hdr_lba_self !=3D table->lba[elt]) goto fail; hdr->hdr_lba_alt =3D le64toh(buf->hdr_lba_alt); + if (hdr->hdr_lba_alt =3D=3D hdr->hdr_lba_self || + hdr->hdr_lba_alt > last) + goto fail; =20 /* Check the managed area. */ hdr->hdr_lba_start =3D le64toh(buf->hdr_lba_start); @@ -283,6 +296,10 @@ gpt_read_hdr(struct g_part_gpt_table *table, struc le_uuid_dec(&buf->hdr_uuid, &hdr->hdr_uuid); hdr->hdr_crc_table =3D le32toh(buf->hdr_crc_table); =20 + /* save LBA for secondary header */ + if (elt =3D=3D GPT_ELT_PRIHDR) + table->lba[GPT_ELT_SECHDR] =3D hdr->hdr_lba_alt; + g_free(buf); return (hdr); =20 @@ -490,18 +507,20 @@ static int g_part_gpt_destroy(struct g_part_table *basetable, struct g_part_parms *= gpp) { struct g_part_gpt_table *table; + struct g_provider *pp; =20 table =3D (struct g_part_gpt_table *)basetable; - if (table->hdr !=3D NULL) - g_free(table->hdr); + pp =3D LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + g_free(table->hdr); table->hdr =3D NULL; =20 /* - * Wipe the first 2 sectors as well as the last to clear the - * partitioning. + * Wipe the first 2 sectors to clear the partitioning. Wipe the last + * sector only if it has secondary header. */ basetable->gpt_smhead |=3D 3; - basetable->gpt_smtail |=3D 1; + if (table->lba[GPT_ELT_SECHDR] =3D=3D pp->mediasize / pp->sectorsize - = 1) + basetable->gpt_smtail |=3D 1; return (0); } =20 @@ -665,10 +684,12 @@ g_part_gpt_read(struct g_part_table *basetable, st struct g_part_gpt_table *table; struct g_part_gpt_entry *entry; u_char *buf; + uint64_t last; int error, index; =20 table =3D (struct g_part_gpt_table *)basetable; pp =3D cp->provider; + last =3D (pp->mediasize / pp->sectorsize) - 1; =20 /* Read the PMBR */ buf =3D g_read_data(cp, 0, pp->sectorsize, &error); @@ -732,6 +753,7 @@ g_part_gpt_read(struct g_part_table *basetable, st printf("GEOM: %s: using the secondary instead -- recovery " "strongly advised.\n", pp->name); table->hdr =3D sechdr; + basetable->gpt_corrupt =3D 1; if (prihdr !=3D NULL) g_free(prihdr); tbl =3D sectbl; @@ -743,6 +765,11 @@ g_part_gpt_read(struct g_part_table *basetable, st "or invalid.\n", pp->name); printf("GEOM: %s: using the primary only -- recovery " "suggested.\n", pp->name); + basetable->gpt_corrupt =3D 1; + } else if (table->lba[GPT_ELT_SECHDR] !=3D last) { + printf( "GEOM: %s: the secondary GPT header is not in " + "the last LBA.\n", pp->name); + basetable->gpt_corrupt =3D 1; } table->hdr =3D prihdr; if (sechdr !=3D NULL) @@ -759,8 +786,9 @@ g_part_gpt_read(struct g_part_table *basetable, st for (index =3D basetable->gpt_entries - 1; index >=3D 0; index--) { if (EQUUID(&tbl[index].ent_type, &gpt_uuid_unused)) continue; - entry =3D (struct g_part_gpt_entry *)g_part_new_entry(basetable, =20 - index+1, tbl[index].ent_lba_start, tbl[index].ent_lba_end); + entry =3D (struct g_part_gpt_entry *)g_part_new_entry( + basetable, index + 1, tbl[index].ent_lba_start, + tbl[index].ent_lba_end); entry->ent =3D tbl[index]; } =20 @@ -769,6 +797,38 @@ g_part_gpt_read(struct g_part_table *basetable, st } =20 static int +g_part_gpt_recover(struct g_part_table *basetable) +{ + struct g_part_gpt_table *table; + struct g_provider *pp; + uint64_t last; + size_t tblsz; + + table =3D (struct g_part_gpt_table *)basetable; + pp =3D LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + last =3D pp->mediasize / pp->sectorsize - 1; + tblsz =3D (table->hdr->hdr_entries * table->hdr->hdr_entsz + + pp->sectorsize - 1) / pp->sectorsize; + + table->lba[GPT_ELT_PRIHDR] =3D 1; + table->lba[GPT_ELT_PRITBL] =3D 2; + table->lba[GPT_ELT_SECHDR] =3D last; + table->lba[GPT_ELT_SECTBL] =3D last - tblsz; + table->state[GPT_ELT_PRIHDR] =3D GPT_STATE_OK; + table->state[GPT_ELT_PRITBL] =3D GPT_STATE_OK; + table->state[GPT_ELT_SECHDR] =3D GPT_STATE_OK; + table->state[GPT_ELT_SECTBL] =3D GPT_STATE_OK; + table->hdr->hdr_lba_start =3D 2 + tblsz; + table->hdr->hdr_lba_end =3D last - tblsz - 1; + + basetable->gpt_first =3D table->hdr->hdr_lba_start; + basetable->gpt_last =3D table->hdr->hdr_lba_end; + basetable->gpt_corrupt =3D 0; + + return (0); +} + +static int g_part_gpt_setunset(struct g_part_table *table, struct g_part_entry *bas= eentry, const char *attrib, unsigned int set) { @@ -867,13 +927,13 @@ g_part_gpt_write(struct g_part_table *basetable, s struct g_part_entry *baseentry; struct g_part_gpt_entry *entry; struct g_part_gpt_table *table; - size_t tlbsz; + size_t tblsz; uint32_t crc; int error, index; =20 pp =3D cp->provider; table =3D (struct g_part_gpt_table *)basetable; - tlbsz =3D (table->hdr->hdr_entries * table->hdr->hdr_entsz + + tblsz =3D (table->hdr->hdr_entries * table->hdr->hdr_entsz + pp->sectorsize - 1) / pp->sectorsize; =20 /* Write the PMBR */ @@ -885,7 +945,7 @@ g_part_gpt_write(struct g_part_table *basetable, s return (error); =20 /* Allocate space for the header and entries. */ - buf =3D g_malloc((tlbsz + 1) * pp->sectorsize, M_WAITOK | M_ZERO); + buf =3D g_malloc((tblsz + 1) * pp->sectorsize, M_WAITOK | M_ZERO); =20 memcpy(buf, table->hdr->hdr_sig, sizeof(table->hdr->hdr_sig)); le32enc(buf + 8, table->hdr->hdr_revision); @@ -924,7 +984,7 @@ g_part_gpt_write(struct g_part_table *basetable, s le32enc(buf + 16, crc); =20 error =3D g_write_data(cp, table->lba[GPT_ELT_PRITBL] * pp->sectorsize,= - buf + pp->sectorsize, tlbsz * pp->sectorsize); + buf + pp->sectorsize, tblsz * pp->sectorsize); if (error) goto out; error =3D g_write_data(cp, table->lba[GPT_ELT_PRIHDR] * pp->sectorsize,= @@ -941,7 +1001,7 @@ g_part_gpt_write(struct g_part_table *basetable, s le32enc(buf + 16, crc); =20 error =3D g_write_data(cp, table->lba[GPT_ELT_SECTBL] * pp->sectorsize,= - buf + pp->sectorsize, tlbsz * pp->sectorsize); + buf + pp->sectorsize, tblsz * pp->sectorsize); if (error) goto out; error =3D g_write_data(cp, table->lba[GPT_ELT_SECHDR] * pp->sectorsize,= Index: head/sys/geom/part/g_part.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/geom/part/g_part.c (revision 213888) +++ head/sys/geom/part/g_part.c (working copy) @@ -1037,8 +1037,39 @@ g_part_ctl_move(struct gctl_req *req, struct g_par= static int g_part_ctl_recover(struct gctl_req *req, struct g_part_parms *gpp) { - gctl_error(req, "%d verb 'recover'", ENOSYS); - return (ENOSYS); + struct g_part_table *table; + struct g_geom *gp; + struct sbuf *sb; + int error, recovered; + + gp =3D gpp->gpp_geom; + G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__, gp->name)); + g_topology_assert(); + table =3D gp->softc; + error =3D recovered =3D 0; + + if (table->gpt_corrupt) { + error =3D G_PART_RECOVER(table); + if (error) { + gctl_error(req, "%d recovering '%s' failed", + error, gp->name); + return (error); + } + recovered =3D 1; + } + /* Provide feedback if so requested. */ + if (gpp->gpp_parms & G_PART_PARM_OUTPUT) { + sb =3D sbuf_new_auto(); + if (recovered) + sbuf_printf(sb, "%s recovered\n", gp->name); + else + sbuf_printf(sb, "%s recovering is not needed\n", + gp->name); + sbuf_finish(sb); + gctl_set_param(req, "output", sbuf_data(sb), sbuf_len(sb) + 1); + sbuf_delete(sb); + } + return (0); } =20 static int @@ -1524,6 +1555,13 @@ g_part_ctlreq(struct gctl_req *req, struct g_class= table =3D NULL; if (modifies && (gpp.gpp_parms & G_PART_PARM_GEOM)) { table =3D gpp.gpp_geom->softc; + if (table !=3D NULL && table->gpt_corrupt && + ctlreq !=3D G_PART_CTL_DESTROY && + ctlreq !=3D G_PART_CTL_RECOVER) { + gctl_error(req, "%d table '%s' is corrupt", + EPERM, gpp.gpp_geom->name); + return; + } if (table !=3D NULL && !table->gpt_opened) { error =3D g_access(LIST_FIRST(&gpp.gpp_geom->consumer), 1, 1, 1); @@ -1789,6 +1827,8 @@ g_part_dumpconf(struct sbuf *sb, const char *inden table->gpt_sectors); sbuf_printf(sb, "%s%u\n", indent, table->gpt_heads); + sbuf_printf(sb, "%s%s\n", indent, + table->gpt_corrupt ? "CORRUPT": "OK"); G_PART_DUMPCONF(table, NULL, sb, indent); } } --------------080108010201050905060301-- --------------enigD2733AF13F5EA54DBBCE0745 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMuFDVAAoJEAHF6gQQyKF6tp0H/3YSJg/33q9gSIUDgm7FFqvU Pm/iu97RlwiDhs7dFHjG7rEJWYqmwjxdpP4LMX72/wz1qY4E2cUwDS0LEBQAft4o syr4V0/+uQpUXjRDOjNMtVkgkLYMlaQvk/Bnqp4pFf5t/sBoS3BxKIc9U1obc/MP fpPZWKOUgiZA/QMZlqQyYRUGV0U2xolZgsXK5K2NSb6mz+GrViMbiiDVnyB3AxHL uutmU/7pQkinTDyEzFbLjPfxnPoHPjgLf48xbgCBLliWgVMlMZBAWnb4PSt3pLw2 chodCgf3z8wuhbLY3ov1AyNB3KqoRGl7LJV+Ow3gT5Zw+Rxm//GLesIyPkz2wZg= =7oN9 -----END PGP SIGNATURE----- --------------enigD2733AF13F5EA54DBBCE0745-- From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 13:35: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 E10191065695; Fri, 15 Oct 2010 13:35:46 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 88F1B8FC08; Fri, 15 Oct 2010 13:35:46 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward5.mail.yandex.net (Yandex) with ESMTP id 9B06814D0BA4; Fri, 15 Oct 2010 17:35:44 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287149744; bh=uH1OEmY6XBJkwYKjzW/qiPSs8E3p/Cpxgpam6hP6Iqk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=S5bauVczKBATkSL4k+2zddIc4ThD1l4N8CQpVdBUBnHqPSmKdJCo2+qnuz6nAXBgH TNLBJzcJ85qenF192HONowIoVIVHqoPMQPSeWqtahuHksnGVUANQIgbo2nfnZ95Mnl emR2OEqOJKgGg505qLaPkzLRVwONUdjFcQ8GOWIw= Received: from [10.43.163.197] (nat-77-150.kirovnet.ru [92.39.77.150]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 0DBDC29008E; Fri, 15 Oct 2010 17:35:43 +0400 (MSD) Message-ID: <4CB8587F.3010401@yandex.ru> Date: Fri, 15 Oct 2010 17:34:55 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4CB850CC.4040206@yandex.ru> In-Reply-To: <4CB850CC.4040206@yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB3C37BED81F79C00C78F885E" X-Yandex-TimeMark: 1287149744 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: Pawel Jakub Dawidek , Alexander Motin , Marcel Moolenaar , Konstantin Belousov Subject: Re: [RFC][patch] GPT recovering support 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, 15 Oct 2010 13:35:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB3C37BED81F79C00C78F885E Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.10.2010 17:02, Andrey V. Elsukov wrote: > * deny any modifications of corrupt tables. Only recover and destroy > allowed. Oops. "gpart destroy" needs to allow "gpart delete"... So, maybe "gpart destroy" should be denied too? --=20 WBR, Andrey V. Elsukov --------------enigB3C37BED81F79C00C78F885E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMuFh/AAoJEAHF6gQQyKF6H6MIAIWkoh4Enr08A5RhsjZTFpra IwI7s1K/Em0sP6LdUxwj0DUgXZoGcxBHhVmdAbbB6yq9DuzCv/hNEoYgGCFmQWvu W1Kbt1o2OX8n/6xnS0BqGWSSw0WgpEB4fNxwMWZon46mfjRVfG7ncSXG2ES9KKsc vrggaQJLyWCEsNpvHsmLPFblsVU3OY6PJjKuLpiKXHDPoHUm8tfv2el2jG87eJyS CLYjZ4/mZXe7vvsD0x6PjFkSeiCfqzeAa0yF73LJuP17NyjqQC7VyXRMaj3jz6cg yobd+0j0BaxLIICra8TxpmxnJ/t6mvCsGgCblaAbOgbyiAZFfRibEMpcOa38WwU= =HolW -----END PGP SIGNATURE----- --------------enigB3C37BED81F79C00C78F885E-- From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 13:44:28 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 939A2106566C for ; Fri, 15 Oct 2010 13:44:28 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 147138FC19 for ; Fri, 15 Oct 2010 13:44:27 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id o9FDi5K7005820 for ; Fri, 15 Oct 2010 16:44:05 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id o9FDi5Om005819 for freebsd-geom@freebsd.org; Fri, 15 Oct 2010 16:44:05 +0300 (EEST) Date: Fri, 15 Oct 2010 16:44:05 +0300 From: Zeus V Panchenko To: freebsd-geom@freebsd.org Message-ID: <20101015134405.GI19196@relay.ibs.dn.ua> References: <20100914180729.GC92933@relay.ibs.dn.ua> <201009150956.o8F9uiLh088066@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201009150956.o8F9uiLh088066@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: storage configuration for Advanced Format 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, 15 Oct 2010 13:44:28 -0000 may somebody help to understand `Sectorsize: 512' while hdd is GPT configured as was written in the first post, please? # gpart list Geom name: ad6 fwheads: 16 fwsectors: 63 last: 1953525134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad6p1 Mediasize: 1000203091968 (932G) Sectorsize: 512 Mode: r1w1e1 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1000203091968 offset: 1048576 type: freebsd-ufs index: 1 end: 1953523711 start: 2048 Consumers: 1. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e2 -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 15:44:39 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 1BEFB1065670 for ; Fri, 15 Oct 2010 15:44:39 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6AA8FC0C for ; Fri, 15 Oct 2010 15:44:38 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9FFiLEM056493; Fri, 15 Oct 2010 17:44:36 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9FFiL3N056492; Fri, 15 Oct 2010 17:44:21 +0200 (CEST) (envelope-from olli) Date: Fri, 15 Oct 2010 17:44:21 +0200 (CEST) Message-Id: <201010151544.o9FFiL3N056492@lurza.secnetix.de> From: Oliver Fromme To: freebsd-geom@FreeBSD.ORG, zeus@ibs.dn.ua In-Reply-To: <20101015134405.GI19196@relay.ibs.dn.ua> X-Newsgroups: list.freebsd-geom User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Fri, 15 Oct 2010 17:44:37 +0200 (CEST) Cc: Subject: Re: storage configuration for Advanced Format X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-geom@FreeBSD.ORG, zeus@ibs.dn.ua List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 15:44:39 -0000 Zeus V Panchenko wrote: > may somebody help to understand `Sectorsize: 512' while hdd is GPT > configured as was written in the first post, please? Because the sectorsize _is_ 512 bytes, as seen by the OS. I don't see how the commands from your first post in this thread could change that. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 17:16:28 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 4A4C4106564A for ; Fri, 15 Oct 2010 17:16:28 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 2F81A8FC08 for ; Fri, 15 Oct 2010 17:16:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LAC00LWCAHRSM40@asmtp030.mac.com>; Fri, 15 Oct 2010 09:15:29 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010150108 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-15_08:2010-10-15, 2010-10-15, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4CB8587F.3010401@yandex.ru> Date: Fri, 15 Oct 2010 09:15:27 -0700 Message-id: References: <4CB850CC.4040206@yandex.ru> <4CB8587F.3010401@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1081) Cc: Pawel Jakub Dawidek , Alexander Motin , Marcel Moolenaar , Konstantin Belousov , freebsd-geom@freebsd.org Subject: Re: [RFC][patch] GPT recovering support 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, 15 Oct 2010 17:16:28 -0000 On Oct 15, 2010, at 6:34 AM, Andrey V. Elsukov wrote: > On 15.10.2010 17:02, Andrey V. Elsukov wrote: >> * deny any modifications of corrupt tables. Only recover and destroy >> allowed. > > Oops. "gpart destroy" needs to allow "gpart delete"... > So, maybe "gpart destroy" should be denied too? Deletion of a partition is the same as modifying the partition table. I would not allow deletion because it creates fuzziness in the interface. It's better to implement a force option to destroy that forces a scheme to be destroyed in a way that prevents undo. This allows you to (effectively) wipe sectors and start over. This is exactly what you want if you're stuck with a detected scheme that is corrupt to the point that you can't do anything with it. It would be good if you can list the corruption cases that are being handled and how you recover. While we need to be friendly to the GEOM flexibility, we do need to respect the GPT spec to the extend that we remain compatible. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 19:04:47 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 EF1CA106564A for ; Fri, 15 Oct 2010 19:04:47 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 66DF68FC08 for ; Fri, 15 Oct 2010 19:04:45 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id o9FJ4Oa6039124; Fri, 15 Oct 2010 22:04:24 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id o9FJ4OYx039123; Fri, 15 Oct 2010 22:04:24 +0300 (EEST) Date: Fri, 15 Oct 2010 22:04:24 +0300 From: Zeus V Panchenko To: freebsd-geom@freebsd.org, olli@lurza.secnetix.de Message-ID: <20101015190424.GA5836@relay.ibs.dn.ua> References: <20101015134405.GI19196@relay.ibs.dn.ua> <201010151544.o9FFiL3N056492@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201010151544.o9FFiL3N056492@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Cc: Subject: Re: storage configuration for Advanced Format X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus.panchenko@gmail.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:04:48 -0000 Oliver Fromme (olli@lurza.secnetix.de) [10.10.15 18:44] wrote: > > Because the sectorsize _is_ 512 bytes, as seen by the OS. > I don't see how the commands from your first post in this > thread could change that. > oops, sorry :( than i have to change the initial question ... what is the correct way to configure hard drive to get the advantagge of the `Advanced Format'? fix the list of commands from initial post, please ... -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-geom@FreeBSD.ORG Fri Oct 15 19:54:02 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 3CA2F106564A for ; Fri, 15 Oct 2010 19:54:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 584A88FC0C for ; Fri, 15 Oct 2010 19:54:01 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9FJrit0067667; Fri, 15 Oct 2010 21:54:00 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9FJriDG067666; Fri, 15 Oct 2010 21:53:44 +0200 (CEST) (envelope-from olli) Date: Fri, 15 Oct 2010 21:53:44 +0200 (CEST) Message-Id: <201010151953.o9FJriDG067666@lurza.secnetix.de> From: Oliver Fromme To: freebsd-geom@FreeBSD.ORG, zeus.panchenko@gmail.com In-Reply-To: <20101015190424.GA5836@relay.ibs.dn.ua> X-Newsgroups: list.freebsd-geom User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Fri, 15 Oct 2010 21:54:00 +0200 (CEST) Cc: Subject: Re: storage configuration for Advanced Format X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-geom@FreeBSD.ORG, zeus.panchenko@gmail.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:54:02 -0000 Zeus V Panchenko wrote: > Oliver Fromme (olli@lurza.secnetix.de) [10.10.15 18:44] wrote: > > Because the sectorsize _is_ 512 bytes, as seen by the OS. > > I don't see how the commands from your first post in this > > thread could change that. > > oops, sorry :( > > than i have to change the initial question ... > > what is the correct way to configure hard drive to get the advantagge > of the `Advanced Format'? Which advantage do you mean, exactly? I can only see advantages for the disk manufacturers: They can use a new buzzword in marketing, they can increase the data density on the disk platters (which means more revenue for them), and they can still use 32bit sector numbers in the disk firmware, which probably makes things a bit easier and cheaper for them. I don't see any advantages for the customers. At least not with the currently existing disks. > fix the list of commands from initial post, please ... The commands are good. There's nothing to fix. The important thing is that every access should be aligned on 4 KB boundaries. So you should make sure that your partitions are all aligned properly, and that the fragment size of your file systems is at least 4 KB. Your commands do that correctly. (The reason is: If you write to a block that is not 4 KB aligned, the drive has to read the affected 4 KB sector first, modify it, then write it back. This is inefficient, of course.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "People still program in C. People keep writing shell scripts. *Most* people don't realize the shortcomings of the tools they are using because they a) don't reflect on their workflows and they are b) too lazy to check out alternatives to realize there is help." -- Simon 'corecode' Schubert