From owner-freebsd-geom@FreeBSD.ORG Sun Jan 16 12:11:50 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0A0BB1065672; Sun, 16 Jan 2011 12:11:50 +0000 (UTC) Date: Sun, 16 Jan 2011 12:11:50 +0000 From: Alexander Best To: freebsd-geom@freebsd.org Message-ID: <20110116121150.GA95957@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 'geom part status' reporting corruption every time i boot a foreign OS from CD/DVD 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, 16 Jan 2011 12:11:50 -0000 hi there, i noticed that after booting the chromeOS, ubuntu, etc. live cds/dvds and afterwards booting freebsd, 'geom part status' reports a corruption for ada0p1: Name Status Components ada0p1 OK ada0 ada1p1 OK ada1 usually the corruption dissapears after another reboot. iirc the issue was that the backup gpt data got corrupted. why do the live cds/dvds even write data to my hdd? did anybody else experience this issue too? cheers. alex -- a13x From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 11:06:59 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D229510656A3 for ; Mon, 17 Jan 2011 11:06:59 +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 C076C8FC19 for ; Mon, 17 Jan 2011 11:06:59 +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 p0HB6xO6048887 for ; Mon, 17 Jan 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0HB6xT4048885 for freebsd-geom@FreeBSD.org; Mon, 17 Jan 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Jan 2011 11:06:59 GMT Message-Id: <201101171106.p0HB6xT4048885@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, 17 Jan 2011 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/152609 geom [geli] geli onetime on gzero panics o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/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 o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o 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 o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o bin/120990 geom [patch] support "BIOS Boot" partition type in gpt(8) o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/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. 56 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 13:18:07 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE15A106564A for ; Mon, 17 Jan 2011 13:18:07 +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 63CC78FC08 for ; Mon, 17 Jan 2011 13:18:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PeoyC-00077m-PD for freebsd-geom@freebsd.org; Mon, 17 Jan 2011 14:18:04 +0100 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 ; Mon, 17 Jan 2011 14:18:04 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jan 2011 14:18:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 17 Jan 2011 14:17:53 +0100 Lines: 33 Message-ID: References: <1686083494.20110113182418@serebryakov.spb.ru> 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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <1686083494.20110113182418@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? 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, 17 Jan 2011 13:18:07 -0000 On 13/01/2011 16:24, Lev Serebryakov wrote: > Hello, Freebsd-geom. > > > I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS with > label on it. This label is shown in /dev/ufs when geom_mirror is > loaded. > > When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid, > complete, clean filesystems, but here is no /dev/ufs entries for them, > and kernel can not mount FSes at all. It's because glabel checks file system size information in the UFS and doesn't create the label if it doesn't match. 88 } else if (fs->fs_magic == FS_UFS2_MAGIC && fs->fs_fsize > 0 && 89 pp->mediasize / fs->fs_fsize == fs->fs_size) { 90 /* Valid UFS2. */ 91 } else { It was done to try and prevent exactly the problem you describe - the abuse of nested GEOM devices. In this case, gmirror takes one sector from the device and so the UFS metadata size doesn't match device size if it's looked at from outside gmirror. mount(8) doesn't check this so you can mount the device from outside gmirror. > Is it because two filesystems have the same label? How this > situation should be solved to allow system boot with broken mirror? "Broken mirror" means /dev/mirror/something will still be visible but it will be backed by only one physical device. It does not usually mean "gmirror metadata is broken" because it can trivially be recreated. From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 13:31:00 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 939101065673 for ; Mon, 17 Jan 2011 13:31:00 +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 48C4C8FC0A for ; Mon, 17 Jan 2011 13:31:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PepAg-00050a-Vp for freebsd-geom@freebsd.org; Mon, 17 Jan 2011 14:30:59 +0100 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 ; Mon, 17 Jan 2011 14:30:58 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jan 2011 14:30:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 17 Jan 2011 14:30:43 +0100 Lines: 30 Message-ID: References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <1811347380.20110113213700@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? 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, 17 Jan 2011 13:31:00 -0000 On 13/01/2011 19:37, Lev Serebryakov wrote: > Hello, Freebsd-geom. > You wrote 13 января 2011 г., 18:24:18: > >> I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS with >> label on it. This label is shown in /dev/ufs when geom_mirror is >> loaded. > >> When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid, >> complete, clean filesystems, but here is no /dev/ufs entries for them, >> and kernel can not mount FSes at all. > And even worse: it sees ONE of all FSes and when "geom_mirror" is > loaded, it puck up one of components from "/dev/ufs/home" instead of > device node and everything hangs up due to loop (?)... Yes, gmirror and glabel are known to interact badly because of such edge cases - since glabel presents the whole underlying device in pretty much the same way as the original device entry, gmirror cannot distinguish between the two. You could use the "-h" argument to "gmirror create" to get around this. Since this is so common and has also bitten me in the past, I wonder if some kind of avoidance detection mechanism could be created in gmirror? I'm thinking of making glabel expose a GEOM property like "fslabel" meaning "this device entry comes from a file system label, not a device or native glabel label" and making gmirror search for this property and skip tasting for devices having it? Pawel? From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 13:39:26 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DAF1106564A for ; Mon, 17 Jan 2011 13:39:26 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id BCCAC8FC08 for ; Mon, 17 Jan 2011 13:39:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 2B3B813DF5F; Mon, 17 Jan 2011 16:39:24 +0300 (MSK) Date: Mon, 17 Jan 2011 16:39:22 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <234432652.20110117163922@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? 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, 17 Jan 2011 13:39:26 -0000 Hello, Ivan. You wrote 17 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2011 =D0=B3., 16:30:43: >>> I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS with >>> label on it. This label is shown in /dev/ufs when geom_mirror is >>> loaded. >> >>> When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid, >>> complete, clean filesystems, but here is no /dev/ufs entries for them, >>> and kernel can not mount FSes at all. >> And even worse: it sees ONE of all FSes and when "geom_mirror" is >> loaded, it puck up one of components from "/dev/ufs/home" instead of >> device node and everything hangs up due to loop (?)... > Yes, gmirror and glabel are known to interact badly because of such edge > cases - since glabel presents the whole underlying device in pretty much > the same way as the original device entry, gmirror cannot distinguish=20 > between the two. You could use the "-h" argument to "gmirror create" to > get around this. > Since this is so common and has also bitten me in the past, I wonder if > some kind of avoidance detection mechanism could be created in gmirror? I think, it will be better if geom_label will create ufs/ufsid items always (even if FS size is smaller that it's container (provider) size), but create providers only as big as FS itself. It this case geom_mirror will never see its metadata inside "UFS-based" providers and geom_label will show FS labels even it it inside mirror when geom_mirror is not loaded at all. Both problems are solved with one solution :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 13:47:02 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D58106566B for ; Mon, 17 Jan 2011 13:47:02 +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 C3A5B8FC0A for ; Mon, 17 Jan 2011 13:47:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PepQB-0004oL-Cv for freebsd-geom@freebsd.org; Mon, 17 Jan 2011 14:46:59 +0100 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 ; Mon, 17 Jan 2011 14:46:59 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jan 2011 14:46:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 17 Jan 2011 14:46:46 +0100 Lines: 33 Message-ID: References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> <234432652.20110117163922@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <234432652.20110117163922@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? 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, 17 Jan 2011 13:47:02 -0000 On 17/01/2011 14:39, Lev Serebryakov wrote: > Hello, Ivan. > You wrote 17 января 2011 г., 16:30:43: > >>>> I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS with >>>> label on it. This label is shown in /dev/ufs when geom_mirror is >>>> loaded. >>> >>>> When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid, >>>> complete, clean filesystems, but here is no /dev/ufs entries for them, >>>> and kernel can not mount FSes at all. >>> And even worse: it sees ONE of all FSes and when "geom_mirror" is >>> loaded, it puck up one of components from "/dev/ufs/home" instead of >>> device node and everything hangs up due to loop (?)... >> Yes, gmirror and glabel are known to interact badly because of such edge >> cases - since glabel presents the whole underlying device in pretty much >> the same way as the original device entry, gmirror cannot distinguish >> between the two. You could use the "-h" argument to "gmirror create" to >> get around this. >> Since this is so common and has also bitten me in the past, I wonder if >> some kind of avoidance detection mechanism could be created in gmirror? > > I think, it will be better if geom_label will create ufs/ufsid items > always (even if FS size is smaller that it's container (provider) > size), but create providers only as big as FS itself. It this case > geom_mirror will never see its metadata inside "UFS-based" providers > and geom_label will show FS labels even it it inside mirror when > geom_mirror is not loaded at all. Both problems are solved with one > solution :) Ah but you see - the UFS metadata *does* record the correct file system size - and this size spans the entire container, just like /dev/adXsY etc. - so both glabel and gmirror behave correctly. From owner-freebsd-geom@FreeBSD.ORG Mon Jan 17 14:09:06 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCBF71065672; Mon, 17 Jan 2011 14:09:05 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66CF08FC1E; Mon, 17 Jan 2011 14:09:05 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 5FC2413DF5F; Mon, 17 Jan 2011 17:09:04 +0300 (MSK) Date: Mon, 17 Jan 2011 17:09:02 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1211987575.20110117170902@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> <234432652.20110117163922@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? 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, 17 Jan 2011 14:09:06 -0000 Hello, Ivan. You wrote 17 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2011 =D0=B3., 16:46:46: >>>>> I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS wi= th >>>>> label on it. This label is shown in /dev/ufs when geom_mirror is >>>>> loaded. >>>> >>>>> When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid, >>>>> complete, clean filesystems, but here is no /dev/ufs entries for them, >>>>> and kernel can not mount FSes at all. >>>> And even worse: it sees ONE of all FSes and when "geom_mirror" is >>>> loaded, it puck up one of components from "/dev/ufs/home" instead = of >>>> device node and everything hangs up due to loop (?)... >>> Yes, gmirror and glabel are known to interact badly because of such edge >>> cases - since glabel presents the whole underlying device in pretty much >>> the same way as the original device entry, gmirror cannot distinguish >>> between the two. You could use the "-h" argument to "gmirror create" to >>> get around this. >>> Since this is so common and has also bitten me in the past, I wonder if >>> some kind of avoidance detection mechanism could be created in gmirror? >> >> I think, it will be better if geom_label will create ufs/ufsid items >> always (even if FS size is smaller that it's container (provider) >> size), but create providers only as big as FS itself. It this case >> geom_mirror will never see its metadata inside "UFS-based" providers >> and geom_label will show FS labels even it it inside mirror when >> geom_mirror is not loaded at all. Both problems are solved with one >> solution :) > Ah but you see - the UFS metadata *does* record the correct file system > size - and this size spans the entire container, just like /dev/adXsY=20 > etc. - so both glabel and gmirror behave correctly. No, no, no. Here is example. Let imagine /dev/ad0s1a and /dev/ad1s1a both have, say, 1024 sectors. They are mirrored as "mirror/rootfs". It should have size 1023 sectors, am I right? 1 sector is spent on metadata and can not be accessed via /dev/mirror/gm0. UFS2 is created on /dev/mirror/gm0, with volume label "rootfs" so it records file system size as "1023 sectors", Ok? When geom_mirror is loaded and "win" tasting of ad?s1a, geom_label reads label from /dev/mirror/gm0 and shows proper "/dev/ufs/rootfs" and "/dev/ufsid/whatever" with proper sizes "1023 sectors". When geom_mirror is not loaded, but geom_label is, now it will not show "/dev/ufs/rootfs" because ad?s1a.size !=3D rootf.size, am I right? If change geom_label to create labels in such cases (simply remove sizes check in current code), there will be problem with geom_mirror loaded AFTER geom_label -- it could pickup mirror component via label, not via device itself. But if we remove this check AND change geom_label in such way, as it will create provider based on UFS size (not underlying provider size), it will work always. When there is no geom_mirror labels will be created but it will be impossible to pickup such label as component of mirror, because label-provider will not contain mirror metadata. And there is one more problem: it is almost always possible to create mirror AFTER file system (add mirror to existing installation without re-creating FSes), but it will have incorrect FS size in metadata and here is no way to "shrink" FS even with one sector. And, yes, it such case current geom_label implementation will create labels from mirror components (size check will be passed), and allows geom_mirror to use labels as components. Complete mess :( And creation mirror on live system looks like useful feature. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Tue Jan 18 07:32:56 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607621065673; Tue, 18 Jan 2011 07:32:56 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 376218FC1A; Tue, 18 Jan 2011 07:32:56 +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 p0I7WufQ095044; Tue, 18 Jan 2011 07:32:56 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0I7Wu5l095035; Tue, 18 Jan 2011 07:32:56 GMT (envelope-from ae) Date: Tue, 18 Jan 2011 07:32:56 GMT Message-Id: <201101180732.p0I7Wu5l095035@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-geom@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/144962: [geom] panic when accessing GPT disk with a large number of entries X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:32:56 -0000 Synopsis: [geom] panic when accessing GPT disk with a large number of entries Responsible-Changed-From-To: freebsd-geom->ae Responsible-Changed-By: ae Responsible-Changed-When: Tue Jan 18 07:32:31 UTC 2011 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=144962 From owner-freebsd-geom@FreeBSD.ORG Tue Jan 18 17:14:25 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090A91065670 for ; Tue, 18 Jan 2011 17:14:25 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2E448FC12 for ; Tue, 18 Jan 2011 17:14:24 +0000 (UTC) Received: by yxh35 with SMTP id 35so2469881yxh.13 for ; Tue, 18 Jan 2011 09:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=gvZCY5VFtocaVZ7h2B48v+omMlmbU6ntYYrCpJ9nNY4=; b=fCLCtTu8qrHmExGp7n4J5K56QsIIKBYhi1oUiLLsATOi4NGA2UndzElNW0jkmGglMe OFAs3qCaOg02w6NaGyyCKYqgT+nuWoR/zlnj+J/TP53dOj61Hn9MmBY+/IhapD5giPx1 Qrv9D+uuXvUR6viNheW0AgpTqFGw7N0EWhAdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=qyfk6QODtbpc7pIKmVzGseVBnwRsO9TwtLX0AcAxySjG25Wl6RICuHTOfyF7BlD9OT J/IqAaUx0Lp2xyjI5RA0DwZGf/+PLs4H3h93bAoJkfNrCVBzmHM1zxUMyraOrNEtuahr +pR7WXihT7WvfXL7PCFg6UYqLgZ/tPw9uBJq8= Received: by 10.151.78.6 with SMTP id f6mr1256055ybl.41.1295369432522; Tue, 18 Jan 2011 08:50:32 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.150.182.16 with HTTP; Tue, 18 Jan 2011 08:49:52 -0800 (PST) In-Reply-To: <1211987575.20110117170902@serebryakov.spb.ru> References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> <234432652.20110117163922@serebryakov.spb.ru> <1211987575.20110117170902@serebryakov.spb.ru> From: Ivan Voras Date: Tue, 18 Jan 2011 17:49:52 +0100 X-Google-Sender-Auth: R6VlCjcPAEOX5o8egUHopABYbG4 Message-ID: To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:14:25 -0000 On 17 January 2011 15:09, Lev Serebryakov wrote: > =C2=A0 Let imagine /dev/ad0s1a and /dev/ad1s1a both have, say, 1024 > =C2=A0sectors. They are mirrored as "mirror/rootfs". It should have size > =C2=A01023 sectors, am I right? 1 sector is spent on metadata and can not= be > =C2=A0accessed via /dev/mirror/gm0. > > =C2=A0 UFS2 is created on /dev/mirror/gm0, with volume label "rootfs" > =C2=A0so it records file system size as "1023 sectors", Ok? Well... it depends. As I see it, the UFS file system size is calculated based on block size, so the actual size would not be 1024, but 1024-32 or something like that, which brings me to the next point... > =C2=A0 When geom_mirror is loaded and "win" tasting of ad?s1a, geom_label > =C2=A0reads label from /dev/mirror/gm0 and shows proper > =C2=A0"/dev/ufs/rootfs" and "/dev/ufsid/whatever" with proper sizes "1023 > =C2=A0sectors". > > =C2=A0 When geom_mirror is not loaded, but geom_label is, now it will not > =C2=A0show "/dev/ufs/rootfs" because ad?s1a.size !=3D rootf.size, am I ri= ght? > > =C2=A0 If change geom_label to create labels in such cases (simply remove > =C2=A0sizes check in current code), there will be problem with geom_mirro= r > =C2=A0loaded AFTER geom_label -- it could pickup mirror component via > =C2=A0label, not via device itself. > > =C2=A0 But if we remove this check AND change geom_label in such way, as > =C2=A0it will create provider based on UFS size (not underlying provider > =C2=A0size), it will work always. When there is no geom_mirror labels wil= l > =C2=A0be created but it will be impossible to pickup such label as > =C2=A0component of mirror, because label-provider will not contain mirror > =C2=A0metadata. I don't think this is a general enough solution. Other file systems than UFS may not record file system size at all, or maybe record it even more inprecisely than UFS. Additionally, glabel would have to be restructured a bit to support that. > =C2=A0 And there is one more problem: it is almost always possible to > =C2=A0create mirror AFTER file system (add mirror to existing installatio= n > =C2=A0without re-creating FSes), but it will have incorrect FS size in > =C2=A0metadata and here is no way to "shrink" FS even with one sector. An= d, > =C2=A0yes, it such case current geom_label implementation will create > =C2=A0labels from mirror components (size check will be passed), and allo= ws > =C2=A0geom_mirror to use labels as components. Complete mess :( And > =C2=A0creation mirror on live system looks like useful feature. I think this would be solved by my other proposal :) From owner-freebsd-geom@FreeBSD.ORG Wed Jan 19 11:33:14 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67FDE1065673; Wed, 19 Jan 2011 11:33:14 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id E2F958FC12; Wed, 19 Jan 2011 11:33:12 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1PfVdo-0008Po-Dq; Wed, 19 Jan 2011 12:51:52 +0200 Date: Wed, 19 Jan 2011 12:54:07 +0200 From: Alexandr Rybalko To: freebsd-geom@FreeBSD.org, freebsd-embedded@FreeBSD.org Message-Id: <20110119125407.be7669b9.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__19_Jan_2011_12_54_07_+0200_WwbCDRav.8r6rhoc" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GEOM_LZMA 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, 19 Jan 2011 11:33:14 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__19_Jan_2011_12_54_07_+0200_WwbCDRav.8r6rhoc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I`m happy to introduce GEOM_ULZMA module and utilitie to create an ulzma image. Think now it in acceptable for testing/reviewing/committing state. Wait for your questions. :) Add xz-embedded to contrib: http://my.ddteam.net/files/add_contrib_xz-embedded.patch Add geom/ulzma/g_ulzma.c and usr.bin/mkulzma: http://my.ddteam.net/files/geom_ulzma_and_mkulzma.patch WBW -- Alexandr Rybalko aka Alex RAY --Multipart=_Wed__19_Jan_2011_12_54_07_+0200_WwbCDRav.8r6rhoc-- From owner-freebsd-geom@FreeBSD.ORG Thu Jan 20 04:53:06 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5518106564A for ; Thu, 20 Jan 2011 04:53:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2C98FC19 for ; Thu, 20 Jan 2011 04:53:06 +0000 (UTC) Received: by qwj9 with SMTP id 9so196837qwj.13 for ; Wed, 19 Jan 2011 20:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TOjXoEhxvh8Xp6JnIQ2BaLA4IdCnciGrzx6yxWRByPE=; b=FVuVN+KatradaTAGGQ8YRSiZDicqC+I25+U830SPlDCAiGXpKBdhrl7QsCcWatgQUo G7yFy843DpSKLIi4sfugxLnknc8iT+MMTGyuEtxjZsCUZvKWP13R+5xpNzvzwiibKy3W 7fYFlliA2csDUYr4Toe15GU0qCAgF2frggKhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ptR9/Tz504g9vttIPkhaaagH9als/xwiGI1aeuBZ4sfrSXVbPTGmEV02Fin5LSSJNa FWZTstYSg//6r7StuWg1yniLMhy6i9z4VY3AiHpkCjtXkyUtVzBNn3ubUYLXlXlf58nc W03PHEbQrhhLAD8CNdoeHg8a6RXG39ttcHZ2M= MIME-Version: 1.0 Received: by 10.224.19.203 with SMTP id c11mr1478287qab.170.1295497863506; Wed, 19 Jan 2011 20:31:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.198.203 with HTTP; Wed, 19 Jan 2011 20:31:03 -0800 (PST) In-Reply-To: <20110119125407.be7669b9.ray@dlink.ua> References: <20110119125407.be7669b9.ray@dlink.ua> Date: Thu, 20 Jan 2011 12:31:03 +0800 X-Google-Sender-Auth: 4wZPDTGqZMBD3JCbyvrqLR1OpRQ Message-ID: From: Adrian Chadd To: Alexandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 20 Jan 2011 04:53:07 -0000 On 19 January 2011 18:54, Alexandr Rybalko wrote: > Hi, > > I`m happy to introduce GEOM_ULZMA module and utilitie to create an ulzma image. > > Think now it in acceptable for testing/reviewing/committing state. > > Wait for your questions. :) I like it. I'd like to see the ulzma and gz stuff unified in a later pass of this code but personally I'm happy to have it committed as-is so it immediately gets some wider exposure. Adrian From owner-freebsd-geom@FreeBSD.ORG Thu Jan 20 08:50:12 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4111065670 for ; Thu, 20 Jan 2011 08:50:12 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 58C1C8FC17 for ; Thu, 20 Jan 2011 08:50:11 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C176345F27; Thu, 20 Jan 2011 09:50:09 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F11E345F25; Thu, 20 Jan 2011 09:50:03 +0100 (CET) Date: Thu, 20 Jan 2011 09:49:55 +0100 From: Pawel Jakub Dawidek To: Adrian Chadd Message-ID: <20110120084955.GD1716@garage.freebsd.pl> References: <20110119125407.be7669b9.ray@dlink.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Alexandr Rybalko , freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 20 Jan 2011 08:50:12 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2011 at 12:31:03PM +0800, Adrian Chadd wrote: > On 19 January 2011 18:54, Alexandr Rybalko wrote: > > Hi, > > > > I`m happy to introduce GEOM_ULZMA module and utilitie to create an ulzm= a image. > > > > Think now it in acceptable for testing/reviewing/committing state. > > > > Wait for your questions. :) >=20 > I like it. I'd like to see the ulzma and gz stuff unified in a later > pass of this code but personally I'm happy to have it committed as-is > so it immediately gets some wider exposure. IMHO it should first be unified, really. Once it is committed the chances are much lower that it will be unified. Alexandr, would you like to implement some more general geom_compress class or something like that where it is easier to add new algorithms? You can look at geom_label, which is more or less implemented that way. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk039zIACgkQForvXbEpPzQfBACg1Xhig70JGZYWtD319vAk2WsM 5eQAnRmqCO3f2CEGcoOUNoPlNuMYsTO2 =qCsL -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-geom@FreeBSD.ORG Thu Jan 20 10:24:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89314106564A; Thu, 20 Jan 2011 10:24:27 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A84068FC13; Thu, 20 Jan 2011 10:24:26 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Pfrgm-0000zL-UJ; Thu, 20 Jan 2011 12:24:24 +0200 Date: Thu, 20 Jan 2011 12:26:44 +0200 From: Alexandr Rybalko To: Pawel Jakub Dawidek Message-Id: <20110120122644.9a38974c.ray@dlink.ua> In-Reply-To: <20110120084955.GD1716@garage.freebsd.pl> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 20 Jan 2011 10:24:27 -0000 On Thu, 20 Jan 2011 09:49:55 +0100 Pawel Jakub Dawidek wrote: >> On Thu, Jan 20, 2011 at 12:31:03PM +0800, Adrian Chadd wrote: >> > On 19 January 2011 18:54, Alexandr Rybalko wrote: >> > > Hi, >> > > >> > > I`m happy to introduce GEOM_ULZMA module and utilitie to create an ulzma image. >> > > >> > > Think now it in acceptable for testing/reviewing/committing state. >> > > >> > > Wait for your questions. :) >> > >> > I like it. I'd like to see the ulzma and gz stuff unified in a later >> > pass of this code but personally I'm happy to have it committed as-is >> > so it immediately gets some wider exposure. >> >> IMHO it should first be unified, really. Once it is committed the >> chances are much lower that it will be unified. >> >> Alexandr, would you like to implement some more general geom_compress >> class or something like that where it is easier to add new algorithms? >> You can look at geom_label, which is more or less implemented that way. It`s possible, but I think primary usage for it is a embedded, so we need smallest one and only one. Now in my boxes I use only geom_ulzma. Only one thing make Adrian idea as wished: gzip already in kernel for other things. But if world produce new compressor fines than xz/lzma we must drop lzma and use new one. Anyway I`ve look into, and do it if easy :) >> >> -- >> Pawel Jakub Dawidek http://www.wheelsystems.com >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! -- Alexandr Rybalko aka Alex RAY From owner-freebsd-geom@FreeBSD.ORG Thu Jan 20 14:48:37 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0777510656C0; Thu, 20 Jan 2011 14:48:37 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1CA8FC1D; Thu, 20 Jan 2011 14:48:35 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 453FD45E5C; Thu, 20 Jan 2011 15:48:33 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5F4A745CA0; Thu, 20 Jan 2011 15:48:28 +0100 (CET) Date: Thu, 20 Jan 2011 15:48:18 +0100 From: Pawel Jakub Dawidek To: Alexandr Rybalko Message-ID: <20110120144818.GG1716@garage.freebsd.pl> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8bBEDOJVaa9YlTAt" Content-Disposition: inline In-Reply-To: <20110120122644.9a38974c.ray@dlink.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Adrian Chadd , freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 20 Jan 2011 14:48:37 -0000 --8bBEDOJVaa9YlTAt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2011 at 12:26:44PM +0200, Alexandr Rybalko wrote: > On Thu, 20 Jan 2011 09:49:55 +0100 > Pawel Jakub Dawidek wrote: > >> IMHO it should first be unified, really. Once it is committed the > >> chances are much lower that it will be unified. > >>=20 > >> Alexandr, would you like to implement some more general geom_compress > >> class or something like that where it is easier to add new algorithms? > >> You can look at geom_label, which is more or less implemented that way. >=20 > It`s possible, but I think primary usage for it is a embedded, so we need= smallest one and only one. > Now in my boxes I use only geom_ulzma. >=20 > Only one thing make Adrian idea as wished: gzip already in kernel for oth= er things. > But if world produce new compressor fines than xz/lzma we must drop lzma = and use new one. Well, world is not that simple, I think:) Some algorithms are faster at decompressing, some compress better, so use less resources to decompress, etc. FreeBSD provides tools, not policies, right? Let's the administrator choose which algorithm fits best his needs. As for the code size, it should be trivial to decide which algorithms we want to compile in. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --8bBEDOJVaa9YlTAt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk04SzIACgkQForvXbEpPzSksgCg8Rql4UxJWLCbXrTFz1QjU4F9 UFUAoJRMqgIN5uFCQqRhM5QsdDW0JehR =Cb06 -----END PGP SIGNATURE----- --8bBEDOJVaa9YlTAt-- From owner-freebsd-geom@FreeBSD.ORG Thu Jan 20 15:51:45 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE68106566C; Thu, 20 Jan 2011 15:51:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9AE8FC12; Thu, 20 Jan 2011 15:51:44 +0000 (UTC) Received: by qyk36 with SMTP id 36so708260qyk.13 for ; Thu, 20 Jan 2011 07:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BFssmYCEIFKUGLCBDwvxS9v6LUL0B7/sQ1Rw5juYUl4=; b=GB7OGO2uplmAPOiDhnDTaJc92VQAaApbd0/6kq1lRsf7UA/7Ehedwi5jRcG5ixVCsM QoGz0wMwD2Lp8x6OlPlKVjxnFuX/WWgXbnH1H5AgWMQNWCtouPq+XWPz4CRcq6HZXORt TrTH9q6ZQFi3ULiQ6LCOXXrwKNmGiP8KVUb3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=bpSPmRHZhyBtZo8+I43M4CoGkcR41bCKhESKGgx0lcql5Pq/ABZLkSK9/qzRwfo8uH WjN5c8WFqhytGY8HVitrhQELll7vILX489MiEriXGZc2wHvkAzG8gShQwx0gR003nK/M iRKqbjmkGiBs4JkreAahtgi5hgfuxk5pBM+Vs= MIME-Version: 1.0 Received: by 10.224.67.18 with SMTP id p18mr2101952qai.20.1295538704331; Thu, 20 Jan 2011 07:51:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.198.203 with HTTP; Thu, 20 Jan 2011 07:51:44 -0800 (PST) In-Reply-To: <20110120122644.9a38974c.ray@dlink.ua> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> Date: Thu, 20 Jan 2011 15:51:44 +0000 X-Google-Sender-Auth: YO0jYYGJDwsToSeDLRZJGNyd7Ko Message-ID: From: Adrian Chadd To: Alexandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Jakub Dawidek , freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 20 Jan 2011 15:51:45 -0000 Well, creating a generic geom_compress module shouldn't increase the size by all that much. It's just a few function pointers that point at the decompression class. The rest of the format is the same, right? (ie, how it's broken into chunks, the chunks are separately compressed, etc.) This is great work by the way. :) Adrian From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 13:02:47 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07531065674 for ; Fri, 21 Jan 2011 13:02:47 +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 6433C8FC08 for ; Fri, 21 Jan 2011 13:02:47 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PgGdZ-0007Xh-QD for freebsd-geom@freebsd.org; Fri, 21 Jan 2011 14:02:45 +0100 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 ; Fri, 21 Jan 2011 14:02:45 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2011 14:02:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 21 Jan 2011 14:02:32 +0100 Lines: 8 Message-ID: References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> 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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Cc: freebsd-embedded@freebsd.org Subject: Re: GEOM_LZMA 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, 21 Jan 2011 13:02:47 -0000 On 20/01/2011 16:51, Adrian Chadd wrote: > Well, creating a generic geom_compress module shouldn't increase the > size by all that much. It's just a few function pointers that point at > the decompression class. The rest of the format is the same, right? > (ie, how it's broken into chunks, the chunks are separately > compressed, etc.) I think they are talking about the size of the kernel :) From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 13:44:14 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A990B106564A; Fri, 21 Jan 2011 13:44:14 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id CDA9B8FC1E; Fri, 21 Jan 2011 13:44:13 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1PgHHg-00040N-0R; Fri, 21 Jan 2011 15:44:12 +0200 Date: Fri, 21 Jan 2011 15:46:36 +0200 From: Alexandr Rybalko To: Ivan Voras Message-Id: <20110121154636.f10529d8.ray@dlink.ua> In-Reply-To: References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__21_Jan_2011_15_46_36_+0200_KF7WL1ChriBbuR/P" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 21 Jan 2011 13:44:14 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__21_Jan_2011_15_46_36_+0200_KF7WL1ChriBbuR/P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 21 Jan 2011 14:02:32 +0100 Ivan Voras wrote: >> On 20/01/2011 16:51, Adrian Chadd wrote: >> > Well, creating a generic geom_compress module shouldn't increase the >> > size by all that much. It's just a few function pointers that point at >> > the decompression class. The rest of the format is the same, right? >> > (ie, how it's broken into chunks, the chunks are separately >> > compressed, etc.) >> >> I think they are talking about the size of the kernel :) Exact match :) But really, gzip in most cases already compiled into kernel (my not) and anyway have small footprint. So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA yet. Module name open for discussion :) Since they must have short and understandable name. Maybe GEOM_COMPR, maybe full GEOM_COMPRESSION, maybe GEOM_REDUCE, etc. http://my.ddteam.net/files/geom_ulzma_and_uzip.diff and same in attachment. P.S. Please modify conf/files by hand, because my own conf/files have many changes. >> >> _______________________________________________ >> 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" -- Alexandr Rybalko aka Alex RAY --Multipart=_Fri__21_Jan_2011_15_46_36_+0200_KF7WL1ChriBbuR/P-- From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 14:09:32 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554ED106566C for ; Fri, 21 Jan 2011 14:09:32 +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 0A6BA8FC16 for ; Fri, 21 Jan 2011 14:09:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PgHg7-0003hE-PN for freebsd-geom@freebsd.org; Fri, 21 Jan 2011 15:09:27 +0100 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 ; Fri, 21 Jan 2011 15:09:27 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2011 15:09:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 21 Jan 2011 15:09:16 +0100 Lines: 13 Message-ID: References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> <20110121154636.f10529d8.ray@dlink.ua> 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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110121154636.f10529d8.ray@dlink.ua> X-Enigmail-Version: 1.1.2 Cc: freebsd-embedded@freebsd.org Subject: Re: GEOM_LZMA 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, 21 Jan 2011 14:09:32 -0000 On 21/01/2011 14:46, Alexandr Rybalko wrote: > But really, gzip in most cases already compiled into kernel (my not) and anyway have small footprint. > > So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA yet. > > Module name open for discussion :) Is "uzip" some kind of well-known or special name? Because since it doesn't reference the algorithm but only a generic term "zip", maybe it's better that the name remains geom_uzip? Except if it is incompatible with the old geom_uzip. From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 14:41:22 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE86E106566B; Fri, 21 Jan 2011 14:41:22 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2CB8FC18; Fri, 21 Jan 2011 14:41:22 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1PgIAw-0004ZS-O7; Fri, 21 Jan 2011 16:41:18 +0200 Date: Fri, 21 Jan 2011 16:43:43 +0200 From: Alexandr Rybalko To: Ivan Voras Message-Id: <20110121164343.41aa1378.ray@dlink.ua> In-Reply-To: References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> <20110121154636.f10529d8.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 21 Jan 2011 14:41:23 -0000 On Fri, 21 Jan 2011 15:09:16 +0100 Ivan Voras wrote: >> On 21/01/2011 14:46, Alexandr Rybalko wrote: >> >> > But really, gzip in most cases already compiled into kernel (my not) and anyway have small footprint. >> > >> > So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA yet. >> > >> > Module name open for discussion :) >> >> Is "uzip" some kind of well-known or special name? Because since it >> doesn't reference the algorithm but only a generic term "zip", maybe >> it's better that the name remains geom_uzip? Except if it is >> incompatible with the old geom_uzip. Yep, they are compatible with geom_uzip. But they have also ulzma and can include something else, so better to have more generic name. >> >> >> _______________________________________________ >> 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" -- Alexandr Rybalko aka Alex RAY From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 15:43:19 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E68391065674; Fri, 21 Jan 2011 15:43:19 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 8178C8FC1B; Fri, 21 Jan 2011 15:43:19 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0B46745EE5; Fri, 21 Jan 2011 16:43:18 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 31A5545CD9; Fri, 21 Jan 2011 16:43:13 +0100 (CET) Date: Fri, 21 Jan 2011 16:43:03 +0100 From: Pawel Jakub Dawidek To: Alexandr Rybalko Message-ID: <20110121154303.GG1698@garage.freebsd.pl> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> <20110121154636.f10529d8.ray@dlink.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HuscSE0D68UGttcd" Content-Disposition: inline In-Reply-To: <20110121154636.f10529d8.ray@dlink.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA 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, 21 Jan 2011 15:43:20 -0000 --HuscSE0D68UGttcd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2011 at 03:46:36PM +0200, Alexandr Rybalko wrote: > On Fri, 21 Jan 2011 14:02:32 +0100 > Ivan Voras wrote: >=20 > >> On 20/01/2011 16:51, Adrian Chadd wrote: > >> > Well, creating a generic geom_compress module shouldn't increase the > >> > size by all that much. It's just a few function pointers that point = at > >> > the decompression class. The rest of the format is the same, right? > >> > (ie, how it's broken into chunks, the chunks are separately > >> > compressed, etc.) > >>=20 > >> I think they are talking about the size of the kernel :) >=20 > Exact match :) >=20 > But really, gzip in most cases already compiled into kernel (my not) and = anyway have small footprint. >=20 > So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA yet.=20 >=20 > Module name open for discussion :) > Since they must have short and understandable name. > Maybe GEOM_COMPR, > maybe full GEOM_COMPRESSION, > maybe GEOM_REDUCE, > etc. What's wrong with GEOM_COMPRESS? We already have equally long or longer class names: GEOM_LINUX_LVM GEOM_MOUNTVER GEOM_MULTIPATH GEOM_SUNLABEL --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --HuscSE0D68UGttcd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk05qYYACgkQForvXbEpPzSVUwCgxf/uGY9JOGR5oWw5IhCGK7Gq XDEAoNhim//BtLIRgYQy/Y64GgSPerrm =Y/fH -----END PGP SIGNATURE----- --HuscSE0D68UGttcd-- From owner-freebsd-geom@FreeBSD.ORG Sat Jan 22 12:58:47 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632AB1065675; Sat, 22 Jan 2011 12:58:47 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3058FC13; Sat, 22 Jan 2011 12:58:46 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 4CC8C221023C; Sat, 22 Jan 2011 15:58:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1295701125; bh=6kiI97C10a9vmXo40aI3KW/Dxdip3y+qKzAvTPvbOwU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=pdJBSuiWTLLiPl0WXWC4cfdChDkP92+7IptmMYEsB7Q3jIRBlhtOS5fPRza3sv3ft LSEUbmQ7DGJ94Dv9iB9orwCew4RzXnbuJ+luvAlz4D4Qi2LUI2YJArcNTjx7ijymvS wYfWnxaRiCGJcOKRFkElae9oC9wpJvTJ4GVK6S0s= Received: from [178.141.5.86] (dynamic-178-141-5-86.kirov.comstar-r.ru [178.141.5.86]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id 00D12415807F; Sat, 22 Jan 2011 15:58:44 +0300 (MSK) Message-ID: <4D3AD47E.9010400@yandex.ru> Date: Sat, 22 Jan 2011 15:58:38 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110122 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-geom@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------070207000008030808070207" Cc: Marcel Moolenaar , Pawel Jakub Dawidek Subject: [PATCH] Do tasting for UFS's id and volume only for freebsd-ufs partitions X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 12:58:47 -0000 This is a multi-part message in MIME format. --------------070207000008030808070207 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Hi All. I saw several strangest problem reports where UFS labels were successfully tasted for an inappropriate provider. So, what you thing about proposed patch? It add new handled attribute to geom PART class - "PART::type". It does return partition type for given consumer. Also it does limit tasting for UFS labels only for "freebsd-ufs" providers. -- WBR, Andrey V. Elsukov --------------070207000008030808070207 Content-Type: text/plain; name="ufs_labels.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ufs_labels.diff" Index: head/sys/geom/label/g_label_ufs.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/label/g_label_ufs.c (revision 217714) +++ head/sys/geom/label/g_label_ufs.c (working copy) @@ -53,6 +53,7 @@ g_label_ufs_taste_common(struct g_consumer *cp, ch struct g_provider *pp; int sb, superblock; struct fs *fs; + char type[64]; =20 g_topology_assert_not(); pp =3D cp->provider; @@ -60,6 +61,10 @@ g_label_ufs_taste_common(struct g_consumer *cp, ch =20 if (SBLOCKSIZE % cp->provider->sectorsize !=3D 0) return; + if (g_getattr("PART::type", cp, &type) !=3D 0) + return; + if (strcmp(type, "freebsd-ufs") !=3D 0) + return; =20 /* * Walk through the standard places that superblocks hide and look 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 217714) +++ head/sys/geom/part/g_part.c (working copy) @@ -1912,6 +1912,7 @@ g_part_start(struct bio *bp) struct g_part_table *table; struct g_kerneldump *gkd; struct g_provider *pp; + char buf[64]; =20 pp =3D bp->bio_to; gp =3D pp->geom; @@ -1960,6 +1961,9 @@ g_part_start(struct bio *bp) if (g_handleattr_str(bp, "PART::scheme", table->gpt_scheme->name)) return; + if (g_handleattr_str(bp, "PART::type", + G_PART_TYPE(table, entry, buf, sizeof(buf)))) + return; if (!strcmp("GEOM::kerneldump", bp->bio_attribute)) { /* * Check that the partition is suitable for kernel --------------070207000008030808070207-- From owner-freebsd-geom@FreeBSD.ORG Sat Jan 22 14:09:13 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF26B106566B for ; Sat, 22 Jan 2011 14:09:13 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 0AC648FC0A for ; Sat, 22 Jan 2011 14:09:12 +0000 (UTC) Received: (qmail invoked by alias); 22 Jan 2011 14:09:11 -0000 Received: from adsl-231.109.242.136.tellas.gr (EHLO [192.168.73.195]) [109.242.136.231] by mail.gmx.com (mp-eu002) with SMTP; 22 Jan 2011 15:09:11 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19E4lxk0jlE1gZXRdIyA3mOPsf3IjvXkuhA9HPfoS I40ClL9C9Q76rS Message-ID: <4D3AE488.7050609@gmx.com> Date: Sat, 22 Jan 2011 16:07:04 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: kmem_map panic with gjournal X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 14:09:13 -0000 Hi, I am seeing a "kmem_map too small" panic on a low resources machine (384MB of RAM). After lowering kern.geom.journal.cache.limit the panic is gone, yet I am not sure that this is the "best" solution. Any thoughts? Backtrace from RELENG_8. The panic also occurs on HEAD. Unread portion of the kernel message buffer: panic: kmem_malloc(131072): kmem_map too small: 111280128 total allocated cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0d3b1ec,d1be5568,c090107c,c31d1870,d1be5568,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0d68c13,0,c0d5c9b8,d1be55d8,0,...) at kdb_backtrace+0x2a panic(c0d5c9b8,20000,6a20000,c0d5c9b2,7d0,...) at panic+0x117 kmem_malloc(c199008c,20000,2,d1be5640,c0b7cc90,...) at kmem_malloc+0x28a page_alloc(0,20000,d1be5633,2,2c41a72,...) at page_alloc+0x27 uma_large_malloc(20000,2,d1be56a8,2,20000,...) at uma_large_malloc+0x50 malloc(20000,c10aa080,2,111,c9415000,...) at malloc+0x80 gj_malloc(c93f5000,ca3ed000,20000,42788000,2,...) at gj_malloc+0x9b g_journal_new_bio(427a8000,2,10ee800,0,c9415000,...) at g_journal_new_bio+0x62 g_journal_insert(427a8000,2,10ee800,0,c9415000,...) at g_journal_insert+0xe0 g_journal_flush(c31ae610,0,c10a8b26,87e,7d0,...) at g_journal_flush+0x36a g_journal_worker(c31ae600,d1be5d28,0,0,0,...) at g_journal_worker+0x162d fork_exit(c10a64e0,c31ae600,d1be5d28) at fork_exit+0x91 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd1be5d60, ebp = 0 --- Uptime: 7m11s Physical memory: 367 MB Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2 Thanks, Nikos From owner-freebsd-geom@FreeBSD.ORG Sat Jan 22 16:46:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FDC01065670 for ; Sat, 22 Jan 2011 16:46:27 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B06678FC08 for ; Sat, 22 Jan 2011 16:46:25 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0588945C9F; Sat, 22 Jan 2011 17:46:23 +0100 (CET) Received: from localhost (89-73-192-49.dynamic.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D30DA45684; Sat, 22 Jan 2011 17:46:17 +0100 (CET) Date: Sat, 22 Jan 2011 17:46:05 +0100 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20110122164605.GA8360@garage.freebsd.pl> References: <4D3AD47E.9010400@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <4D3AD47E.9010400@yandex.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: [PATCH] Do tasting for UFS's id and volume only for freebsd-ufs partitions X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 16:46:27 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 22, 2011 at 03:58:38PM +0300, Andrey V. Elsukov wrote: > Hi All. >=20 > I saw several strangest problem reports where UFS labels were > successfully tasted for an inappropriate provider. > So, what you thing about proposed patch? >=20 > It add new handled attribute to geom PART class - "PART::type". > It does return partition type for given consumer. > Also it does limit tasting for UFS labels only for "freebsd-ufs" > providers. What's wrong with placing UFS on raw disk or GELI-encrypted provider? In my opinion this patch limits functionality too much. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk07Cc0ACgkQForvXbEpPzTj8wCbBWu+t0muH42ZkcdjOwVBUIkG cFgAni7bpPNmXU9XVkvBTwii+NuG6vTL =APlW -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-geom@FreeBSD.ORG Sat Jan 22 23:01:47 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2AC91065694; Sat, 22 Jan 2011 23:01:47 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D1DF18FC14; Sat, 22 Jan 2011 23:01:46 +0000 (UTC) Received: by bwz12 with SMTP id 12so2696284bwz.13 for ; Sat, 22 Jan 2011 15:01:45 -0800 (PST) Received: by 10.204.72.20 with SMTP id k20mr2021738bkj.184.1295735417901; Sat, 22 Jan 2011 14:30:17 -0800 (PST) Received: from rnote.ddteam.net (184-210-135-95.pool.ukrtel.net [95.135.210.184]) by mx.google.com with ESMTPS id j11sm5289761bka.12.2011.01.22.14.30.15 (version=SSLv3 cipher=RC4-MD5); Sat, 22 Jan 2011 14:30:16 -0800 (PST) Date: Sun, 23 Jan 2011 00:30:13 +0200 From: Aleksandr Rybalko To: Pawel Jakub Dawidek , Ivan Voras Message-Id: <20110123003013.90378231.ray@ddteam.net> In-Reply-To: <20110121154303.GG1698@garage.freebsd.pl> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> <20110121154636.f10529d8.ray@dlink.ua> <20110121154303.GG1698@garage.freebsd.pl> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexandr Rybalko , freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 23:01:47 -0000 On Fri, 21 Jan 2011 16:43:03 +0100 Pawel Jakub Dawidek wrote: > On Fri, Jan 21, 2011 at 03:46:36PM +0200, Alexandr Rybalko wrote: > > On Fri, 21 Jan 2011 14:02:32 +0100 > > Ivan Voras wrote: > > > > >> On 20/01/2011 16:51, Adrian Chadd wrote: > > >> > Well, creating a generic geom_compress module shouldn't > > >> > increase the size by all that much. It's just a few function > > >> > pointers that point at the decompression class. The rest of > > >> > the format is the same, right? (ie, how it's broken into > > >> > chunks, the chunks are separately compressed, etc.) > > >> > > >> I think they are talking about the size of the kernel :) > > > > Exact match :) > > > > But really, gzip in most cases already compiled into kernel (my > > not) and anyway have small footprint. > > > > So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA > > yet. > > > > Module name open for discussion :) > > Since they must have short and understandable name. > > Maybe GEOM_COMPR, > > maybe full GEOM_COMPRESSION, > > maybe GEOM_REDUCE, > > etc. > > What's wrong with GEOM_COMPRESS? We already have equally long or > longer class names: > > GEOM_LINUX_LVM > GEOM_MOUNTVER > GEOM_MULTIPATH > GEOM_SUNLABEL > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! So as result of small discussion (thanks Ivan and Pawel Jakub) think best name is GEOM_UCOMPRESS (module do only UN-compress). WBW -- Aleksandr Rybalko From owner-freebsd-geom@FreeBSD.ORG Sat Jan 22 23:13:13 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7839D106564A for ; Sat, 22 Jan 2011 23:13:12 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26DC98FC15 for ; Sat, 22 Jan 2011 23:13:11 +0000 (UTC) Received: by qyk36 with SMTP id 36so2836819qyk.13 for ; Sat, 22 Jan 2011 15:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=IjWhz7zjfGdArTblx37MTD56tpq8xaGh6sg8BKuauzY=; b=qQYp3pGMksOgfZMgP44kbyzBbUSf+JInKnvaPw9ECakQrAlu7kLteymyyhVTYsYSKH kqfheeox6LG2FZezgJynPTYgZwUUerZXCnBq2XsY3lMB4FyGk1zwsc8CDI7eLa05wW8i cSOKyw9tJkLykl6JJy3kJGslN3CSdQrXq9e/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=prdxZLcITCR3hlrQtmBudTqoFdfpJqv/feoTQsl3CVjNnKdwuINDolTn4AWBh17TD3 eooei+4qTIGm+D90F95z+ge3WiincsrZr2ELL/0VibMIoOAPMvJJTQQCOX6rpOqTFfWT aSUsXNxqpsMgSIiDwDqN3nd6UFU1fS4bhVLeQ= Received: by 10.229.213.130 with SMTP id gw2mr2161284qcb.253.1295737990996; Sat, 22 Jan 2011 15:13:10 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.44.70 with HTTP; Sat, 22 Jan 2011 15:12:30 -0800 (PST) In-Reply-To: <20110123003013.90378231.ray@ddteam.net> References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> <20110121154636.f10529d8.ray@dlink.ua> <20110121154303.GG1698@garage.freebsd.pl> <20110123003013.90378231.ray@ddteam.net> From: Ivan Voras Date: Sun, 23 Jan 2011 00:12:30 +0100 X-Google-Sender-Auth: UJ5M_guBFIQQUrcw0OK1BqTy6Ts Message-ID: To: Aleksandr Rybalko Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GEOM_LZMA X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 23:13:13 -0000 On 22 January 2011 23:30, Aleksandr Rybalko wrote: > So as result of small discussion (thanks Ivan and Pawel Jakub) think > best name is GEOM_UCOMPRESS (module do only UN-compress). It's a good name, I'd accept it. But since you already have a descriptive name, why not add the missing "N" and make it GEOM_UNCOMPRESS? It's more user-friendly in case future users start wondering what the "U" means :)