From owner-freebsd-fs@freebsd.org Sun Nov 22 07:23:55 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27D68A353F6 for ; Sun, 22 Nov 2015 07:23:55 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id 181651888 for ; Sun, 22 Nov 2015 07:23:54 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from Chriss-MacBook-Pro.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mango.stankevitz.com (Postfix) with ESMTPSA id DB43741976 for ; Sat, 21 Nov 2015 23:18:27 -0800 (PST) To: FreeBSD Filesystems From: Chris Stankevitz Subject: Recovering a zfs root pool from backup Message-ID: <56516C41.20906@stankevitz.com> Date: Sat, 21 Nov 2015 23:18:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 07:23:55 -0000 I have a 'zroot' as setup by the FreeBSD install procedure on "Machine A". I back it up like so: zfs snapshot -r zroot@backup zfs send -Rv zroot@backup > /path/to/external/drive/zroot.backup.bin Let's assume that "Machine A" zroot pool is destroyed. On "Machine B" I issue these commands: zpool create zroot /dev/new/drive cat /path/to/external/drive/zroot.backup.bin | zfs receive -d zroot I do not believe that this will create a working drive for Machine A because: 1. I doubt I can create a new pool called "zroot" on Machine B since it is already running a pool called "zroot" 2. I doubt that this process will create the appropriate "boot sector" stuff (I do not know what I am talking about here). Can you provide a solution to either of these problems and/or identify other problems with my backup/restore procedure? Thank you, Chris PS: The system is a file server with nearly all data stored on a zpool that is not "zroot". From owner-freebsd-fs@freebsd.org Sun Nov 22 08:47:16 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0293DA35161 for ; Sun, 22 Nov 2015 08:47:16 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from Exch2-2.slu.se (pop.slu.se [77.235.224.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC19163C for ; Sun, 22 Nov 2015 08:47:14 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from Exch2-2.slu.se (77.235.224.122) by Exch2-2.slu.se (77.235.224.122) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 22 Nov 2015 09:32:02 +0100 Received: from Exch2-2.slu.se ([fe80::9023:6997:a676:a304]) by Exch2-2.slu.se ([fe80::9023:6997:a676:a304%23]) with mapi id 15.00.1104.000; Sun, 22 Nov 2015 09:32:02 +0100 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: Chris Stankevitz CC: FreeBSD Filesystems Subject: Re: Recovering a zfs root pool from backup Thread-Topic: Recovering a zfs root pool from backup Thread-Index: AQHRJQBCR2hkpvI3C0qCBcQnAeh6oA== Date: Sun, 22 Nov 2015 08:32:01 +0000 Message-ID: <8834bc1f-4e73-4315-a591-a4ff89dc80c9@email.android.com> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 08:47:16 -0000 DQpEZW4gMjIgbm92LiAyMDE1IDg6MjQgZm0gc2tyZXYgQ2hyaXMgU3Rhbmtldml0eiA8Y2hyaXNA c3Rhbmtldml0ei5jb20+Og0KPg0KPiBJIGhhdmUgYSAnenJvb3QnIGFzIHNldHVwIGJ5IHRoZSBG cmVlQlNEIGluc3RhbGwgcHJvY2VkdXJlIG9uICJNYWNoaW5lDQo+IEEiLiAgSSBiYWNrIGl0IHVw IGxpa2Ugc286DQo+DQo+IHpmcyBzbmFwc2hvdCAtciB6cm9vdEBiYWNrdXANCj4NCj4gemZzIHNl bmQgLVJ2IHpyb290QGJhY2t1cCA+IC9wYXRoL3RvL2V4dGVybmFsL2RyaXZlL3pyb290LmJhY2t1 cC5iaW4NCj4NCj4gTGV0J3MgYXNzdW1lIHRoYXQgIk1hY2hpbmUgQSIgenJvb3QgcG9vbCBpcyBk ZXN0cm95ZWQuICBPbiAiTWFjaGluZSBCIiBJDQo+IGlzc3VlIHRoZXNlIGNvbW1hbmRzOg0KPg0K PiB6cG9vbCBjcmVhdGUgenJvb3QgL2Rldi9uZXcvZHJpdmUNCj4NCj4gY2F0IC9wYXRoL3RvL2V4 dGVybmFsL2RyaXZlL3pyb290LmJhY2t1cC5iaW4gfCB6ZnMgcmVjZWl2ZSAtZCB6cm9vdA0KPg0K PiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgdGhpcyB3aWxsIGNyZWF0ZSBhIHdvcmtpbmcgZHJpdmUg Zm9yIE1hY2hpbmUgQQ0KPiBiZWNhdXNlOg0KPg0KPiAxLiBJIGRvdWJ0IEkgY2FuIGNyZWF0ZSBh IG5ldyBwb29sIGNhbGxlZCAienJvb3QiIG9uIE1hY2hpbmUgQiBzaW5jZSBpdA0KPiBpcyBhbHJl YWR5IHJ1bm5pbmcgYSBwb29sIGNhbGxlZCAienJvb3QiDQo+DQo+IDIuIEkgZG91YnQgdGhhdCB0 aGlzIHByb2Nlc3Mgd2lsbCBjcmVhdGUgdGhlIGFwcHJvcHJpYXRlICJib290IHNlY3RvciINCj4g c3R1ZmYgKEkgZG8gbm90IGtub3cgd2hhdCBJIGFtIHRhbGtpbmcgYWJvdXQgaGVyZSkuDQoNCkV4 YWN0bHkuIFlvdSdkIG5lZWQgdG8gYm9vdCB0aGUgbWFjaGluZSBmcm9tIENEL1VTQiB0byBiZSBh YmxlIHRvIHJlY2VpdmUgdGhlIHN0cmVhbS4gQWJvdXQgdGhlIGJvb3Qgc3R1ZmYuIFRoYXQgd291 bGQgbmVlZCB0byBiZSBoYW5kbGVkIHdoZW4gcGFydGl0aW9uaW5nIHRoZSBuZXcgZHJpdmU6DQoj IGdwYXJ0IGNyZWF0ZSAtdCBncHQgKGEpP2RhWzAtOV0rDQojIGdwYXJ0IGFkZCAtdCBmcmVlYnNk LWJvb3QgLXMgNjRrIC1sIGJvb3QwIChhKT9kYVswLTldKw0KIyBncGFydCBib290Y29kZSAtYiAv Ym9vdC9wbWJyIC1wIC9ib290L2dwdHpmc2Jvb3QgLWkgMSAoYSk/ZGFbMC05XSsNCiMgZ3BhcnQg YWRkIC10IGZyZWVic2Qtc3dhcCAtYiAyMDQ4IC1zIHhnIC1sIHN3YXAwIChhKT9kYVswLTldKw0K IyBncGFydCBhZGQgLXQgZnJlZWJzZC16ZnMgLWEgNGsgLWwgc3lzMCAoYSk/ZGFbMC05XSsNCiMg c3lzY3RsIHZmcy56ZnMubWluX2F1dG9fYXNoaWZ0PTEyDQoNCkFsc28geW91IG5lZWQgdG8gc2V0 IHRoZSAiYm9vdGZzIiBwcm9wZXJ0eSBhZnRlciB0aGUgcmVjZWl2ZToNCiMgenBvb2wgc2V0IGJv b3Rmcz16cm9vdCB6cm9vdA0KDQovSw0KDQo+DQo+IENhbiB5b3UgcHJvdmlkZSBhIHNvbHV0aW9u IHRvIGVpdGhlciBvZiB0aGVzZSBwcm9ibGVtcyBhbmQvb3IgaWRlbnRpZnkNCj4gb3RoZXIgcHJv YmxlbXMgd2l0aCBteSBiYWNrdXAvcmVzdG9yZSBwcm9jZWR1cmU/DQo+DQo+IFRoYW5rIHlvdSwN Cj4NCj4gQ2hyaXMNCj4NCj4gUFM6IFRoZSBzeXN0ZW0gaXMgYSBmaWxlIHNlcnZlciB3aXRoIG5l YXJseSBhbGwgZGF0YSBzdG9yZWQgb24gYSB6cG9vbA0KPiB0aGF0IGlzIG5vdCAienJvb3QiLg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVl YnNkLWZzQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwczovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1mcw0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBh bnkgbWFpbCB0byAiZnJlZWJzZC1mcy11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-fs@freebsd.org Sun Nov 22 23:05:26 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3668CA3373B for ; Sun, 22 Nov 2015 23:05:26 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2079A1102 for ; Sun, 22 Nov 2015 23:05:25 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from Chriss-MacBook-Pro.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mango.stankevitz.com (Postfix) with ESMTPSA id 88D3F41A01; Sun, 22 Nov 2015 15:05:24 -0800 (PST) Subject: Re: Recovering a zfs root pool from backup To: =?UTF-8?Q?Karli_Sj=c3=b6berg?= References: <8834bc1f-4e73-4315-a591-a4ff89dc80c9@email.android.com> Cc: FreeBSD Filesystems From: Chris Stankevitz Message-ID: <56524A34.8030806@stankevitz.com> Date: Sun, 22 Nov 2015 15:05:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8834bc1f-4e73-4315-a591-a4ff89dc80c9@email.android.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 23:05:26 -0000 On 11/22/15 12:32 AM, Karli Sjöberg wrote: > > 1. I doubt I can create a new pool called "zroot" on Machine B since it > > is already running a pool called "zroot" > > > > 2. I doubt that this process will create the appropriate "boot sector" > > stuff (I do not know what I am talking about here). > > Exactly. You'd need to boot the machine from CD/USB to be able to > receive the stream. About the boot stuff. That would need to be handled > when partitioning the new drive: > # gpart create -t gpt (a)?da[0-9]+ > # gpart add -t freebsd-boot -s 64k -l boot0 (a)?da[0-9]+ > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 (a)?da[0-9]+ > # gpart add -t freebsd-swap -b 2048 -s xg -l swap0 (a)?da[0-9]+ > # gpart add -t freebsd-zfs -a 4k -l sys0 (a)?da[0-9]+ > # sysctl vfs.zfs.min_auto_ashift=12 > > Also you need to set the "bootfs" property after the receive: > # zpool set bootfs=zroot zroot Karli, Thank you. Should I be concerned that I cannot "zpool create zroot" from my recovery setup because there will already be a pool with that name? If so, how should I get around that? I know I can give it a temporarily different name and later export/import to rename it -- but it's not clear to me that I will ever get that renamed given that I will always be running FreeBSD with a zroot. Perhaps I could give it a different name "zroot2" (and "zpool set bootfs=zroot2 zroot2")... boot to that... then rename it back to zroot and reboot to complete the restore. Thank you again, Chris From owner-freebsd-fs@freebsd.org Mon Nov 23 06:35:50 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DCECA355C7 for ; Mon, 23 Nov 2015 06:35:50 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from EXCH2-1.slu.se (webmail.slu.se [77.235.224.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C065D15AD for ; Mon, 23 Nov 2015 06:35:49 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from Exch2-2.slu.se (77.235.224.122) by EXCH2-1.slu.se (77.235.224.121) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 Nov 2015 07:20:37 +0100 Received: from Exch2-2.slu.se ([fe80::9023:6997:a676:a304]) by Exch2-2.slu.se ([fe80::9023:6997:a676:a304%23]) with mapi id 15.00.1104.000; Mon, 23 Nov 2015 07:20:36 +0100 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: Chris Stankevitz CC: FreeBSD Filesystems Subject: Re: Recovering a zfs root pool from backup Thread-Topic: Recovering a zfs root pool from backup Thread-Index: AQHRJQBCR2hkpvI3C0qCBcQnAeh6oJ6omcUAgAB5mYA= Date: Mon, 23 Nov 2015 06:20:36 +0000 Message-ID: <1448259637.3588.8.camel@data-b104.adm.slu.se> References: <8834bc1f-4e73-4315-a591-a4ff89dc80c9@email.android.com> <56524A34.8030806@stankevitz.com> In-Reply-To: <56524A34.8030806@stankevitz.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.235.228.63] Content-Type: text/plain; charset="utf-8" Content-ID: <5F8E71426291EB488BCB0B200804939B@ad.slu.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 06:35:50 -0000 c8O2biAyMDE1LTExLTIyIGtsb2NrYW4gMTU6MDUgLTA4MDAgc2tyZXYgQ2hyaXMgU3Rhbmtldml0 ejoNCj4gT24gMTEvMjIvMTUgMTI6MzIgQU0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOg0KPiA+ICA+ IDEuIEkgZG91YnQgSSBjYW4gY3JlYXRlIGEgbmV3IHBvb2wgY2FsbGVkICJ6cm9vdCIgb24gTWFj aGluZSBCIHNpbmNlIGl0DQo+ID4gID4gaXMgYWxyZWFkeSBydW5uaW5nIGEgcG9vbCBjYWxsZWQg Inpyb290Ig0KPiA+ICA+DQo+ID4gID4gMi4gSSBkb3VidCB0aGF0IHRoaXMgcHJvY2VzcyB3aWxs IGNyZWF0ZSB0aGUgYXBwcm9wcmlhdGUgImJvb3Qgc2VjdG9yIg0KPiA+ICA+IHN0dWZmIChJIGRv IG5vdCBrbm93IHdoYXQgSSBhbSB0YWxraW5nIGFib3V0IGhlcmUpLg0KPiA+DQo+ID4gRXhhY3Rs eS4gWW91J2QgbmVlZCB0byBib290IHRoZSBtYWNoaW5lIGZyb20gQ0QvVVNCIHRvIGJlIGFibGUg dG8NCj4gPiByZWNlaXZlIHRoZSBzdHJlYW0uIEFib3V0IHRoZSBib290IHN0dWZmLiBUaGF0IHdv dWxkIG5lZWQgdG8gYmUgaGFuZGxlZA0KPiA+IHdoZW4gcGFydGl0aW9uaW5nIHRoZSBuZXcgZHJp dmU6DQo+ID4gIyBncGFydCBjcmVhdGUgLXQgZ3B0IChhKT9kYVswLTldKw0KPiA+ICMgZ3BhcnQg YWRkIC10IGZyZWVic2QtYm9vdCAtcyA2NGsgLWwgYm9vdDAgKGEpP2RhWzAtOV0rDQo+ID4gIyBn cGFydCBib290Y29kZSAtYiAvYm9vdC9wbWJyIC1wIC9ib290L2dwdHpmc2Jvb3QgLWkgMSAoYSk/ ZGFbMC05XSsNCj4gPiAjIGdwYXJ0IGFkZCAtdCBmcmVlYnNkLXN3YXAgLWIgMjA0OCAtcyB4ZyAt bCBzd2FwMCAoYSk/ZGFbMC05XSsNCj4gPiAjIGdwYXJ0IGFkZCAtdCBmcmVlYnNkLXpmcyAtYSA0 ayAtbCBzeXMwIChhKT9kYVswLTldKw0KPiA+ICMgc3lzY3RsIHZmcy56ZnMubWluX2F1dG9fYXNo aWZ0PTEyDQo+ID4NCj4gPiBBbHNvIHlvdSBuZWVkIHRvIHNldCB0aGUgImJvb3RmcyIgcHJvcGVy dHkgYWZ0ZXIgdGhlIHJlY2VpdmU6DQo+ID4gIyB6cG9vbCBzZXQgYm9vdGZzPXpyb290IHpyb290 DQo+IA0KPiBLYXJsaSwNCj4gDQo+IFRoYW5rIHlvdS4gIFNob3VsZCBJIGJlIGNvbmNlcm5lZCB0 aGF0IEkgY2Fubm90ICJ6cG9vbCBjcmVhdGUgenJvb3QiIA0KPiBmcm9tIG15IHJlY292ZXJ5IHNl dHVwIGJlY2F1c2UgdGhlcmUgd2lsbCBhbHJlYWR5IGJlIGEgcG9vbCB3aXRoIHRoYXQgbmFtZT8N Cg0KWW91wrRyZSBzdGlsbCB0aGlua2luZyBvZiBkb2luZyB0aGUgcmVzdG9yZSBwcm9jZXNzIGZy b20gIk1hY2hpbmUgQiIuDQpEcm9wIHRoYXQgYW5kIGRvIGl0IGZyb20gIk1hY2hpbmUgQSIgaW5z dGVhZC4gSnVzdCBtYWtlIHN1cmUgdGhhdCB5b3UNCmJvb3QgIk1hY2hpbmUgQSIgZnJvbSBDRC9V U0IuIFRoZW4gdGhlcmUgd2lsbCBiZSBubyBwb29sIGNhbGxlZA0KInpyb290IjopDQoNCi9LDQoN Cj4gDQo+IElmIHNvLCBob3cgc2hvdWxkIEkgZ2V0IGFyb3VuZCB0aGF0PyAgSSBrbm93IEkgY2Fu IGdpdmUgaXQgYSB0ZW1wb3JhcmlseSANCj4gZGlmZmVyZW50IG5hbWUgYW5kIGxhdGVyIGV4cG9y dC9pbXBvcnQgdG8gcmVuYW1lIGl0IC0tIGJ1dCBpdCdzIG5vdCANCj4gY2xlYXIgdG8gbWUgdGhh dCBJIHdpbGwgZXZlciBnZXQgdGhhdCByZW5hbWVkIGdpdmVuIHRoYXQgSSB3aWxsIGFsd2F5cyAN Cj4gYmUgcnVubmluZyBGcmVlQlNEIHdpdGggYSB6cm9vdC4NCj4gDQo+IFBlcmhhcHMgSSBjb3Vs ZCBnaXZlIGl0IGEgZGlmZmVyZW50IG5hbWUgInpyb290MiIgKGFuZCAienBvb2wgc2V0IA0KPiBi b290ZnM9enJvb3QyIHpyb290MiIpLi4uIGJvb3QgdG8gdGhhdC4uLiB0aGVuIHJlbmFtZSBpdCBi YWNrIHRvIHpyb290IA0KPiBhbmQgcmVib290IHRvIGNvbXBsZXRlIHRoZSByZXN0b3JlLg0KPiAN Cj4gVGhhbmsgeW91IGFnYWluLA0KPiANCj4gQ2hyaXMNCg0K From owner-freebsd-fs@freebsd.org Mon Nov 23 10:32:44 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45D69A306DC for ; Mon, 23 Nov 2015 10:32:44 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mxout01.bytecamp.net (mxout01.bytecamp.net [212.204.60.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03CDB1139 for ; Mon, 23 Nov 2015 10:32:43 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: by mxout01.bytecamp.net (Postfix, from userid 1001) id A8A4F30FD11; Mon, 23 Nov 2015 11:32:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bytecamp.net; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=20140709; bh=rqmf2FUAC1oilE4Q8nvwrzVTuzA=; b=LNpU/25bl7Jb5qcyDkm2adUIbenNseTWjEizYuYzIRlBHNoGHUDr9MpRWtieIiVnUtiA0yVeaARR7nfaBmLVtpIM4mkNIZBgiKHa38VVGYmWnnJkoXtONYSTycX+y2aTtQkA0OI7m27+C/4ygCxmUwuIHCAhqBnrhbE8MdwhoQ8= Received: from mail.bytecamp.net (mailstore.bytecamp.net [212.204.60.20]) by mxout01.bytecamp.net (Postfix) with ESMTP id 5265530FD00 for ; Mon, 23 Nov 2015 11:32:35 +0100 (CET) Received: (qmail 30753 invoked by uid 89); 23 Nov 2015 11:32:35 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with AES128-SHA encrypted SMTP; 23 Nov 2015 11:32:35 +0100 Subject: Re: filesystem deadlock, process in vodead state To: Dmitriy Makarov , freebsd-fs@freebsd.org References: <564D9930.1080509@bytecamp.net> <1447936216089-6054111.post@n5.nabble.com> From: Robert Schulze Organization: bytecamp GmbH Message-ID: <5652EB43.1060504@bytecamp.net> Date: Mon, 23 Nov 2015 11:32:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1447936216089-6054111.post@n5.nabble.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 10:32:44 -0000 Hi, Am 19.11.2015 um 13:30 schrieb Dmitriy Makarov: > Hi, > > we has exactly the same issue on our two boxes, running CURRENT. > But in our case stuck is on read one exactly file: ls $file - works fine, > cat $file - hang. > The file is on ZFS pool, stripe of mirrors too. I have opened a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204764 regards, Robert Schulze From owner-freebsd-fs@freebsd.org Mon Nov 23 18:53:24 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F8F4A362B4 for ; Mon, 23 Nov 2015 18:53:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEDC61ADA for ; Mon, 23 Nov 2015 18:53:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tANIrN1e017890 for ; Mon, 23 Nov 2015 18:53:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Mon, 23 Nov 2015 18:53:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 18:53:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204764 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 24 05:11:20 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16657A2995B for ; Tue, 24 Nov 2015 05:11:20 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id EC0B11ECE for ; Tue, 24 Nov 2015 05:11:19 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from Chriss-MacBook-Pro.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mango.stankevitz.com (Postfix) with ESMTPSA id 1303D41B11; Mon, 23 Nov 2015 21:11:13 -0800 (PST) Subject: Re: Recovering a zfs root pool from backup To: =?UTF-8?Q?Karli_Sj=c3=b6berg?= References: <8834bc1f-4e73-4315-a591-a4ff89dc80c9@email.android.com> <56524A34.8030806@stankevitz.com> <1448259637.3588.8.camel@data-b104.adm.slu.se> Cc: FreeBSD Filesystems From: Chris Stankevitz Message-ID: <5653F170.2070307@stankevitz.com> Date: Mon, 23 Nov 2015 21:11:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1448259637.3588.8.camel@data-b104.adm.slu.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 05:11:20 -0000 On 11/22/15 10:20 PM, Karli Sjöberg wrote: > You´re still thinking of doing the restore process from "Machine B". > Drop that and do it from "Machine A" instead. Just make sure that you > boot "Machine A" from CD/USB. Then there will be no pool called > "zroot":) Karli, Thanks again. Because the FreeBSD live CD/USB would have to deal with the same problem that I am worried about... they must have worked around it. Probaby a) not using ZFS on the boot CD/USB or b) using ZFS but not calling the pool 'zroot'. I'll find out the next time I boot one up. But your point is clear: not something I need to worry about. Thanks again, Chris From owner-freebsd-fs@freebsd.org Tue Nov 24 16:27:37 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E1C3A3731E for ; Tue, 24 Nov 2015 16:27:37 +0000 (UTC) (envelope-from case@SDF.ORG) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "SDF.ORG" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B3751936 for ; Tue, 24 Nov 2015 16:27:36 +0000 (UTC) (envelope-from case@SDF.ORG) Received: from otaku.freeshell.org (IDENT:case@otaku.freeshell.org [192.94.73.9]) by sdf.lonestar.org (8.15.2/8.14.5) with ESMTPS id tAOGQqv2015059 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Tue, 24 Nov 2015 16:27:23 GMT Date: Tue, 24 Nov 2015 16:26:51 +0000 (UTC) From: John Case X-X-Sender: case@faeroes.freeshell.org To: freebsd-fs@freebsd.org Subject: so ... what *are* we doing about byzantine ZFS send/recv streams ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:27:37 -0000 I was reading a thread on HN about ZFS[1] when someone from rsync.net commented that they support ZFS send/recv to their cloud platform.[2] Someone else responded in that thread asking how they dealt with "byzantine streams", by which they meant a ZFS stream that has been corrupted on purpose so as to panic the receiver (or worse). The rsync.net guy said they gave everyone their own zpool inside their own bhyve so there isn't a big concern there - at worst "it might be a DOS attack". So my questions: 1. What, if anything, does FreeBSD 10.x do about "byzantine streams" and is there any mitigation of this ? 2. If I allow someone to ZFS send a arbitrary snapshot to me, does locking them in a VM like the guy suggests a good solution ? Or is there still a security/corruption threat there ? Thank you. [1] https://news.ycombinator.com/item?id=10568705 [2] http://www.rsync.net/products/zfsintro.html From owner-freebsd-fs@freebsd.org Wed Nov 25 12:14:35 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FE1BA372F1 for ; Wed, 25 Nov 2015 12:14:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D32181243 for ; Wed, 25 Nov 2015 12:14:34 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.160.217] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a1Yxu-0004sW-1R; Wed, 25 Nov 2015 13:14:26 +0100 Date: Wed, 25 Nov 2015 13:14:25 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Cc: John Case Subject: Re: so ... what *are* we doing about byzantine ZFS send/recv streams ? Message-ID: <20151125131425.071dcae1@fabiankeil.de> In-Reply-To: References: Reply-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4+sxasYsEnLHjNKG2zmr_jV"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 12:14:35 -0000 --Sig_/4+sxasYsEnLHjNKG2zmr_jV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable John Case wrote: > I was reading a thread on HN about ZFS[1] when someone from rsync.net=20 > commented that they support ZFS send/recv to their cloud platform.[2] >=20 > Someone else responded in that thread asking how they dealt with=20 > "byzantine streams", by which they meant a ZFS stream that has been=20 > corrupted on purpose so as to panic the receiver (or worse). >=20 > The rsync.net guy said they gave everyone their own zpool inside their ow= n=20 > bhyve so there isn't a big concern there - at worst "it might be a DOS=20 > attack". >=20 >=20 > So my questions: >=20 >=20 > 1. What, if anything, does FreeBSD 10.x do about "byzantine streams" and= =20 > is there any mitigation of this ? FreeBSD 10.x "does" nothing about this and merely inherits the issue from upstream. At the last OpenZFS developer summit the issue was briefly looked at and considered too complicated/expensive to solve completely. The people who looked at it mainly cared about the (Joyent) use case where the receiving and sending systems have trusted kernels, in which case signi= ng the streams is sufficient to workaround the issue. For details see: https://youtu.be/vKiJzj-vRYM For the "backup server" use case the issue can be mitigated by letting the clients access the storage through ggate (or iSCSI etc.) in which case the server does not have to parse the ZFS receive streams. If the clients additionally use geli they are also less likely to be successfully attacked by a compromised server. Example configurations: https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00029.html https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00030.html > 2. If I allow someone to ZFS send a arbitrary snapshot to me, does lockin= g=20 > them in a VM like the guy suggests a good solution ? Or is there still a= =20 > security/corruption threat there ? Whether or not it's a good solution depends on the use case. Being able to receive ZFS streams probably gives a motivated attacker complete control over the virtualized system in which case she's one VM vulnerability away from controlling the host system. Fabian --Sig_/4+sxasYsEnLHjNKG2zmr_jV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZVpiEACgkQBYqIVf93VJ0NYgCeLqFbZ/bS8me+tPV4e19ptxPf VAgAoJt1KKPz44Pu+mv0JdVD06G0XXoD =xYbs -----END PGP SIGNATURE----- --Sig_/4+sxasYsEnLHjNKG2zmr_jV-- From owner-freebsd-fs@freebsd.org Thu Nov 26 21:12:03 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D3B6A3A399 for ; Thu, 26 Nov 2015 21:12:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89C391152 for ; Thu, 26 Nov 2015 21:12:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAQLC3In007859 for ; Thu, 26 Nov 2015 21:12:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204337] ZFS can have a non-empty directory, but the files don't exist. Date: Thu, 26 Nov 2015 21:12:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 21:12:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204337 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Blocks| |203349 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Fri Nov 27 15:31:11 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3223EA3AEF3 for ; Fri, 27 Nov 2015 15:31:11 +0000 (UTC) (envelope-from k@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79A381D72 for ; Fri, 27 Nov 2015 15:31:09 +0000 (UTC) (envelope-from k@free.de) Received: (qmail 92666 invoked from network); 27 Nov 2015 16:24:25 +0100 Received: from smtp.free.de (HELO [91.204.7.14]) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 27 Nov 2015 16:24:25 +0100 To: freebsd-fs@freebsd.org From: Kai Gallasch Subject: High fragmentation on zpool log X-Enigmail-Draft-Status: N1210 Organization: FREE! Message-ID: <565875A7.6060004@free.de> Date: Fri, 27 Nov 2015 16:24:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R6g0d5tPOrX8t4sWAxN2vJF140WrSWUD0" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 15:31:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R6g0d5tPOrX8t4sWAxN2vJF140WrSWUD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi. Today I had a look at the zpool of a server (FreeBSD 10.2, GENERIC kernel, 100d uptime, 96GB RAM) I recently installed. The pool has eight SAS drives in a raid 10 setup (concatenated mirror pairs) and uses a cache and a mirrored log. The log and cache both are on a pair of Intel SSDs. # gpart show -l da9 =3D> 34 195371501 da9 GPT (93G) 34 6 - free - (3.0K) 40 16777216 1 log-BTTV5234003K100FGN (8.0G) 16777256 178594272 2 cache-BTTV5234003K100FGN (85G) 195371528 7 - free - (3.5K) Is 85% fragmentation of the log device something to worry about? Why does zpool list show so unrealistic values for FREE and CAP? Is this normal? Atached: Some output of zpool list. Regards, Kai. (zpool list -v output, ommited columns: EXPANDSZ.,DEDUP, HEALTH, ALTROOT) NAME SIZE ALLOC FREE FRAG CAP rpool 7.25T 440G 6.82T 4% 5% mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D0SVZE - - - - - gpt/rpool-WMC160D8MJPD - - - - - mirror 1.81T 110G 1.70T 4% 5% gpt/rpool-WMC160D9DLL2 - - - - - gpt/rpool-WMC160D23CWA - - - - - mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D94930 - - - - - gpt/rpool-WMC160D9V5LW - - - - - mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D9ZV0S - - - - - gpt/rpool-WMC160D5HFT6 - - - - - mirror 7.94G 43.2M 7.90G 85% 0% gpt/log-BTTV523401U4100FGN - - - - - gpt/log-BTTV5234003K100FGN - - - - - cache - - - - - gpt/cache-BTTV5234003K100FGN 85.2G 142G 16.0E 0% 166% gpt/cache-BTTV523401U4100FGN 85.2G 172G 16.0E 0% 202% --=20 PGP-KeyID =3D 0x70654D7C4FB1F588 --R6g0d5tPOrX8t4sWAxN2vJF140WrSWUD0 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.22 (GNU/Linux) iQIcBAEBCgAGBQJWWHWoAAoJEHBlTXxPsfWIgmEP/j8sWZo3sCXwjdBU7wYbIW+C /weohJEMt779o9ZbPTgWqLbFlVlxSdghzNcsvo8eFZzLH1KeXPRaYPMUvBWpAHSV Ei454xQfMwAVqvVwWHw3peUVB6oR5QrBXHiGnogCgjTF+Vrt5V4XhJCmKNqdc1Kq wrk5HsyFDpHYYAN8Zbl01PkgYiSJ5W4dD1hdKIMmt0NhiT8nJWVOopbxhK/SKmaR NHxWIbab1ZukGxuoLURZ+dk8ojjmKiEJQl7/sjjWk16jVtGts8qYXEgEt2l6ftvm o22LTSBFztx3E49lcxutNfa+pdnqJ6Jzm7O5n08GGcZ4derB/jBUdmP970yI+4Gh T80TooepbS+eUmHlCrBL96sTbYji2KaCE7gVrYXBV9v6s8qxldY9r2rKos2VkaWu UzleRWSgD9k8t2/lh762RGc74iSKbLjOD25ifmPQwbgM68q+RIMPVeZ01OAJVUS6 1K98s2yDxb7vNMT0+mn6T8YkKc+lincOYTBgM+Qq5t/UfnLaYFXEPWIbOnQwKkcZ 0TQjYtlofZsRjG/HAosBv/wLHHgfzUD9Um6QpgGOakHIp2ql+6dssLWZD8/ZWT9T Vdij5elYA1RgtqrNry+2lbT8E3KQoLGz1ChfbmFE13GChgCKXoc8hvYPdOTzgCTf XtAhTItvVhlMF2sS5slb =NbAD -----END PGP SIGNATURE----- --R6g0d5tPOrX8t4sWAxN2vJF140WrSWUD0-- From owner-freebsd-fs@freebsd.org Fri Nov 27 15:58:40 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643D5A39813 for ; Fri, 27 Nov 2015 15:58:40 +0000 (UTC) (envelope-from jg@internetx.com) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2814D1D23 for ; Fri, 27 Nov 2015 15:58:39 +0000 (UTC) (envelope-from jg@internetx.com) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id B021E1472002; Fri, 27 Nov 2015 16:49:24 +0100 (CET) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8KG+UVccNCS; Fri, 27 Nov 2015 16:49:22 +0100 (CET) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 71DA34C4C59E; Fri, 27 Nov 2015 16:49:22 +0100 (CET) Subject: Re: High fragmentation on zpool log References: <565875A7.6060004@free.de> To: Kai Gallasch , freebsd-fs@freebsd.org Reply-To: jg@internetx.com From: InterNetX - Juergen Gotteswinter Message-ID: <56587B83.9020506@internetx.com> Date: Fri, 27 Nov 2015 16:49:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565875A7.6060004@free.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 15:58:40 -0000 Your SSDS are not really attached as Zil ? Am 27.11.2015 um 16:24 schrieb Kai Gallasch: > > Hi. > > Today I had a look at the zpool of a server (FreeBSD 10.2, GENERIC > kernel, 100d uptime, 96GB RAM) I recently installed. > > The pool has eight SAS drives in a raid 10 setup (concatenated mirror > pairs) and uses a cache and a mirrored log. > > The log and cache both are on a pair of Intel SSDs. > > # gpart show -l da9 > => 34 195371501 da9 GPT (93G) > 34 6 - free - (3.0K) > 40 16777216 1 log-BTTV5234003K100FGN (8.0G) > 16777256 178594272 2 cache-BTTV5234003K100FGN (85G) > 195371528 7 - free - (3.5K) > > > Is 85% fragmentation of the log device something to worry about? > > Why does zpool list show so unrealistic values for FREE and CAP? > Is this normal? > > Atached: Some output of zpool list. > > Regards, > Kai. > > > (zpool list -v output, ommited columns: EXPANDSZ.,DEDUP, > HEALTH, ALTROOT) > > NAME SIZE ALLOC FREE FRAG CAP > rpool 7.25T 440G 6.82T 4% 5% > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D0SVZE - - - - - > gpt/rpool-WMC160D8MJPD - - - - - > mirror 1.81T 110G 1.70T 4% 5% > gpt/rpool-WMC160D9DLL2 - - - - - > gpt/rpool-WMC160D23CWA - - - - - > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D94930 - - - - - > gpt/rpool-WMC160D9V5LW - - - - - > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D9ZV0S - - - - - > gpt/rpool-WMC160D5HFT6 - - - - - > mirror 7.94G 43.2M 7.90G 85% 0% > gpt/log-BTTV523401U4100FGN - - - - - > gpt/log-BTTV5234003K100FGN - - - - - > cache - - - - - > gpt/cache-BTTV5234003K100FGN 85.2G 142G 16.0E 0% 166% > gpt/cache-BTTV523401U4100FGN 85.2G 172G 16.0E 0% 202% > > > From owner-freebsd-fs@freebsd.org Fri Nov 27 16:18:26 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F5EEA39F02 for ; Fri, 27 Nov 2015 16:18:26 +0000 (UTC) (envelope-from k@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E614B1CC5 for ; Fri, 27 Nov 2015 16:18:25 +0000 (UTC) (envelope-from k@free.de) Received: (qmail 40169 invoked from network); 27 Nov 2015 17:18:22 +0100 Received: from smtp.free.de (HELO [91.204.7.14]) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 27 Nov 2015 17:18:22 +0100 Subject: Re: High fragmentation on zpool log To: jg@internetx.com, freebsd-fs@freebsd.org References: <565875A7.6060004@free.de> <56587B83.9020506@internetx.com> From: Kai Gallasch Organization: FREE! Message-ID: <5658824D.6070800@free.de> Date: Fri, 27 Nov 2015 17:18:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56587B83.9020506@internetx.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f0VgWuvQVhueBTxkSTRx4AqwW02u558V0" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 16:18:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f0VgWuvQVhueBTxkSTRx4AqwW02u558V0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27.11.2015 16:49 InterNetX - Juergen Gotteswinter wrote: > Your SSDS are not really attached as Zil ? Sorry. Due to copying&pasting a condensed version of zpool list -v, I forgot to paste a line.. so this is the corrected version: Sorry, Kai. (zpool list -v output, ommited columns: EXPANDSZ.,DEDUP, HEALTH, ALTROOT) NAME SIZE ALLOC FREE FRAG CAP rpool 7.25T 440G 6.82T 4% 5% mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D0SVZE - - - - - gpt/rpool-WMC160D8MJPD - - - - - mirror 1.81T 110G 1.70T 4% 5% gpt/rpool-WMC160D9DLL2 - - - - - gpt/rpool-WMC160D23CWA - - - - - mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D94930 - - - - - gpt/rpool-WMC160D9V5LW - - - - - mirror 1.81T 110G 1.71T 4% 5% gpt/rpool-WMC160D9ZV0S - - - - - gpt/rpool-WMC160D5HFT6 - - - - - logs mirror 7.94G 43.2M 7.90G 85% 0% gpt/log-BTTV523401U4100FGN - - - - - gpt/log-BTTV5234003K100FGN - - - - - cache - - - - - gpt/cache-BTTV5234003K100FGN 85.2G 142G 16.0E 0% 166% gpt/cache-BTTV523401U4100FGN 85.2G 172G 16.0E 0% 202% --f0VgWuvQVhueBTxkSTRx4AqwW02u558V0 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.22 (GNU/Linux) iQIcBAEBCgAGBQJWWIJNAAoJEHBlTXxPsfWI2i8P/3cT/lpOjno4CMvQotSXpJHL hJ+hA1WzbbqWVUnX9ml0IF6VH78Kb2tnj2sWjF7upPdQ1LEjKryXPZfMiksrKFDu aMcfH9kkMgZP0Bd2qfKJB+6yPxq1ktHA0jD6EtrA7FvABzkuftNajsHEWokjDxW+ kb+LbssqiUeigSMQTKjAX+rmKwBsLmsYI1Pu4/5tg/iGB43b/uLg7uhaCSeFU+GL +6FlDm6IU9QXLhrB1bUPfXtl+QzF3atnrLVj5aKHytShQPZaAlEtqXG4CkiLHMN8 Lg2WrzgNr/v9f7sumZ7kRtNNuFYMta8aqa1QGLQq9DREZzdoWCUR76Of95dK+S9a w03bL1GtkyNKEqgF7GCggUU0U7Q+a+X5UAiy558cqdLVR47I8PXIidTiIhnnJD9N 005mQH+XaTX1gavAIx+seqygmm/wXcrqgeVgd1VQGECT1Xf0fCLjN874RuN9AHFf fV2U9TXKGM2+uaKfYV85BuviMJgrH5EpRF8gLJRGci1HbPgxS8cYM5/HCMQF4xn1 cPno11k0clVLmk9+RShhmqkbGLUXuuDpLZVsYPSvcvaNE0SOKuq4SUXPdUrxVqV+ 8lQre5mCPIUDHakdeUk+quulxc4UcPxPJnl/XNeVnCPM9eNYCFgR/nc0RjEF55+f rj6All6DLzrR5e10I+bX =sR7f -----END PGP SIGNATURE----- --f0VgWuvQVhueBTxkSTRx4AqwW02u558V0-- From owner-freebsd-fs@freebsd.org Fri Nov 27 16:22:01 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FF90A3A0F3 for ; Fri, 27 Nov 2015 16:22:01 +0000 (UTC) (envelope-from jg@internetx.com) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01C4111F4 for ; Fri, 27 Nov 2015 16:22:00 +0000 (UTC) (envelope-from jg@internetx.com) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id 93BC51472002; Fri, 27 Nov 2015 17:21:58 +0100 (CET) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0f2w7RKW1Rs; Fri, 27 Nov 2015 17:21:56 +0100 (CET) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id B2B651472004; Fri, 27 Nov 2015 17:21:56 +0100 (CET) Reply-To: jg@internetx.com Subject: Re: High fragmentation on zpool log References: <565875A7.6060004@free.de> <56587B83.9020506@internetx.com> <5658824D.6070800@free.de> To: Kai Gallasch , freebsd-fs@freebsd.org From: InterNetX - Juergen Gotteswinter Message-ID: <56588326.8050800@internetx.com> Date: Fri, 27 Nov 2015 17:21:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5658824D.6070800@free.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 16:22:01 -0000 Am 27.11.2015 um 17:18 schrieb Kai Gallasch: > On 27.11.2015 16:49 InterNetX - Juergen Gotteswinter wrote: >> Your SSDS are not really attached as Zil ? > > Sorry. Due to copying&pasting a condensed version of zpool list -v, I > forgot to paste a line.. so this is the corrected version: > > Sorry, > Kai. > :) i think this is caused by the size of your Zil, dunno if its really something to care about ( i whould not worry about). More problematic (regarding SSD Lifetime) is the dual use of SSD for ZIL / L2. Your Flash Drives get hammered with writes from 2 Sides. Write Caching, and L2 Feed ing. > > (zpool list -v output, ommited columns: EXPANDSZ.,DEDUP, > HEALTH, ALTROOT) > > NAME SIZE ALLOC FREE FRAG CAP > rpool 7.25T 440G 6.82T 4% 5% > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D0SVZE - - - - - > gpt/rpool-WMC160D8MJPD - - - - - > mirror 1.81T 110G 1.70T 4% 5% > gpt/rpool-WMC160D9DLL2 - - - - - > gpt/rpool-WMC160D23CWA - - - - - > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D94930 - - - - - > gpt/rpool-WMC160D9V5LW - - - - - > mirror 1.81T 110G 1.71T 4% 5% > gpt/rpool-WMC160D9ZV0S - - - - - > gpt/rpool-WMC160D5HFT6 - - - - - > logs > mirror 7.94G 43.2M 7.90G 85% 0% > gpt/log-BTTV523401U4100FGN - - - - - > gpt/log-BTTV5234003K100FGN - - - - - > cache - - - - - > gpt/cache-BTTV5234003K100FGN 85.2G 142G 16.0E 0% 166% > gpt/cache-BTTV523401U4100FGN 85.2G 172G 16.0E 0% 202% > > > > > From owner-freebsd-fs@freebsd.org Sat Nov 28 00:18:07 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 572C2A36090 for ; Sat, 28 Nov 2015 00:18:07 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A34413D4 for ; Sat, 28 Nov 2015 00:18:06 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from [192.168.1.8] ([100.1.236.52]) by vms173011.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0NYH00CCZY1KT100@vms173011.mailsrvcs.net> for freebsd-fs@freebsd.org; Fri, 27 Nov 2015 17:17:45 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Nc0brD34 c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=qtqOOiqGOCEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=FOgapiqSnp4Hhr6GXaoA:9 a=QEXdDO2ut3YA:10 a=-e6_ufxW9dpez5ZrTscA:9 a=_W_S_7VecoQA:10 From: "Mikhail T." Subject: Recovering an unlink-ed, but still opened file To: freebsd-fs@freebsd.org Message-id: <5658E498.9070700@aldan.algebra.com> Date: Fri, 27 Nov 2015 18:17:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 00:18:07 -0000 A deleted file, that's still opened by a process is "there" on the filesystem. Is there any way -- with an existing command-line utility or a new program using an existing API -- to give the still-valid inode a name again? Wouldn't that be a wonderful feature to have? Thanks! -mi From owner-freebsd-fs@freebsd.org Sat Nov 28 02:46:50 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17AAFA3BC40 for ; Sat, 28 Nov 2015 02:46:50 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC03F1EF4 for ; Sat, 28 Nov 2015 02:46:49 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: by vkbs1 with SMTP id s1so76683699vkb.1 for ; Fri, 27 Nov 2015 18:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rPmF1sRZAQNFZpB0tIcBuRRvudJRGqRgZbBCjjLgPI=; b=DKzoo1UbXJRnd7J6wAui61SQMw+CgOT5mfjepY/PqZMQnt8S5nVjw4ZgNI0XONGJ+X Ov/pJKgbAOfQbggFG8pHlt1AqhY6hFLM8r+GnYiNEZEhxR3/8nwDcndhVv/ge2jtky2s KHjHteIyWw3gB8JsaFt0CJ5ZUbnsSlKmhLWq0r6vyvXUaTdsgFlfn1eJwqzAfgfrI/y/ vSkdjsRxO9jGoF/YyyjoeHZLF8HA+eZWB2QTPS0pPTR+sLNRItDU32fVMS/rwJLa4y2Z 4gcCfRpJFDZ9/Nm3d99ZEIxOEu8d4GCv1ZoO4zGj3O5Ir0TJRJsJBbT5EAF2UFEbY9s1 sprA== MIME-Version: 1.0 X-Received: by 10.31.135.2 with SMTP id j2mr43760442vkd.91.1448678808565; Fri, 27 Nov 2015 18:46:48 -0800 (PST) Received: by 10.103.108.3 with HTTP; Fri, 27 Nov 2015 18:46:48 -0800 (PST) Received: by 10.103.108.3 with HTTP; Fri, 27 Nov 2015 18:46:48 -0800 (PST) In-Reply-To: <5658E498.9070700@aldan.algebra.com> References: <5658E498.9070700@aldan.algebra.com> Date: Fri, 27 Nov 2015 18:46:48 -0800 Message-ID: Subject: Re: Recovering an unlink-ed, but still opened file From: "alex.burlyga.ietf alex.burlyga.ietf" To: "Mikhail T." Cc: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 02:46:50 -0000 If you know which process and which file descriptor, should be able to just copy from /proc//fd/ to a file. I would try that first. Alex. On Nov 27, 2015 16:18, "Mikhail T." wrote: > A deleted file, that's still opened by a process is "there" on the > filesystem. > > Is there any way -- with an existing command-line utility or a new > program using an existing API -- to give the still-valid inode a name > again? Wouldn't that be a wonderful feature to have? Thanks! > > -mi > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Sat Nov 28 03:30:22 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1968A39CD4 for ; Sat, 28 Nov 2015 03:30:22 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89DE517F6 for ; Sat, 28 Nov 2015 03:30:22 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: by vkay187 with SMTP id y187so76781263vka.3 for ; Fri, 27 Nov 2015 19:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H49mACP1gojftMr2L3QjAEtHtrTMn79L/KcHCVNcaBM=; b=vLeh75dFfVys3BcVI5kJtp8CrW5n5STaZ9F8uE0d52gMXIIBQ1Z2SVaCNRDmOI+v6h 2bpkJC1+sjC8Bsv2Dv7sVV5P2E/blg3cL0S9/Qiszwmddh0Zns+Hcg4ml67AKnRsN9jf GL5MVxanUe8NhRe1vTuT0QGOZKgz5b0hTUU7enBrp9vo8sPkvQ/iE9pBHRFcE7jB+vj/ 2PXWXlksafJiU4aIGp3ay82WvJZC0KYSuh4oi7iLAOyziTCuxYmTOQkUaDGg3QfBBKs3 a19oSjjNGo8zh/J2vIacasreWPQSk6DgWXj91UTXi+3ygZeSlc3tv5l2o1LzdEP+ccHx j0fA== MIME-Version: 1.0 X-Received: by 10.31.194.201 with SMTP id s192mr45658102vkf.92.1448681421691; Fri, 27 Nov 2015 19:30:21 -0800 (PST) Received: by 10.103.108.3 with HTTP; Fri, 27 Nov 2015 19:30:21 -0800 (PST) Received: by 10.103.108.3 with HTTP; Fri, 27 Nov 2015 19:30:21 -0800 (PST) In-Reply-To: <56591999.1040001@aldan.algebra.com> References: <5658E498.9070700@aldan.algebra.com> <56591999.1040001@aldan.algebra.com> Date: Fri, 27 Nov 2015 19:30:21 -0800 Message-ID: Subject: Re: Recovering an unlink-ed, but still opened file From: "alex.burlyga.ietf alex.burlyga.ietf" To: "Mikhail T." Cc: freebsd-fs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 03:30:22 -0000 fdescfs is no use here to:-( Is the file on NFS mount by any chance? Then there is .nfsXXXXX files. Alex. On Nov 27, 2015 19:03, "Mikhail T." wrote: > On 27.11.2015 21:46, alex.burlyga.ietf alex.burlyga.ietf wrote: > > If you know which process and which file descriptor, should be able to > just copy from /proc//fd/ to a file. I would try that first. > > I know this trick -- and even used it on Solaris once. It may work on > Linux too. But not on FreeBSD: > > tail -f /var/log/messages > /var/tmp/l & > [1] 13954 > mi@narawntapu:/usr/src (829) rm /var/tmp/l > mi@narawntapu:/usr/src (830) ls -l /proc/13954/fd > ls: /proc/13954/fd: No such file or directory > > Worse, our linprocfs does not support that either: > > mi@narawntapu:/usr/src (831) ls -l /compat/linux/proc/13954/fd > lr--r--r-- 1 mi wheel 0 27 =D0=BB=D0=B8=D1=81 22:00 /compat/linux/proc= /13954/fd -> > *unknown* > > Perhaps more importantly, even if the trick worked, it wouldn't have been= , > what I asked for -- it would've allowed me to create a copy of the file. > I'd like to be able to restore access to the original -- so that, for > example, whatever the process writes to it is still available, etc. Can > that be done somehow? Thanks! Yours, > > -mi > > > From owner-freebsd-fs@freebsd.org Sat Nov 28 04:04:22 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38A17A3A323 for ; Sat, 28 Nov 2015 04:04:22 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CAC714C0 for ; Sat, 28 Nov 2015 04:04:21 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) MIME-version: 1.0 Received: from [192.168.1.8] ([100.1.236.52]) by vms173007.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0NYI007LZ8IHY230@vms173007.mailsrvcs.net> for freebsd-fs@freebsd.org; Fri, 27 Nov 2015 21:03:55 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=MtGvkDue c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=qtqOOiqGOCEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=OLdxXjmIuasWO8Qz8K8A:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=aca3njQzIMUgqc5ctrQA:9 a=QJ9RKmk9sE7axZcg:21 a=_W_S_7VecoQA:10 Subject: Re: Recovering an unlink-ed, but still opened file To: "alex.burlyga.ietf alex.burlyga.ietf" References: <5658E498.9070700@aldan.algebra.com> Cc: freebsd-fs From: "Mikhail T." X-Enigmail-Draft-Status: N1110 Message-id: <56591999.1040001@aldan.algebra.com> Date: Fri, 27 Nov 2015 22:03:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-reply-to: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 04:04:22 -0000 On 27.11.2015 21:46, alex.burlyga.ietf alex.burlyga.ietf wrote: > > If you know which process and which file descriptor, should be able to > just copy from /proc//fd/ to a file. I would try that first. > I know this trick -- and even used it on Solaris once. It may work on Linux too. But not on FreeBSD: tail -f /var/log/messages > /var/tmp/l & [1] 13954 mi@narawntapu:/usr/src (829) rm /var/tmp/l mi@narawntapu:/usr/src (830) ls -l /proc/13954/fd ls: /proc/13954/fd: No such file or directory Worse, our linprocfs does not support that either: mi@narawntapu:/usr/src (831) ls -l /compat/linux/proc/13954/fd lr--r--r-- 1 mi wheel 0 27 лис 22:00 /compat/linux/proc/13954/fd -> *unknown* Perhaps more importantly, even if the trick worked, it wouldn't have been, what I asked for -- it would've allowed me to create a copy of the file. I'd like to be able to restore access to the original -- so that, for example, whatever the process writes to it is still available, etc. Can that be done somehow? Thanks! Yours, -mi From owner-freebsd-fs@freebsd.org Sat Nov 28 05:22:48 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 431C2A3B1E3 for ; Sat, 28 Nov 2015 05:22:48 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAEAB129D for ; Sat, 28 Nov 2015 05:22:47 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by wmww144 with SMTP id w144so73908910wmw.1 for ; Fri, 27 Nov 2015 21:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DfeBTcEYynXM1HYWN8zU0RpA5A4u7zsJXAQfIUXc/U0=; b=0z0zje0oaNfdWoqyaT20FNkbQ3F4IaIAlGEUOZ0Q7b+OK3RtjKu7m3SRzh1Hqht+RG KgFiavJP5hYImqk1Z3dIR50srUKrFEeH1NkR6t+ttUCHz7Zc3TrVQmuiCR1Vc9cxKItE aRF6IqsDhG4mWSiN+bQKb1CVMOsngS2ZgWVq16v0qJ+EMFCdo2mIVaTJ1hbOYg/m+OhH MgxuxSX5lXlScC8nppB1b8opvX829Cz8c94yqKB1ALhR9YogLuVORPphhh3qImVYGhkQ MnsGMQK/0L02rYwdiXECqVoWgD+27i9DdzkjYOO5/sTmNx/BXhUafSl9oyJKJSjDKIFn DbKg== MIME-Version: 1.0 X-Received: by 10.28.222.4 with SMTP id v4mr15570216wmg.67.1448688165366; Fri, 27 Nov 2015 21:22:45 -0800 (PST) Received: by 10.194.192.33 with HTTP; Fri, 27 Nov 2015 21:22:45 -0800 (PST) In-Reply-To: <56591999.1040001@aldan.algebra.com> References: <5658E498.9070700@aldan.algebra.com> <56591999.1040001@aldan.algebra.com> Date: Fri, 27 Nov 2015 23:22:45 -0600 Message-ID: Subject: Re: Recovering an unlink-ed, but still opened file From: Adam Vande More To: "Mikhail T." Cc: "alex.burlyga.ietf alex.burlyga.ietf" , freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 05:22:48 -0000 On Fri, Nov 27, 2015 at 9:03 PM, Mikhail T. wrote: > Perhaps more importantly, even if the trick worked, it wouldn't have > been, what I asked for -- it would've allowed me to create a copy of the > file. I'd like to be able to restore access to the original -- so that, > for example, whatever the process writes to it is still available, etc. > Can that be done somehow? Thanks! Yours, > > -mi > find . -inum -exec mv {} \; -- Adam From owner-freebsd-fs@freebsd.org Sat Nov 28 05:50:09 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0104FA3B487 for ; Sat, 28 Nov 2015 05:50:08 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9F271C8A for ; Sat, 28 Nov 2015 05:50:08 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from [192.168.1.8] ([100.1.236.52]) by vms173001.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0NYI0038KDE9FH20@vms173001.mailsrvcs.net> for freebsd-fs@freebsd.org; Fri, 27 Nov 2015 22:49:29 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=btqxfxui c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=qtqOOiqGOCEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=Sxf2URxz7R3b3xKBua0A:9 a=QEXdDO2ut3YA:10 a=hUpblVa_MaYA:10 a=pGLkceISAAAA:8 a=UNMh7_ci-tjmsUlfdj0A:9 a=_W_S_7VecoQA:10 Subject: Re: Recovering an unlink-ed, but still opened file To: "alex.burlyga.ietf alex.burlyga.ietf" References: <5658E498.9070700@aldan.algebra.com> <56591999.1040001@aldan.algebra.com> Cc: freebsd-fs From: "Mikhail T." Message-id: <56593251.90705@aldan.algebra.com> Date: Fri, 27 Nov 2015 23:49:21 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 In-reply-to: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 05:50:09 -0000 On 27.11.2015 22:30, alex.burlyga.ietf alex.burlyga.ietf wrote: > Is the file on NFS mount by any chance? I don't have an ongoing problem -- I just want to investigate and, if sufficiently easy, implement a solution... -mi From owner-freebsd-fs@freebsd.org Sat Nov 28 09:58:16 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D39FA3ADE6 for ; Sat, 28 Nov 2015 09:58:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECC91A6B for ; Sat, 28 Nov 2015 09:58:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-88.lns20.per1.internode.on.net [121.45.225.88]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAS9vqVr084475 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 28 Nov 2015 01:57:55 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Recovering an unlink-ed, but still opened file To: "Mikhail T." , freebsd-fs@freebsd.org References: <5658E498.9070700@aldan.algebra.com> From: Julian Elischer Message-ID: <56597A9A.5020404@freebsd.org> Date: Sat, 28 Nov 2015 17:57:46 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5658E498.9070700@aldan.algebra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 09:58:16 -0000 On 28/11/2015 7:17 AM, Mikhail T. wrote: > A deleted file, that's still opened by a process is "there" on the > filesystem. > > Is there any way -- with an existing command-line utility or a new > program using an existing API -- to give the still-valid inode a name > again? Wouldn't that be a wonderful feature to have? Thanks! well, I've done this in the distant past: (there may be easier ways involving /proc if you have it mounted etc.) touch /tmp/anyfile gdb cp break main run /tmp/anyfile /tmp/saved (program breaks) break open {step until you get the open of anyfile} place a breakpoint just after the open. continue {program stops with file opened) take note of file descriptor. kgdb /boot/kernel/kernel /dev/mem {find procedd descriptors of both processes.. (the one you have with the file you want, and the 'cp' above. follow links to file descriptors swap vnode pointers in the descriptors you want. set a breakpoint at 'close' in the 'cp' continue the 'cp' swap pointers back within kernel. continue cp so that it exits. go read contents of file > > -mi > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Sat Nov 28 10:01:54 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED69AA3AF46 for ; Sat, 28 Nov 2015 10:01:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C651E1C97 for ; Sat, 28 Nov 2015 10:01:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-88.lns20.per1.internode.on.net [121.45.225.88]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tASA1Ye8084501 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 28 Nov 2015 02:01:37 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Recovering an unlink-ed, but still opened file To: "Mikhail T." , "alex.burlyga.ietf alex.burlyga.ietf" References: <5658E498.9070700@aldan.algebra.com> <56591999.1040001@aldan.algebra.com> <56593251.90705@aldan.algebra.com> Cc: freebsd-fs From: Julian Elischer Message-ID: <56597B78.6060203@freebsd.org> Date: Sat, 28 Nov 2015 18:01:28 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56593251.90705@aldan.algebra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 10:01:55 -0000 On 28/11/2015 12:49 PM, Mikhail T. wrote: > On 27.11.2015 22:30, alex.burlyga.ietf alex.burlyga.ietf wrote: >> Is the file on NFS mount by any chance? > I don't have an ongoing problem -- I just want to investigate and, if > sufficiently easy, implement a solution... are you allowed to reboot? fsdb may be your answer to relink it and then reboot, causing fsck to correct the linkage counts. > From owner-freebsd-fs@freebsd.org Sat Nov 28 13:30:03 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7082A3BB97 for ; Sat, 28 Nov 2015 13:30:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9142A1A76 for ; Sat, 28 Nov 2015 13:30:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:DunM5BFziuQyy79EVdNF8J1GYnF86YWxBRYc798ds5kLTJ75oMqwAkXT6L1XgUPTWs2DsrQf27eQ4/2rAzNIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niqbiptaJPE1hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv+YJa6jxfrw5QLpEF3xmdjltvIy4/SXEGCWV63Y2aUlevCEAVwbf4RzwRZu0vDDSuPBw1SOBMYvxV79iChq46KI+ch7ji28iPjU69GzSwphqiatQoxasojRixIHJbYWNNLx1d/WOLpshWWNdU5MJBGR6CYSmYt5KVrJZMA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DNAQD+qllW/61jaINehQOvLo5rAQ2BZoYPgWEUAQEBAQEBAQGBCYItgg4jBGQBIgINGQJbBIhBnDmPcI9EDCGBAYVTiUKDMYFEBY0idog/qhcCHwEBQoIQAR2BdCCEXEKBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,356,1444708800"; d="scan'208";a="254602129" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 28 Nov 2015 08:29:55 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E063F15F5E3 for ; Sat, 28 Nov 2015 08:29:55 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id D9HcOlyvRxLN for ; Sat, 28 Nov 2015 08:29:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 80F2115F5ED for ; Sat, 28 Nov 2015 08:29:55 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dirk-PPcPc8m for ; Sat, 28 Nov 2015 08:29:55 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5D14A15F5E3 for ; Sat, 28 Nov 2015 08:29:55 -0500 (EST) Date: Sat, 28 Nov 2015 08:29:55 -0500 (EST) From: Rick Macklem To: FreeBSD FS Message-ID: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> Subject: should mutexes be uniquely named? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: should mutexes be uniquely named? Thread-Index: YHpHNcYauUF2pc+LMGoIiRXKLcF0zw== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 13:30:03 -0000 Hi, I think the patches I posted last week that add "-manage-gids" are about ready for a commit to head. However, there is one place in the code where I'm not sure which is better to do: --> The code replaces a single mutex with one for each hash list head (table entry). I currently use MTX_DUPOK and call them all the same thing. or I could add a "lockname" field to the hash table enty structure and give each one a unique name (similar to what Garrett Wollman did in the kernel rpc). The only downside to this is 16bytes of storage for each hash table entry. (Admittedly, I don't think many sites would need to set the hash table size greater than a few thousand, so this isn't a lot of malloc()'d memory.) So, what do you think. Should I add the code to make the mutex names unique? Thanks in advance for any comments, rick ps: The coding change is trivial. It just involves using more malloc()'d memory. From owner-freebsd-fs@freebsd.org Sat Nov 28 14:26:10 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89802A3B577 for ; Sat, 28 Nov 2015 14:26:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 060111F4B for ; Sat, 28 Nov 2015 14:26:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tASEQ4tl047822 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 28 Nov 2015 16:26:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tASEQ4tl047822 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tASEQ4ja047821; Sat, 28 Nov 2015 16:26:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Nov 2015 16:26:04 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD FS Subject: Re: should mutexes be uniquely named? Message-ID: <20151128142604.GW3448@kib.kiev.ua> References: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 14:26:10 -0000 On Sat, Nov 28, 2015 at 08:29:55AM -0500, Rick Macklem wrote: > Hi, > > I think the patches I posted last week that add "-manage-gids" are about > ready for a commit to head. > > However, there is one place in the code where I'm not sure which is better > to do: > --> The code replaces a single mutex with one for each hash list head (table > entry). > I currently use MTX_DUPOK and call them all the same thing. > or > I could add a "lockname" field to the hash table enty structure and give > each one a unique name (similar to what Garrett Wollman did in the kernel rpc). > The only downside to this is 16bytes of storage for each hash table entry. > (Admittedly, I don't think many sites would need to set the hash table size > greater than a few thousand, so this isn't a lot of malloc()'d memory.) Question is, why do you need to acquire two mutexes simultaneously ? If mutexes protect the hash list rooted in head, then this is somewhat unusual. Downside is not only the name, but also a witness overhead in the non-production kernels. > > So, what do you think. Should I add the code to make the mutex names unique? > > Thanks in advance for any comments, rick > ps: The coding change is trivial. It just involves using more malloc()'d memory. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Sat Nov 28 15:23:48 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 523FAA3A216 for ; Sat, 28 Nov 2015 15:23:48 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F0771C3A; Sat, 28 Nov 2015 15:23:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from [192.168.1.8] ([100.1.236.52]) by vms173005.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0NYJ00BHJ6RGJX10@vms173005.mailsrvcs.net>; Sat, 28 Nov 2015 09:23:41 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=btqxfxui c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=qtqOOiqGOCEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=Z29a-TBkDGM1egZ8RIQA:9 a=pILNOxqGKmIA:10 a=E_JP7TCqwq8A:10 a=6I5d2MoRAAAA:8 a=AE_zWaUsDz9FSKkf5Z0A:9 a=HDl3vuLClUmWSPM6:21 a=_W_S_7VecoQA:10 Subject: Re: Recovering an unlink-ed, but still opened file To: Julian Elischer , "alex.burlyga.ietf alex.burlyga.ietf" References: <5658E498.9070700@aldan.algebra.com> <56591999.1040001@aldan.algebra.com> <56593251.90705@aldan.algebra.com> <56597B78.6060203@freebsd.org> Cc: freebsd-fs From: "Mikhail T." Message-id: <5659C6FC.9080708@aldan.algebra.com> Date: Sat, 28 Nov 2015 10:23:40 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 In-reply-to: <56597B78.6060203@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 15:23:48 -0000 On 28.11.2015 05:01, Julian Elischer wrote: > are you allowed to reboot? I'd rather it was not required... > fsdb may be your answer to relink it and then reboot, causing fsck to > correct the linkage counts. Can't the linkage count be fixed by other means? Some equivalent of link(2): linkfd(pid_t pid, int fd, const char *name2); ? Yours, -mi From owner-freebsd-fs@freebsd.org Sat Nov 28 16:42:58 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5ADBA3B2CE; Sat, 28 Nov 2015 16:42:58 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E2D611FD; Sat, 28 Nov 2015 16:42:58 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) MIME-version: 1.0 Received: from [192.168.1.8] ([100.1.236.52]) by vms173003.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.34.0 64bit (built Oct 14 2014)) with ESMTPA id <0NYJ000H57MS5Q10@vms173003.mailsrvcs.net>; Sat, 28 Nov 2015 09:42:29 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=WpDWSorv c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=qtqOOiqGOCEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=weWSkvkYGQq-ntKvi4AA:9 a=QEXdDO2ut3YA:10 a=DyZeXvobOD24KcgYWNcA:9 a=G3rUhnM3Q6f7ZNui:21 a=_W_S_7VecoQA:10 To: stable@freebsd.org, freebsd-fs From: "Mikhail T." Subject: cp from NFS to ZFS hung in "fifoor" X-Enigmail-Draft-Status: N1110 Message-id: <5659CB64.5020105@aldan.algebra.com> Date: Sat, 28 Nov 2015 10:42:28 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 16:42:58 -0000 I was copying /home from an old server (narawntapu) to a new one (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags ro,intr. On narawntapu /home was simply located on an SSD, but on aldan I created a ZFS filesystem for it. The copying was started thus: root@aldan:/home (435) cp -Rpn /mnt/* . for a while this was proceeding at a decent clip with cp making newnfsreq-uests: load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S -> ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S 100% load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S -> ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S 100% ZFS on the destination compressing and writing stuff out and the traffic between the two ranging from 30 to 50Mb/s (according to systat), but then something happened and the cp-process is now hung: load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k There is nothing in the logs on the new system, but the old one has a number of entries like: Nov 28 10:28:45 narawntapu kernel: sonewconn: pcb 0xfffff80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (62 occurrences) Nov 28 10:29:45 narawntapu kernel: sonewconn: pcb 0xfffff80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (50 occurrences) Nov 28 10:30:46 narawntapu kernel: sonewconn: pcb 0xfffff80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (59 occurrences) Nov 28 10:31:46 narawntapu kernel: sonewconn: pcb 0xfffff80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (57 occurrences) Nov 28 10:32:46 narawntapu kernel: sonewconn: pcb 0xfffff80086231930: Listen queue overflow: 8 already in queue awaiting acceptance (68 occurrences) Both systems are largely idle now. I'm not in a hurry -- is anybody interested in investigating it in situ? What is "fifoor" -- does this point to a trouble in the ZFS, the NFS-client, or the NFS-server? Both systems run FreeBSD/amd64 of recent 10.x-vintage. Thanks! -mi From owner-freebsd-fs@freebsd.org Sat Nov 28 21:40:52 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 151E5A3B7C7 for ; Sat, 28 Nov 2015 21:40:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B15E51861 for ; Sat, 28 Nov 2015 21:40:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:fcauzB98R512sf9uRHKM819IXTAuvvDOBiVQ1KB92+4cTK2v8tzYMVDF4r011RmSDdidu68P0rCN+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStOU35n8jrrps7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+lh7FVheG4GcdVC08nx5PHhPC8lmuXZDqrir5vOd58CafNMzyC7szXGLxwb1sTUrSiSwEfxsw+2LTh8k42LheqRmioxF665PTb5yYMOJ+OKjUK4BJDVFdV9pcAnQSSri3aJECWq9YZb5V X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQCaHVpW/61jaINVBoQObwa+GAENgWYXCoUkSgKBXxQBAQEBAQEBAYEJgi2CBwEBAQMBAQEBIAQnIAsFCwIBCA4KAgINGQICJwEJJgIECAcEARwEiAUIDawijz0BAQEBAQEBAwEBAQEBAQEYBIEBhVOEfoQ7AQEHBoMrgUQFjSJ2iD+FKoUin0sCHwEBQoIQAR2BdCA0B4QhCBcjgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,357,1444708800"; d="scan'208";a="253175148" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Nov 2015 16:40:44 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BDF4E15F5E4; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3K7m1gAA5kfi; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2D6F615F5E9; Sat, 28 Nov 2015 16:40:44 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6yyoidjEOSo3; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 119EC15F5E4; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Date: Sat, 28 Nov 2015 16:40:44 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Cc: FreeBSD FS Message-ID: <1688684587.110043576.1448746844037.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151128142604.GW3448@kib.kiev.ua> References: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> <20151128142604.GW3448@kib.kiev.ua> Subject: Re: should mutexes be uniquely named? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: should mutexes be uniquely named? Thread-Index: 5NkgetqFhitxRrkMxVU7V9mV7HhHbg== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 21:40:52 -0000 Kostik wrote: > On Sat, Nov 28, 2015 at 08:29:55AM -0500, Rick Macklem wrote: > > Hi, > > > > I think the patches I posted last week that add "-manage-gids" are about > > ready for a commit to head. > > > > However, there is one place in the code where I'm not sure which is better > > to do: > > --> The code replaces a single mutex with one for each hash list head > > (table > > entry). > > I currently use MTX_DUPOK and call them all the same thing. > > or > > I could add a "lockname" field to the hash table enty structure and > > give > > each one a unique name (similar to what Garrett Wollman did in the > > kernel rpc). > > The only downside to this is 16bytes of storage for each hash table > > entry. > > (Admittedly, I don't think many sites would need to set the hash table > > size > > greater than a few thousand, so this isn't a lot of malloc()'d > > memory.) > Question is, why do you need to acquire two mutexes simultaneously ? > If mutexes protect the hash list rooted in head, then this is somewhat > unusual. > There are two hash tables, one hashed on names and the other uid/gid. The entries are linked into both of these lists. I suppose that I could use a different name for the "name" hash table entries vs the "uid/gid" ones, which would avoid the duplication for the common cases. There are also a couple of infrequent cases (when new entries are being added to the cache) where, to avoid a LOR in mutex locking the above 2 hash tables, the code locks all the table entries in the one hash table before doing the other hash table. In this case, you will still end up with duplicates unless each lock is uniquely named. Maybe I should use a different name for the "user/group name" hash table than the "uid/gid" one, but still allow duplicates for the infrequent cases? Thanks for any help, rick > Downside is not only the name, but also a witness overhead in the > non-production kernels. > > > > > > So, what do you think. Should I add the code to make the mutex names > > unique? > > > > Thanks in advance for any comments, rick > > ps: The coding change is trivial. It just involves using more malloc()'d > > memory. > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Sat Nov 28 21:53:41 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32883A3B9E7; Sat, 28 Nov 2015 21:53:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B98791CA5; Sat, 28 Nov 2015 21:53:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:6CP78RUDZdHj6rul5/Rls/vLP/XV8LGtZVwlr6E/grcLSJyIuqrYZhKGt8tkgFKBZ4jH8fUM07OQ6PC9Hzxdqs/b7jgrS99laVwssY0uhQsuAcqIWwXQDcXBSGgEJvlET0Jv5HqhMEJYS47UblzWpWCuv3ZJQk2sfTR8Kum9IIPOlcP/j7n0oM2OJVUVz2PnP/tbF1afk0b4joEum4xsK6I8mFPig0BjXKBo/15uPk+ZhB3m5829r9ZJ+iVUvO89pYYbCf2pN/dwcbsNRhEnMGA85cmjiV+JBV+K5zgAUngQuhNMDwHDqhj+UZr7qCK8ve14jnq0J8rzGIo1Ujfqyq5gSxvljW9TLTsw+2LTh8lYkaVUvR+lvxw5yIeCM9LdD+Z3Yq6IJYBSfmFGRMsEDyE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQDRIVpW/61jaINdhA5vBr4bAQ2BZhcKhSRKAkyBExQBAQEBAQEBAYEJgi2CBwEBAQMBAQEBIAQnIAsFCwIBCBMFAgINGQICJwEJJgIECAcEARwEiAUIDawDjz8BAQEBAQEBAQIBAQEBAQEBARuBAYVThH6ENQYBAQWDM4FEBY4YiD+FKoUihEdJlkuDcAIfAQFChCIgNAeEIQgXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,357,1444708800"; d="scan'208";a="254652042" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 28 Nov 2015 16:53:38 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 735DD15F5E4; Sat, 28 Nov 2015 16:53:38 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jJGBskTkx1YT; Sat, 28 Nov 2015 16:53:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id ACEB615F5E9; Sat, 28 Nov 2015 16:53:37 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4MSDyysiMoVz; Sat, 28 Nov 2015 16:53:37 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8EBB615F5E4; Sat, 28 Nov 2015 16:53:37 -0500 (EST) Date: Sat, 28 Nov 2015 16:53:37 -0500 (EST) From: Rick Macklem To: "Mikhail T." Cc: stable@freebsd.org, freebsd-fs Message-ID: <1797738664.110049243.1448747617558.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <5659CB64.5020105@aldan.algebra.com> References: <5659CB64.5020105@aldan.algebra.com> Subject: Re: cp from NFS to ZFS hung in "fifoor" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: cp from NFS to ZFS hung in "fifoor" Thread-Index: 71K1Z8URtZx18dr8wVDEnFmEW0myoQ== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 21:53:41 -0000 Mikhail T. wrote: > I was copying /home from an old server (narawntapu) to a new one > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > ro,intr. On narawntapu /home was simply located on an SSD, but on aldan > I created a ZFS filesystem for it. > > The copying was started thus: > > root@aldan:/home (435) cp -Rpn /mnt/* . > > for a while this was proceeding at a decent clip with cp making > newnfsreq-uests: > > load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > -> > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > 100% > load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > -> > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > 100% > > ZFS on the destination compressing and writing stuff out and the traffic > between the two ranging from 30 to 50Mb/s (according to systat), but > then something happened and the cp-process is now hung: > > load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k > load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k > load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k > Doing `ps axHl` will show you what the ``cp`` process is stuck on (WCHAN). If it is down inside ZFS, then I suspect it is ZFS resource related. If it is stuck somewhere in NFS or the kernel RPC, then I`d suspect a net driver issue: - The number 1 issue for net drivers vs NFS is TSO, so disabling TSO is the first thing to try (if the processes aren`t stuck inside zfs). (In the machine that is sending data, since it is a transmit segment limit problem. If I understood what you were doing, that would be the NFS server, but I`d disable it on both server and client.) - If that doesn`t fix it, try rsize=32768,wsize=32768 mount options for the NFS mount. These TSO issues are slowly getting resolved, but some drivers may still be broken, especially if you aren`t running head. (For example, only a very recent em(4) driver is fixed.) You can also do things like `netstat -m` to look for mbuf cluster exhaustion and look at the stats for your net driver (usually a sysctl). Good luck with it, rick > There is nothing in the logs on the new system, but the old one has a > number of entries like: > > Nov 28 10:28:45 narawntapu kernel: sonewconn: pcb > 0xfffff80086231930: Listen queue overflow: 8 already in queue > awaiting acceptance (62 occurrences) > Nov 28 10:29:45 narawntapu kernel: sonewconn: pcb > 0xfffff80086231930: Listen queue overflow: 8 already in queue > awaiting acceptance (50 occurrences) > Nov 28 10:30:46 narawntapu kernel: sonewconn: pcb > 0xfffff80086231930: Listen queue overflow: 8 already in queue > awaiting acceptance (59 occurrences) > Nov 28 10:31:46 narawntapu kernel: sonewconn: pcb > 0xfffff80086231930: Listen queue overflow: 8 already in queue > awaiting acceptance (57 occurrences) > Nov 28 10:32:46 narawntapu kernel: sonewconn: pcb > 0xfffff80086231930: Listen queue overflow: 8 already in queue > awaiting acceptance (68 occurrences) > > Both systems are largely idle now. I'm not in a hurry -- is anybody > interested in investigating it in situ? What is "fifoor" -- does this > point to a trouble in the ZFS, the NFS-client, or the NFS-server? Both > systems run FreeBSD/amd64 of recent 10.x-vintage. > > Thanks! > > -mi > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Sat Nov 28 22:41:05 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B745A3B169; Sat, 28 Nov 2015 22:41:05 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 460CC1BA3; Sat, 28 Nov 2015 22:41:05 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D2326B8059; Sat, 28 Nov 2015 23:41:01 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id BE03228494; Sat, 28 Nov 2015 23:41:01 +0100 (CET) Date: Sat, 28 Nov 2015 23:41:01 +0100 From: Jilles Tjoelker To: "Mikhail T." Cc: stable@freebsd.org, freebsd-fs Subject: Re: cp from NFS to ZFS hung in "fifoor" Message-ID: <20151128224101.GA8470@stack.nl> References: <5659CB64.5020105@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5659CB64.5020105@aldan.algebra.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 22:41:05 -0000 On Sat, Nov 28, 2015 at 10:42:28AM -0500, Mikhail T. wrote: > I was copying /home from an old server (narawntapu) to a new one > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > ro,intr. On narawntapu /home was simply located on an SSD, but on aldan > I created a ZFS filesystem for it. > The copying was started thus: > root@aldan:/home (435) cp -Rpn /mnt/* . > for a while this was proceeding at a decent clip with cp making > newnfsreq-uests: > load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > -> > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > 100% > load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > -> > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > 100% > ZFS on the destination compressing and writing stuff out and the traffic > between the two ranging from 30 to 50Mb/s (according to systat), but > then something happened and the cp-process is now hung: > load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k > load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k > load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k This normally means that the process is opening a fifo for reading and is waiting for a writer. Although cp -R will normally copy a fifo by calling mkfifo at the destination, it may open one if a regular file is replaced with a fifo between the time it reads the directory and it copies that file. This is not that unlikely if large directory trees are copied during that time. On the other hand, cp without -R/-r/-l/-s will always open a fifo. You can make cp continue by opening the fifo (which you'll need to find first, for example by checking what has been copied already) for writing, like : >/path/to/some/fifo. It will be replaced with an empty file at the destination. -- Jilles Tjoelker From owner-freebsd-fs@freebsd.org Sat Nov 28 23:11:00 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B04A5A3B6FC; Sat, 28 Nov 2015 23:11:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5409017BE; Sat, 28 Nov 2015 23:10:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:7GhgDxaV+FtbiaHoA8T7dwf/LSx+4OfEezUN459isYplN5qZpcu8bnLW6fgltlLVR4KTs6sC0LqL9fC9EjVcuN6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDvvc2OKFwU3XKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1kdVmEbiVJ0AQ/I6BL3RN+lsCr+sudm8DKGNMb1C7YwD2eM9aBuHSXpgyRPEjcy82Xaj4QklqdSqxGlqhlX3onbfYyRLPo4daqLLoBSfnZIQssED38JOYi7dYZaSrNZZes= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQBfM1pW/61jaINdhA5vBr4bAQ2BZhcKhSRKAkyBDxQBAQEBAQEBAYEJgi2CBwEBAQMBAQEBIAQnIAsFCwIBCBMFAgINGQICJwEJJgIECAcEARwEiAUIDakvj0ABAQEBAQEBAQEBAQEBAQEBAQEBGoEBhVOEfoQ7AQEFgzOBRAWOGIg/hSqFIoUQmjsCHwEBQoIRHYF0IDQHhCk6gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,358,1444708800"; d="scan'208";a="253183225" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Nov 2015 18:10:58 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C7DFB15F5E4; Sat, 28 Nov 2015 18:10:58 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Bz7UTgeI6pCk; Sat, 28 Nov 2015 18:10:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2E07715F5E9; Sat, 28 Nov 2015 18:10:58 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CpEvMSxdw0s4; Sat, 28 Nov 2015 18:10:58 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 135D015F5E4; Sat, 28 Nov 2015 18:10:58 -0500 (EST) Date: Sat, 28 Nov 2015 18:10:58 -0500 (EST) From: Rick Macklem To: Jilles Tjoelker Cc: "Mikhail T." , freebsd-fs , stable@freebsd.org Message-ID: <1399144047.110083450.1448752258051.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151128224101.GA8470@stack.nl> References: <5659CB64.5020105@aldan.algebra.com> <20151128224101.GA8470@stack.nl> Subject: Re: cp from NFS to ZFS hung in "fifoor" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: cp from NFS to ZFS hung in "fifoor" Thread-Index: HxYXiQVyopzcEgTBG1wBftCEbqqH5w== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 23:11:00 -0000 Jilles Tjoelker wrote: > On Sat, Nov 28, 2015 at 10:42:28AM -0500, Mikhail T. wrote: > > I was copying /home from an old server (narawntapu) to a new one > > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > > ro,intr. On narawntapu /home was simply located on an SSD, but on aldan > > I created a ZFS filesystem for it. > > > The copying was started thus: > > > root@aldan:/home (435) cp -Rpn /mnt/* . > > > for a while this was proceeding at a decent clip with cp making > > newnfsreq-uests: > > > load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k > > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > > -> > > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > > 100% > > load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k > > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > > -> > > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > > 100% > > > ZFS on the destination compressing and writing stuff out and the traffic > > between the two ranging from 30 to 50Mb/s (according to systat), but > > then something happened and the cp-process is now hung: > > > load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k > > load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k > > load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k > > This normally means that the process is opening a fifo for reading and > is waiting for a writer. Although cp -R will normally copy a fifo by > calling mkfifo at the destination, it may open one if a regular file is > replaced with a fifo between the time it reads the directory and it > copies that file. This is not that unlikely if large directory trees are > copied during that time. > Oops, thanks. I didn't know that [fifoor] in these lines meant that was what the WCHAN is. Obviously, you should now ignore everything I said;-) rick > On the other hand, cp without -R/-r/-l/-s will always open a fifo. > > You can make cp continue by opening the fifo (which you'll need to find > first, for example by checking what has been copied already) for > writing, like : >/path/to/some/fifo. It will be replaced with an empty > file at the destination. > > -- > Jilles Tjoelker > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >