From owner-freebsd-geom@FreeBSD.ORG Mon Feb 25 11:06:47 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E83F140 for ; Mon, 25 Feb 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 12C08E6B for ; Mon, 25 Feb 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PB6kbs066583 for ; Mon, 25 Feb 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PB6kkw066581 for freebsd-geom@FreeBSD.org; Mon, 25 Feb 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2013 11:06:46 GMT Message-Id: <201302251106.r1PB6kkw066581@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 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:06:47 -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/171865 geom [geom] [patch] g_wither_washer() keeping a core busy o kern/170038 geom [geom] geom_mirror always starts degraded after reboot o kern/169539 geom [geom] [patch] fix ability to run gmirror on MSI MegaR a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162690 geom [geom] gpart label changes only take effect after a re o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres f kern/159414 geom [isp] isp(4)+gmultipath(8) : removing active fiber pat p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them 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/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/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/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 bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock 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 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 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/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/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa 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. 73 problems total. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 28 17:02:09 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 999B37B5 for ; Thu, 28 Feb 2013 17:02:09 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0DD1FA for ; Thu, 28 Feb 2013 17:02:09 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UB6sA-000897-9w for freebsd-geom@freebsd.org; Thu, 28 Feb 2013 18:02:22 +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 ; Thu, 28 Feb 2013 18:02:22 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Feb 2013 18:02:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! Date: Thu, 28 Feb 2013 18:01:46 +0100 Lines: 54 Message-ID: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> <1502041051.20130228185647@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12065FB88A964A3B91C9C4FD" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <1502041051.20130228185647@serebryakov.spb.ru> X-Enigmail-Version: 1.4.3 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:02:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12065FB88A964A3B91C9C4FD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28/02/2013 15:56, Lev Serebryakov wrote: > One time, Kirk say, that delayed writes are Ok for SU until bottom > layer doesn't lie about operation completeness. geom_raid5 could > delay writes (in hope that next writes will combine nicely and allow > not to do read-calculate-write cycle for read alone), but it never > mark BIO complete until it is really completed (layers down to > geom_raid5 returns completion). So, every BIO in wait queue is "in > flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :(= It shouldn't be - it could be a bug. > And want I really want to see is "SYNC" flag for BIO and that all > journal-related writes will be marked with it. Also all commits > originated with fsync() MUST be marked in same way, really. Alexander > Motin (ahci driver author) assured me, that he'll add support for > such flag in driver to flush drive cache too, if it will be > introduced. Hmmm, once upon a time I actually tried to add it: http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch This is from 2011, and was never really reviewed. Kirk said it was a good idea (meaning the implementation could be wrong, YMMV) :) I don't know whether it's significant, but ffs_softdep.c contains 6 bawrite() calls (meaning buf async write), in softdep_process_journal(), softdep_journal_freeblocks(), softdep_fsync_mountdev(), sync_cgs(), and flush_deplist(). --------------enig12065FB88A964A3B91C9C4FD 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.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEvjXoACgkQ/QjVBj3/HSzgXQCZASkd1JTlv/mRSlZ8EdNtqVwp XNUAoI6V2WCe4D9mfizE/RTDA1g0SKrL =eK7Y -----END PGP SIGNATURE----- --------------enig12065FB88A964A3B91C9C4FD-- From owner-freebsd-geom@FreeBSD.ORG Thu Feb 28 17:32:35 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89D31B93; Thu, 28 Feb 2013 17:32:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 44C183FC; Thu, 28 Feb 2013 17:32:35 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 64B434AC57; Thu, 28 Feb 2013 21:32:23 +0400 (MSK) Date: Thu, 28 Feb 2013 21:32:17 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <127827160.20130228213217@serebryakov.spb.ru> To: Ivan Voras Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> <1502041051.20130228185647@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:32:35 -0000 Hello, Ivan. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 21:01= :46: >> One time, Kirk say, that delayed writes are Ok for SU until bottom >> layer doesn't lie about operation completeness. geom_raid5 could >> delay writes (in hope that next writes will combine nicely and allow >> not to do read-calculate-write cycle for read alone), but it never >> mark BIO complete until it is really completed (layers down to >> geom_raid5 returns completion). So, every BIO in wait queue is "in >> flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :( IV> It shouldn't be - it could be a bug. I'll try to reproduce it on VM, but it could be hard, as virtual storage have very different (really -- much simpler) characteristics and behavior. >> And want I really want to see is "SYNC" flag for BIO and that all >> journal-related writes will be marked with it. Also all commits >> originated with fsync() MUST be marked in same way, really. Alexander >> Motin (ahci driver author) assured me, that he'll add support for >> such flag in driver to flush drive cache too, if it will be >> introduced. IV> Hmmm, once upon a time I actually tried to add it: IV> http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch I have almost the same patch here :) IV> This is from 2011, and was never really reviewed. Kirk said it was a IV> good idea (meaning the implementation could be wrong, YMMV) :) It will be great to see this idea committed, really! Could I help somehow? IV> I don't know whether it's significant, but ffs_softdep.c contains 6 IV> bawrite() calls (meaning buf async write), in softdep_process_journal(), IV> softdep_journal_freeblocks(), softdep_fsync_mountdev(), sync_cgs(), and IV> flush_deplist(). As far as I understand (I've examined this code when try to understand how to add this BIO_SYNC flag), ASYNC/SYNC here means something different. It is only about does caller want to sleep till operation is completed, and doesn't mean sync or async write... So, I'm not sure, which of these calls should be marked for flushing (or should be marked with new ORDERED/BARRIER flag at least). SU code is complicated enough without journal, and with journal it is much more complicated to simply understand it :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Fri Mar 1 11:28:20 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C279F497; Fri, 1 Mar 2013 11:28:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 82D62854; Fri, 1 Mar 2013 11:28:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 9F5BE4AC59; Fri, 1 Mar 2013 15:28:02 +0400 (MSK) Date: Fri, 1 Mar 2013 15:27:56 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <612776324.20130301152756@serebryakov.spb.ru> To: Ivan Voras , Don Lewis Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> <1502041051.20130228185647@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:28:20 -0000 Hello, Ivan. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 21:01= :46: >> One time, Kirk say, that delayed writes are Ok for SU until bottom >> layer doesn't lie about operation completeness. geom_raid5 could >> delay writes (in hope that next writes will combine nicely and allow >> not to do read-calculate-write cycle for read alone), but it never >> mark BIO complete until it is really completed (layers down to >> geom_raid5 returns completion). So, every BIO in wait queue is "in >> flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :( IV> It shouldn't be - it could be a bug. I understand, that it proves nothing, but I've tried to repeat "previous crash corrupt FS in journal-undetectable way" theory by killing virtual system when there is massive writing to geom_radi5-based FS (on virtual drives, unfortunately). I've done 15 tries (as it is manual testing, it takes about 1-1.5 hours total), but every time FS was Ok after double-fsck (first with journal and last without one). Of course, there was MASSIVE loss of data, as timeout and size of cache in geom_raid5 was set very high (sometimes FS becomes empty after unpacking 50% of SVN mirror seed, crash and check) but FS was consistent every time! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Fri Mar 1 14:19:22 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9806D464 for ; Fri, 1 Mar 2013 14:19:22 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 56683F75 for ; Fri, 1 Mar 2013 14:19:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UBQoD-0003V2-LX for freebsd-geom@freebsd.org; Fri, 01 Mar 2013 15:19:37 +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, 01 Mar 2013 15:19:37 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Mar 2013 15:19:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Subject: Disk idents as labels Date: Fri, 01 Mar 2013 15:19:05 +0100 Lines: 57 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D4ED7B5883AB784B97DA116" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 X-Enigmail-Version: 1.4.3 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:19:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D4ED7B5883AB784B97DA116 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, It's silly how this often-requested feature is still not implemented, so I've made this simple patch which introduces the facility to glabel: https://bitbucket.org/ivoras/freebsd-head/commits/2ee41dd299e82a8659b61d9= 5ebd35f08306735e9 Basically, it looks up the GEOM::ident attribute and the GEOM class name and creates a label in the form of "/dev/diskid/CLASS_NAME-ident". I've added the CLASS_NAME part since there are many classes which simply pass-through the attribute requests, which can lead to the same drive being labeled more than once. There are other ways in which this can be handled, for example by maintaining a table of previously seen ident strings and not creating a label device if there already exists one for this ident, or by only restricting the glabel code to create label nodes for devices of class DISK. I sort of like the latter solution best, but I don't know if "DISK" is the only class to which such labeling should be restricted. I'd like very much for people with complex GEOM topologies or with non-common RAID controllers to test this and report what they get in /dev/diskid. The patch should also apply to 9-stable. For example, on a virtual machine I get this: crw-r----- 1 root operator 0x66 1 Mar 14:59 /dev/diskid/DISK-01000000000000000001 crw-r----- 1 root operator 0x68 1 Mar 14:59 /dev/diskid/PART-00000000000000000001 The DISK one is ok, since it's an unused drive attached to the system, but the PART one isn't, since it's an unused partition on a drive. This is why I'd like to restrict this functionality to devices of DISK class. --------------enig4D4ED7B5883AB784B97DA116 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.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEwuNkACgkQ/QjVBj3/HSwUgwCdHLUYfLgQbkOShQuJTOv2MyPU LW0An3FHDHRAWwWN9D395eTylAgBEYuX =vepy -----END PGP SIGNATURE----- --------------enig4D4ED7B5883AB784B97DA116--