From owner-freebsd-fs@FreeBSD.ORG Sun Sep 29 09:17:53 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C3D9741 for ; Sun, 29 Sep 2013 09:17:53 +0000 (UTC) (envelope-from 3PvBHUg0LAtU1E9J192I189DUC1GFJK5.E5K6J6I552J4.FI7@calendar-server.bounces.google.com) Received: from mail-bk0-x250.google.com (mail-bk0-x250.google.com [IPv6:2a00:1450:4008:c01::250]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80FB62D65 for ; Sun, 29 Sep 2013 09:17:52 +0000 (UTC) Received: by mail-bk0-f80.google.com with SMTP id mx10so39323bkb.3 for ; Sun, 29 Sep 2013 02:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:auto-submitted:message-id:date:subject :from:to:content-type; bh=jxEtbX1JFqVmvujjdIAJmkPrwYZa6RFwiYFt4flFF1I=; b=WIDZ3YBnwFv9oGMBtH3EU5nhEKY8m6K9mz8NAxpN5rmRa4OQ2ac6AP6/9zTOhkaUCC Z15dH8EnBALyhJXXi2YblLX7DafIpsfwEdHNpsQEyQcJ3IC3n61ANoTVkKIbdejmRWLl 2RUDJ5/9BWC/d0mal0brRXdk+DDllpPDT4UDegm1IID2Ir7Qj6H/V2s3WIA2zT8IKhTF xaDwn3Rw1TwIwkXVbOuAQIOWkuRMIsjPWE5FTu8QF3rDzJlWdygub83lj+U2Sk8UtYJQ qFEcE/4ZoAraShP47DZX5aq1Cjkz11eN/aetei25td20rmd6Q6AQFfwuz6q9hC5sg2z4 AJQQ== MIME-Version: 1.0 X-Received: by 10.180.149.135 with SMTP id ua7mr5161706wib.0.1380446270381; Sun, 29 Sep 2013 02:17:50 -0700 (PDT) Sender: Google Calendar Auto-Submitted: auto-generated Message-ID: <001a11c37dc695537c04e782317a@google.com> Date: Sun, 29 Sep 2013 09:17:50 +0000 Subject: Invitation: Hello My Dearest, Please i need your help @ Sun Sep 29, 2013 5:30am - 6:30am (anisaibrahim3@laposte.net) From: "anisaibrahim3@laposte.net" To: "fs@freebsd.org" Content-Type: multipart/mixed; boundary=001a11c37dc695537404e7823179 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "anisaibrahim3@laposte.net" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 09:17:53 -0000 --001a11c37dc695537404e7823179 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBI ZWxsbyBNeSBEZWFyZXN0LCBQbGVhc2UgaSBuZWVkIHlvdXIgaGVscA0KDQpIZWxsbyBNeSBEZWFy ZXN0LCBQbGVhc2UgaSBuZWVkIHlvdXIgaGVscA0KDQoNClBsZWFzZSBwZXJtaXQgbWUgdG8gaW50 cm9kdWNlIG15c2VsZiwgaSBhbSBNaXNzIEFuaXNhIElicmFoaW0gQ291bGliYWx5IDIzICANCnll YXJzIG9sZCBmZW1hbGUgZnJvbSB0aGUgUmVwdWJsaWMgb2YgSXZvcnkgQ29hc3QsIFdlc3QgQWZy aWNhLCBJJ20gdGhlICANCkRhdWdodGVyIG9mIExhdGUgQ2hpZWYgU2d0LiBJYnJhaGltIENvdWxp YmFseSAoYS5rLmEgR2VuZXJhbCBJQiApLiBNeSBsYXRlICANCkZhdGhlciB3YXMgYSB3ZWxsIGtu b3duIEl2b3J5IENvYXN0IG1pbGl0YXJ5IGxlYWRlci4gSGUgZGllZCBvbiBUaHVyc2RheSAyOCAg DQpBcHJpbCAyMDExIGZvbGxvd2luZyBhIGZpZ2h0IHdpdGggdGhlIFJlcHVibGljYW4gRm9yY2Vz IG9mIEl2b3J5IENvYXN0ICANCihGUkNJKS4NCg0KDQpZb3UgY2FuIHJlYWQgbW9yZSBhYm91dCBt eSBmYXRoZXIgaW4gdGhlIGxpbmsgYmVsb3c6DQoNCg0KaHR0cDovL3d3dy5ndWFyZGlhbi5jby51 ay93b3JsZC8yMDExL2Fwci8yOC9pdm9yeS1jb2FzdC1yZW5lZ2FkZS13YXJsb3JkLWlicmFoaW0t Y291bGliYWx5DQoNCg0KSSBhbSBjb25zdHJhaW5lZCB0byBjb250YWN0IHlvdSBiZWNhdXNlIG9m IHRoZSBtYWx0cmVhdG1lbnQgd2hpY2ggaSBhbSAgDQpyZWNlaXZpbmcgZnJvbSBteSBzdGVwIG1v dGhlci4gU2hlIHBsYW5uZWQgdG8gdGFrZSBhd2F5IGFsbCBteSBsYXRlICANCmZhdGhlcidzIHRy ZWFzdXJ5IGFuZCBwcm9wZXJ0aWVzIGZyb20gbWUgc2luY2UgdGhlIHVuZXhwZWN0ZWQgZGVhdGgg b2YgbXkgIA0KYmVsb3ZlZCBGYXRoZXIgYmVjYXVzZSBteSBtb3RoZXIgZGllZCBkdXJpbmcgY2hp bGQgYmlydGggYW5kIGkgd2FzIGxlZnQgIA0KYWxvbmUgd2l0aCBteSBzdGVwIG1vdGhlciB0byB0 YWtlIGNhcmUgb2YgbWUuIE1lYW53aGlsZSBpIHdhbnRlZCB0byB0cmF2ZWwgIA0KdG8gRXVyb3Bl LCBidXQgc2hlIGhpZGUgYXdheSBteSB0cmF2ZWxpbmcgZG9jdW1lbnRzLiBMdWNraWx5IHNoZSBk aWQgbm90ICANCmRpc2NvdmVyIHdoZXJlIGkga2VwdCBteSBmYXRoZXIncyBGaWxlIHdoaWNoIGNv bnRhaW5lZCBpbXBvcnRhbnQgZG9jdW1lbnRzICANCmxpa2UgdGhlIHdpbGwgYW5kIGRlcG9zaXQg Y2VydGlmaWNhdGUgb2YgbXkgRmF0aGVyJ3MgZnVuZCB3aGljaCBiZWFycyBteSAgDQpuYW1lIGFz IHRoZSBuZXh0IG9mIGtpbiB0byBpbmhlcml0IHRoZSBtb25leSBpbiBoaXMgYmFuayBhY2NvdW50 LiBOb3cgSSBhbSAgDQpwcmVzZW50bHkgc3RheWluZyBpbiB0aGUgUmVmdWdlZSBNaXNzaW9uIENh bXAgaW4gQnVya2luYSBGYXNvLiBJIGFtIHNlZWtpbmcgIA0KZm9yIGxvbmcgdGVybSByZWxhdGlv bnNoaXAgYW5kIGludmVzdG1lbnQgYXNzaXN0YW5jZS4gTXkgZmF0aGVyIG9mIGJsZXNzZWQgIA0K bWVtb3J5IGRlcG9zaXRlZCB0aGUgc3VtIG9mIFVTJCAxMS41IE1pbGxpb24gaW4gQmFuayBPZiBB ZnJpY2EgaGVyZSBpbiAgDQpCdXJraW5hIEZhc28gd2l0aCBteSBuYW1lIGFzIHRoZSBuZXh0IG9m IGtpbi4NCg0KDQpJIGhhdmUgY29udGFjdGVkIHRoZSBCYW5rIHRvIGNsZWFyIHRoZSBkZXBvc2l0 IGJ1dCB0aGUgQnJhbmNoIE1hbmFnZXIgdG9sZCAgDQptZSB0aGF0IG15IGxhdGUgZmF0aGVyIHBs YWNlIGFuIGluc3RydWN0aW9uIG9uIHRoZSBkZXBvc2l0ZWQgZnVuZCB0aGF0IGkgIA0KbXVzdCBw cmVzZW50IGEgZm9yZWlnbiB0cnVzdGVlIHdobyB3aWxsIGhlbHAgbWUgaW4gaW52ZXN0bWVudCBv ZiB0aGUgZnVuZC4NCg0KDQpIb3dldmVyLCB0aGUgbWFuYWdlciBhZHZpc2VkIG1lIHRvIHByb3Zp ZGUgYSB0cnVzdGVlIHdobyB3aWxsIHN0YW5kIG9uIG15ICANCmJlaGFsZiBmb3IgdGhlIHRyYW5z ZmVyIG9mIHRoZSBmdW5kLiBpIHdhbnRlZCB0byBpbmZvcm0gbXkgc3RlcG1vdGhlciBhYm91dCAg DQp0aGlzIGRlcG9zaXQgYnV0IGkgYW0gYWZyYWlkIHRoYXQgc2hlIHdpbGwgbm90IG9mZmVyIG1l IGFueXRoaW5nIGFmdGVyIHRoZSAgDQpyZWxlYXNlIG9mIHRoZSBtb25leSBiZWNhdXNlIHNoZSB0 aHJlYXRlbiB0byBraWxsIG1lLg0KDQoNClRoZXJlZm9yZSwgaSBkZWNpZGUgdG8gc2VlayBmb3Ig eW91ciBoZWxwIGluIHRyYW5zZmVycmluZyB0aGUgbW9uZXkgaW50byAgDQp5b3VyIGJhbmsgYWNj b3VudCB3aGlsZSBpIHdpbGwgcmVsb2NhdGUgdG8geW91ciBjb3VudHJ5IGFuZCBzZXR0bGUgZG93 biAgDQp3aXRoIHlvdS4gQXMgeW91IGluZGljYXRlIHlvdXIgaW50ZXJlc3QgdG8gaGVscCBtZSwg aSB3aWxsIGdpdmUgeW91IHRoZSAgDQphY2NvdW50IG51bWJlciBhbmQgdGhlIGNvbnRhY3Qgb2Yg dGhlIGJhbmsgd2hlcmUgbXkgbGF0ZSBiZWxvdmVkIGZhdGhlciAgDQpkZXBvc2l0ZWQgdGhlIG1v bmV5IHdpdGggbXkgbmFtZSBhcyB0aGUgbmV4dCBvZiBraW4uIEl0IGlzIG15IGludGVudGlvbiB0 byAgDQpjb21wZW5zYXRlIHlvdSB3aXRoIDMwJSBvdXQgb2YgdGhlIHRvdGFsIG1vbmV5IGFmdGVy IHRoZSB0cmFuc2ZlciBmb3IgeW91ciAgDQphc3Npc3RhbmNlIGFuZCB0aGUgYmFsYW5jZSBzaGFs bCBiZSBteSBpbnZlc3RtZW50IGluIGFueSBwcm9maXRhYmxlIHZlbnR1cmUgIA0Kd2hpY2ggeW91 IHdpbGwgcmVjb21tZW5kIHRvIG1lIGFzIGkgaGF2ZSBubyBpZGVhIGFib3V0IGZvcmVpZ24gaW52 ZXN0bWVudC4gIA0KUGxlYXNlIGFsbCBteSBjb21tdW5pY2F0aW9ucyB3aXRoIHlvdSAgc2hvdWxk IGJlIHRocm91Z2ggZW1haWwgYWRkcmVzcyBmb3IgIA0KY29uZmlkZW50aWFsIHB1cnBvc2VzLg0K DQoNCg0KDQoNClRoYW5rcyBpbiBhbnRpY2lwYXRpb24gb2YgeW91ciBwb3NpdGl2ZSByZXNwb25z ZS4NCg0KDQpZb3VycyBzaW5jZXJlbHkNCk1pc3MgQW5pc2EgSWJyYWhpbSBDb3VsaWJhbHkuDQpX aGVuOiBTdW4gU2VwIDI5LCAyMDEzIDU6MzBhbSCWIDY6MzBhbSBFYXN0ZXJuIFRpbWUNCkNhbGVu ZGFyOiBhbmlzYWlicmFoaW0zQGxhcG9zdGUubmV0DQpXaG86DQogICAgIChHdWVzdCBsaXN0IGhh cyBiZWVuIGhpZGRlbiBhdCBvcmdhbml6ZXIncyByZXF1ZXN0KQ0KDQpFdmVudCBkZXRhaWxzOiAg DQpodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1j WEJoYXprd2Jqa3hhV2cwWkdnd2JqVjJOV0ZwY21kbGEyc2dabk5BWm5KbFpXSnpaQzV2Y21jJnRv az1NalVqWVc1cGMyRnBZbkpoYUdsdE0wQnNZWEJ2YzNSbExtNWxkRE13TkRBeFptUTRObVpoWWpV MFl6RXhNMlk1WTJWak9EVTBaVFJqWkdWaU1UZGxNekptT0RVJmN0ej1BbWVyaWNhL05ld19Zb3Jr JmhsPWVuDQoNCkludml0YXRpb24gZnJvbSBHb29nbGUgQ2FsZW5kYXI6IGh0dHBzOi8vd3d3Lmdv b2dsZS5jb20vY2FsZW5kYXIvDQoNCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgY291cnRlc3kgZW1h aWwgYXQgdGhlIGFjY291bnQgZnNAZnJlZWJzZC5vcmcgYmVjYXVzZSAgDQp5b3UgYXJlIGFuIGF0 dGVuZGVlIG9mIHRoaXMgZXZlbnQuDQoNClRvIHN0b3AgcmVjZWl2aW5nIGZ1dHVyZSBub3RpZmlj YXRpb25zIGZvciB0aGlzIGV2ZW50LCBkZWNsaW5lIHRoaXMgZXZlbnQuICANCkFsdGVybmF0aXZl bHkgeW91IGNhbiBzaWduIHVwIGZvciBhIEdvb2dsZSBhY2NvdW50IGF0ICANCmh0dHBzOi8vd3d3 Lmdvb2dsZS5jb20vY2FsZW5kYXIvIGFuZCBjb250cm9sIHlvdXIgbm90aWZpY2F0aW9uIHNldHRp bmdzIGZvciAgDQp5b3VyIGVudGlyZSBjYWxlbmRhci4NCg== --001a11c37dc695537404e7823179-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 29 21:16:20 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61E488F4 for ; Sun, 29 Sep 2013 21:16:20 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6F5428F9 for ; Sun, 29 Sep 2013 21:16:19 +0000 (UTC) Received: from [10.0.0.10] ([10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id r8TLGCUT063397 for ; Mon, 30 Sep 2013 00:16:12 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <52489897.1070306@ukr.net> Date: Mon, 30 Sep 2013 00:16:07 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: fs@freebsd.org Subject: Zpool (2-mirror) with mixed ashift Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [89.209.81.54]); Mon, 30 Sep 2013 00:16:12 +0300 (EEST) X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, FREEMAIL_FROM, T_FILL_THIS_FORM_SHORT, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 21:16:20 -0000 Hi all! I have the misfortune. :( I had a system with two HDD with a cluster size of 512b. Due to lack of space in the system, it was decided to put the 4 3TB HDD in 2-mirror zfs pool I used the instructions from the forum: http://forums.freebsd.org/showthread.php?t=37819 But with the addition of the second mirror and the second mirror turned out to ashift = 9. Notice now zfs pool filled with more than 50% How can I safely do a second mirror in the pool ashift=12 without losing data? How to continue to create 2-mirror zfs pool for 4k HDD? Thank you. A little more than further information: FreeBSD 9.1-STABLE #0 r251351M: Sat Jun 15 01:22:15 EEST 2013 amd64 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 5,44T 3,23T 2,21T 59% 1.16x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 3,41T 2,12T 186K /tank # zpool status pool: tank state: ONLINE scan: resilvered 2,38T in 8h46m with 0 errors on Mon Jun 17 02:32:29 2013 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 errors: No known data errors # zdb tank: version: 5000 name: 'tank' state: 0 txg: 47135 pool_guid: 13092523331396101530 hostid: 143250101 hostname: 'mary-teresa.XXXXX.ua' vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 13092523331396101530 children[0]: type: 'mirror' id: 0 guid: 3335739818 whole_disk: 0 metaslab_array: 34 metaslab_shift: 34 ashift: 12 asize: 3000586993664 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 11030443378289800725 path: '/dev/gpt/disk3' phys_path: '/dev/gpt/disk3' whole_disk: 1 DTL: 39 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 11332687226484843334 path: '/dev/gpt/disk4' phys_path: '/dev/gpt/disk4' whole_disk: 1 DTL: 24 create_txg: 4 resilvering: 1 children[1]: type: 'mirror' id: 1 guid: 17121080319583017092 metaslab_array: 38 metaslab_shift: 34 ashift: 9 asize: 3000586993664 is_log: 0 create_txg: 47133 children[0]: type: 'disk' id: 0 guid: 4425616934581567964 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 1 create_txg: 47133 children[1]: type: 'disk' id: 1 guid: 5113772130885677504 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 1 create_txg: 47133 features_for_read: -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-fs@FreeBSD.ORG Sun Sep 29 21:40:29 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0E5026B for ; Sun, 29 Sep 2013 21:40:29 +0000 (UTC) (envelope-from prvs=1984e6c06e=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EE382A12 for ; Sun, 29 Sep 2013 21:40:29 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006171425.msg for ; Sun, 29 Sep 2013 22:40:20 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 29 Sep 2013 22:40:20 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1984e6c06e=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Vladislav V. Prodan" , References: <52489897.1070306@ukr.net> Subject: Re: Zpool (2-mirror) with mixed ashift Date: Sun, 29 Sep 2013 22:40:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 21:40:30 -0000 ashift is only automatically calculated in HEAD or 10 (currently in alpha) If you're running something older then use gnop to configure 4k sectors and then creation your pool on .nop device. Regards Steve ----- Original Message ----- From: "Vladislav V. Prodan" To: Sent: Sunday, September 29, 2013 10:16 PM Subject: Zpool (2-mirror) with mixed ashift > Hi all! > > I have the misfortune. :( > I had a system with two HDD with a cluster size of 512b. > Due to lack of space in the system, it was decided to put the 4 3TB HDD > in 2-mirror zfs pool > I used the instructions from the forum: > http://forums.freebsd.org/showthread.php?t=37819 > But with the addition of the second mirror and the second mirror turned > out to ashift = 9. > Notice now zfs pool filled with more than 50% > How can I safely do a second mirror in the pool ashift=12 without losing > data? > How to continue to create 2-mirror zfs pool for 4k HDD? > > Thank you. > A little more than further information: > > FreeBSD 9.1-STABLE #0 r251351M: Sat Jun 15 01:22:15 EEST 2013 amd64 > > # zpool list tank > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > tank 5,44T 3,23T 2,21T 59% 1.16x ONLINE - > > # zfs list tank > NAME USED AVAIL REFER MOUNTPOINT > tank 3,41T 2,12T 186K /tank > > # zpool status > pool: tank > state: ONLINE > scan: resilvered 2,38T in 8h46m with 0 errors on Mon Jun 17 02:32:29 2013 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk3 ONLINE 0 0 0 > gpt/disk4 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > > errors: No known data errors > > > # zdb > tank: > version: 5000 > name: 'tank' > state: 0 > txg: 47135 > pool_guid: 13092523331396101530 > hostid: 143250101 > hostname: 'mary-teresa.XXXXX.ua' > vdev_children: 2 > vdev_tree: > type: 'root' > id: 0 > guid: 13092523331396101530 > children[0]: > type: 'mirror' > id: 0 > guid: 3335739818 > whole_disk: 0 > metaslab_array: 34 > metaslab_shift: 34 > ashift: 12 > asize: 3000586993664 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 11030443378289800725 > path: '/dev/gpt/disk3' > phys_path: '/dev/gpt/disk3' > whole_disk: 1 > DTL: 39 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 11332687226484843334 > path: '/dev/gpt/disk4' > phys_path: '/dev/gpt/disk4' > whole_disk: 1 > DTL: 24 > create_txg: 4 > resilvering: 1 > children[1]: > type: 'mirror' > id: 1 > guid: 17121080319583017092 > metaslab_array: 38 > metaslab_shift: 34 > ashift: 9 > asize: 3000586993664 > is_log: 0 > create_txg: 47133 > children[0]: > type: 'disk' > id: 0 > guid: 4425616934581567964 > path: '/dev/gpt/disk0' > phys_path: '/dev/gpt/disk0' > whole_disk: 1 > create_txg: 47133 > children[1]: > type: 'disk' > id: 1 > guid: 5113772130885677504 > path: '/dev/gpt/disk1' > phys_path: '/dev/gpt/disk1' > whole_disk: 1 > create_txg: 47133 > features_for_read: > > > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 30 09:16:43 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 03784C3C for ; Mon, 30 Sep 2013 09:16:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id BA9CE25C0 for ; Mon, 30 Sep 2013 09:16:42 +0000 (UTC) Received: from [172.16.1.206] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 26C8F9DC513; Mon, 30 Sep 2013 11:07:38 +0200 (CEST) Subject: Re: zfs: the exponential file system from hell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <52457A32.2090105@fsn.hu> Date: Mon, 30 Sep 2013 11:07:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> References: <52457A32.2090105@fsn.hu> To: Attila Nagy X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 09:16:43 -0000 On Sep 27, 2013, at 2:29 PM, Attila Nagy wrote: > Hi, >=20 > Did anyone try to fill a zpool with multiple zfs in it and graph the = space accounted by df and zpool list? > If not, here it is: > = https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#59282714= 43977601554 There is a fundamental problem with "df" and ZFS. df is based on the = assumption that each file system has=20 a fixed maximum size (generally the size of the disk partition on which = it resides). ZFS is really different, though. Unless you assign them fixed sizes, it = works much like a virtual memory system. There is a large pool shared by all the datasets, and *any* of them can grow = to the maximum pool size, that's the data "df " shows. With virtual storage allocation, compression and deduplication you can = no longer make the old assumptions you made in the old days.=20 Anyway, in a system with variable datasets "df" is actually meaningless = and you should rely on "zpool list", which gives you the real size, allocated space, free space, etc. % zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 1.59T 500G 1.11T 30% 1.00x ONLINE - %=20 Times change, embracing the satanic filesystem implies that you have to = change your mindset (and your scripts!) :) Borja. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 30 11:06:43 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5AABDC7 for ; Mon, 30 Sep 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D20DD2BE9 for ; Mon, 30 Sep 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8UB6h6q053445 for ; Mon, 30 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8UB6h4W053443 for freebsd-fs@FreeBSD.org; Mon, 30 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Sep 2013 11:06:43 GMT Message-Id: <201309301106.r8UB6h4W053443@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 334 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 30 13:28:43 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 44C1769A for ; Mon, 30 Sep 2013 13:28:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0892C25D0 for ; Mon, 30 Sep 2013 13:28:43 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 725D3153435; Mon, 30 Sep 2013 15:28:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkL_f2V2i7AW; Mon, 30 Sep 2013 15:28:32 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:7532:e977:1083:166f] (unknown [IPv6:2001:4cb8:3:1:7532:e977:1083:166f]) by smtp.digiware.nl (Postfix) with ESMTP id F018F153433; Mon, 30 Sep 2013 15:28:31 +0200 (CEST) Message-ID: <52497C7F.4030702@digiware.nl> Date: Mon, 30 Sep 2013 15:28:31 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Borja Marcos Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> In-Reply-To: <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 13:28:43 -0000 On 2013-09-30 11:07, Borja Marcos wrote: [About ZFS and df not being friends] > Times change, embracing the satanic filesystem implies that you have to change your mindset (and your scripts!) :) Let alone what you need to change when using net-snmp and cacti, if you want to make some easy and obvious graphs.. Still looking for time to figure that out. --WjW From owner-freebsd-fs@FreeBSD.ORG Mon Sep 30 20:48:12 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E03E854C for ; Mon, 30 Sep 2013 20:48:12 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 616EB242E for ; Mon, 30 Sep 2013 20:48:11 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id r8UKm2Jq055452 for ; Mon, 30 Sep 2013 23:48:02 +0300 (EEST) Message-ID: <20130930234802.55451@relay.ibs.dn.ua> Date: Mon, 30 Sep 2013 23:48:02 +0300 From: "Zeus Panchenko" To: cc: Subject: ZFS Permanent errors on fresh installation on VMware ESX Organization: I.B.S. LLC X-Mailer: MH-E 8.3.1; GNU Mailutils 2.99.98; GNU Emacs 24.0.93 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 20:48:12 -0000 hi, may somebody advise, please? FreeBSD 9.2R just installed on VM under VMware ESX 4.1.2 CPU: 2x1.5GHz MEM: 1G HDD: 16Gb > uname -a FreeBSD 9.2-RELEASE #0 r255898: amd64 vfs.zfs.arc_max=536870912 open-vm-tools-nox11-425873_3,1 port is intsalled after portinstall of several ports, reboot and scrub, status shows this: pool: zroot state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 0h2m with 2 errors on Mon Sep 30 20:00:01 2013 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 2 gpt/disk0 ONLINE 0 0 4 errors: Permanent errors have been detected in the following files: /usr/ports/distfiles/gnome2/glib-2.36.3.tar.xz /usr/src/contrib/gcc/ChangeLog-2005 how is it possible on just installed system? what can be the cause? other OSes (MSWin, Centos,Debian) works fine, but FreeBSD on ZFS (and even UFS) exposes disk damages :( is there some "secret" knowledge to manage fs on VM installations? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Mon Sep 30 21:16:49 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7CE2607 for ; Mon, 30 Sep 2013 21:16:49 +0000 (UTC) (envelope-from prvs=198501a29f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 776312633 for ; Mon, 30 Sep 2013 21:16:49 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006213507.msg for ; Mon, 30 Sep 2013 22:16:46 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 30 Sep 2013 22:16:46 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=198501a29f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Zeus Panchenko" , References: <20130930234802.55451@relay.ibs.dn.ua> Subject: Re: ZFS Permanent errors on fresh installation on VMware ESX Date: Mon, 30 Sep 2013 22:16:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:16:50 -0000 Whats the backing disk? I'm wondering if its LSI Megraid? If so ensure you're running the latest FW as older FW have known issue with TRIM requests, as in they delete the wrong data from the disk. This will only be relavent if the disk is reporting TRIM support through VMware. One thing you might want to try is setting the following in /boot/loader.conf: vfs.zfs.trim.enabled="0" Regards Steve ----- Original Message ----- From: "Zeus Panchenko" To: Sent: Monday, September 30, 2013 9:48 PM Subject: ZFS Permanent errors on fresh installation on VMware ESX > hi, > > may somebody advise, please? > > FreeBSD 9.2R just installed on VM under VMware ESX 4.1.2 > CPU: 2x1.5GHz > MEM: 1G > HDD: 16Gb > >> uname -a > FreeBSD 9.2-RELEASE #0 r255898: amd64 > > vfs.zfs.arc_max=536870912 > > open-vm-tools-nox11-425873_3,1 port is intsalled > > after portinstall of several ports, reboot and scrub, status shows this: > > pool: zroot > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: scrub repaired 0 in 0h2m with 2 errors on Mon Sep 30 20:00:01 2013 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 2 > gpt/disk0 ONLINE 0 0 4 > > errors: Permanent errors have been detected in the following files: > > /usr/ports/distfiles/gnome2/glib-2.36.3.tar.xz > /usr/src/contrib/gcc/ChangeLog-2005 > > > how is it possible on just installed system? > > what can be the cause? > > other OSes (MSWin, Centos,Debian) works fine, but FreeBSD on ZFS (and even UFS) > exposes disk damages :( > > is there some "secret" knowledge to manage fs on VM installations? > > -- > Zeus V. Panchenko jid:zeus@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 09:18:20 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A84F82E4 for ; Tue, 1 Oct 2013 09:18:20 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 677672A13 for ; Tue, 1 Oct 2013 09:18:20 +0000 (UTC) Received: from [172.16.1.206] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id C0A219DC587; Tue, 1 Oct 2013 11:18:12 +0200 (CEST) Subject: Re: zfs: the exponential file system from hell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20130930234401.GA68360@neutralgood.org> Date: Tue, 1 Oct 2013 11:18:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> To: kpneal@pobox.com X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 09:18:20 -0000 On Oct 1, 2013, at 1:44 AM, kpneal@pobox.com wrote: > On Mon, Sep 30, 2013 at 11:07:33AM +0200, Borja Marcos wrote: >> Anyway, in a system with variable datasets "df" is actually = meaningless and you should rely on "zpool list", which gives you >> the real size, allocated space, free space, etc. >>=20 >>=20 >> % zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> pool 1.59T 500G 1.11T 30% 1.00x ONLINE - >> %=20 >=20 > See that the zfs command says aurd0 has used 2.14T of space while the = zpool > command says it has used 3.21T? But aursys (the mirror) has numbers = that > roughly match. >=20 > Since 'zfs' works above the pool level it gives accurate sizes no = matter > what kind of redundancy (if any) you are using. >=20 > Bottom line: > The replacement for the 'df' command when using ZFS is 'zfs list'. Ouch, I stand corrected! Thank you :) Borja. From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 10:14:16 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9587D116 for ; Tue, 1 Oct 2013 10:14:16 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53E042DDD for ; Tue, 1 Oct 2013 10:14:16 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VQwy3-0006a3-Po for freebsd-fs@freebsd.org; Tue, 01 Oct 2013 12:14:11 +0200 Received: from jtotz2.cs.ucl.ac.uk ([128.16.6.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Oct 2013 12:14:11 +0200 Received: from johannes by jtotz2.cs.ucl.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Oct 2013 12:14:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Subject: Re: zfs: the exponential file system from hell Date: Tue, 01 Oct 2013 11:14:02 +0100 Lines: 59 Message-ID: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: jtotz2.cs.ucl.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <20130930234401.GA68360@neutralgood.org> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 10:14:16 -0000 On 01/10/2013 00:44, kpneal@pobox.com wrote: > On Mon, Sep 30, 2013 at 11:07:33AM +0200, Borja Marcos wrote: >> >> On Sep 27, 2013, at 2:29 PM, Attila Nagy wrote: >> >>> Hi, >>> >>> Did anyone try to fill a zpool with multiple zfs in it and graph the space accounted by df and zpool list? >>> If not, here it is: >>> https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 >> >> There is a fundamental problem with "df" and ZFS. df is based on the assumption that each file system has >> a fixed maximum size (generally the size of the disk partition on which it resides). > >> Anyway, in a system with variable datasets "df" is actually meaningless and you should rely on "zpool list", which gives you >> the real size, allocated space, free space, etc. >> >> >> % zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> pool 1.59T 500G 1.11T 30% 1.00x ONLINE - >> % > > Well, not quite. The 'zpool' command works at a lower level of abstraction > than the 'zfs' command. And zpool has a quirk where the amount of space > used and available is only accurate for mirrors or single disk vdevs, but > for raidz* it does not factor in space used for redundancy. (This does not > make it _wrong_, you just have to understand what it is telling you.) I'd say this is a desgin flow in zfs though. One motivation for having it was to do away with all the layering in the storage stack and have something integrated. Does somebody have a usecase where the numbers reported by zpool for (free/used) space are actually useful? > For example, I have two pools here, one of which (aursys) is a two way > mirror, and the other (aurd0) is a 6-drive raidz2. > > [kpn@aurora ~]$ zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > aurd0 4.91T 3.21T 1.70T 65% 1.00x ONLINE - > aursys 278G 84.7G 193G 30% 1.00x ONLINE - > > [kpn@aurora ~]$ zfs list -o space aurd0 aursys > NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD > aurd0 1.08T 2.14T 4.00K 59.9K 1G 2.14T > aursys 189G 85.7G 0 44.5K 1G 84.7G > > See that the zfs command says aurd0 has used 2.14T of space while the zpool > command says it has used 3.21T? But aursys (the mirror) has numbers that > roughly match. > > Since 'zfs' works above the pool level it gives accurate sizes no matter > what kind of redundancy (if any) you are using. > > Bottom line: > The replacement for the 'df' command when using ZFS is 'zfs list'. > From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 11:33:22 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 454F2237 for ; Tue, 1 Oct 2013 11:33:22 +0000 (UTC) (envelope-from info@goalresearch.com) Received: from mailout-1.websupport.sk (mailout-1.websupport.sk [37.9.172.130]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 050C122AE for ; Tue, 1 Oct 2013 11:33:21 +0000 (UTC) Received: from lb2.websupport.sk (localhost [127.0.0.1]) by smtp-cf.websupport.sk (Postfix) with ESMTP id B16851004DE8 for ; Tue, 1 Oct 2013 13:27:58 +0200 (CEST) Received: from www.my-conf.com (max.websupport.sk [195.210.29.7]) by mail1.websupport.sk (Postfix) with ESMTP for ; Tue, 1 Oct 2013 13:27:58 +0200 (CEST) Date: Tue, 1 Oct 2013 13:27:58 +0200 To: "freebsd-fs@freebsd.org" From: "The-Science.com" Subject: Call for Papers - Virtual Conferences Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-Virus-Checked: Checked by ClamAV on lb2.websupport.sk X-ESET-AntiSpam: OK;87;calc;2013-10-01 13:27:58;1310011327587296;EC84 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "The-Science.com" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:33:22 -0000 Please resend this information to your colleagues who might be interested. We are sorry if you receive this CFP more than once. -------------------------------------------- Virtual International Conferences Call For Papers The aim of the Virtual Conferences is create a space for researchers from from different scientific areas to exchange and communicate the new ideas and solutions. CURRENTLY CONFERENCES: ******************************************* HASSACC 2013 (November 18-22, 2013) Humanities Sciences at the Common Conference www.hassacc.com Registration & Submission Deadline: October 18, 2013 ******************************************* RCITD 2013 (November 18-22, 2013) International Virtual Research Conference In Technical Disciplines www.rcitd.com Registration & Submission Deadline: October 18, 2013 ******************************************* ARSA 2013 (December 2 - 6, 2013) Advanced Research in Scientific Areas www.arsa-conf.com Registration & Submission Deadline: November 4, 2013 ******************************************* QUAESTI 2013 (December 16 - 20, 2013) The 1st Virtual Multidisciplinary Conference www.quaesti.com Registration & Submission Deadline: November 18, 2013 ******************************************* We invite you to submit your research work (papers). Accepted papers will be sent for evaluation to major indexing databases as SCOPUS and GScholar. All conference participants eligible for receiving the conference materials with ISSN and ISBN, conference certificate and online entrance in to the Virtual Conference system. -------------------------------------------- CORRESPONDENCE: THOMSON Ltd. Organizing Committee Univerzitna 8498/25 010 08 Zilina Slovakia E-mail: info@the-science.com Virtual Conference portals: www.hassacc.com www.rcitd.com www.arsa-conf.com www.quaesti.com =========================== If you are interested in receiving the latest updates from us, subscribe to our newsletter below. http://www.the-science.com/subscribe/mail_freebsd-fs@freebsd.org/key_cf0466fd335b6f74c71bdb7b7f4558d1 If you are not interested in receiving the latest updates from us, unsubscribe to our newsletter below. http://www.my-conf.com/unsubscribe.php?c=DjQyWYbPMVh1N0hVRDM401qmXV4iLdz0 From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 11:35:03 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E7925470 for ; Tue, 1 Oct 2013 11:35:03 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6612222D8 for ; Tue, 1 Oct 2013 11:35:03 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id r91BYx1d024457; Tue, 1 Oct 2013 14:34:59 +0300 (EEST) Message-ID: <20131001143459.24455@relay.ibs.dn.ua> Date: Tue, 01 Oct 2013 14:34:59 +0300 From: "Zeus Panchenko" To: "Steven Hartland" Subject: Re: ZFS Permanent errors on fresh installation on VMware ESX In-reply-to: Your message of Mon, 30 Sep 2013 22:16:40 +0100 References: <20130930234802.55451@relay.ibs.dn.ua> Organization: I.B.S. LLC X-Mailer: MH-E 8.3.1; GNU Mailutils 2.99.98; GNU Emacs 24.0.93 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:35:04 -0000 Steven Hartland wrote: > Whats the backing disk? > I'm wondering if its LSI Megraid? no, it is: aacu0: mem 0xfe600000-0xfe7fffff irq 18 at device 0.0 on pci1 aacu0: Enable Raw I/O aacu0: Enable 64-bit array aacu0: Adaptec 5805Z, aac driver 2.4.1-18284 aacu0: New comm. interface enabled aacu0: [ITHREAD] > This will only be relavent if the disk is reporting TRIM support through VMware. I think it is not since disks (SAS 15K and SSD) are visible to vm by iSCSI from FreeNAS > One thing you might want to try is setting the following in /boot/loader.conf: > vfs.zfs.trim.enabled="0" thank you for it, lets see how it will behave with it -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 14:32:02 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 83D95FCF for ; Tue, 1 Oct 2013 14:32:02 +0000 (UTC) (envelope-from prvs=1986948615=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23AF92F90 for ; Tue, 1 Oct 2013 14:32:01 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006230787.msg for ; Tue, 01 Oct 2013 15:31:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 01 Oct 2013 15:31:51 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1986948615=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Zeus Panchenko" References: <20130930234802.55451@relay.ibs.dn.ua> <20131001143459.24455@relay.ibs.dn.ua> Subject: Re: ZFS Permanent errors on fresh installation on VMware ESX Date: Tue, 1 Oct 2013 15:31:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:32:02 -0000 ----- Original Message ----- From: "Zeus Panchenko" > Steven Hartland wrote: > >> Whats the backing disk? > > >> I'm wondering if its LSI Megraid? > > no, it is: > aacu0: mem 0xfe600000-0xfe7fffff irq 18 at device 0.0 on pci1 > aacu0: Enable Raw I/O > aacu0: Enable 64-bit array > aacu0: Adaptec 5805Z, aac driver 2.4.1-18284 > aacu0: New comm. interface enabled > aacu0: [ITHREAD] What do the raw disk(s) report when detected in FreeBSD? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 16:34:08 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDBB6994 for ; Tue, 1 Oct 2013 16:34:08 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C30E0281F for ; Tue, 1 Oct 2013 16:34:08 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 12B85666F4 for ; Tue, 1 Oct 2013 09:34:08 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 43796-04-5 for ; Tue, 1 Oct 2013 09:34:07 -0700 (PDT) Received: from [10.20.30.11] (63.sub-70-197-2.myvzw.com [70.197.2.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 7213B666CF for ; Tue, 1 Oct 2013 09:34:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: zfs: the exponential file system from hell From: Jordan Hubbard In-Reply-To: <20130930234401.GA68360@neutralgood.org> Date: Tue, 1 Oct 2013 09:33:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> To: freebsd-fs@FreeBSD.org X-Mailer: Apple Mail (2.1811) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:34:08 -0000 On Sep 30, 2013, at 4:44 PM, kpneal@pobox.com wrote: > Bottom line: > The replacement for the 'df' command when using ZFS is 'zfs list'. Given that we have the sources to df, I guess we should consider the = question begged: Do we want to change it to DTRT for zfs filesystems? = There's no Unix Law=99 that says "df(1) must use the output of statfs(2) = directly and can use no longer sources of information!" At the end of the day, df(1) is just a convenient status reporting tool = aimed at human consumption. It could easily reach out to "zfs list" for = the data it prints for zfs volumes if what's reported by statfs(2) just = isn't suitable. - Jordan From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 18:36:16 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B249D1C9 for ; Tue, 1 Oct 2013 18:36:16 +0000 (UTC) (envelope-from berend@pobox.com) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB8A2ED2 for ; Tue, 1 Oct 2013 18:36:15 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B8FEBEEC4; Tue, 1 Oct 2013 14:36:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=sasl; bh=saywVbdOancZLTX+Ntm8+ADjzSk=; b=peoGPuuEAprVG2lY8ktOh6T2wSDu Ozzm96V5yxIqfEVufJ04ANMJZXh1GKwo+gPHteQFeZNXNlEkHE1AL1C8Dw/E7Qqr 0T0FVjLKYw7Ko9fonqzju+FIJKg4Cdh2lgL/Dg7cub4FoOhJ3oMsVhJXZJW3BkQd 0wpTI+4KcnKLzdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=wipSx/ QXwoeH9mtK1lWXBgxPq5wiKVSFkSWwuBMDixFIkgJFZvN+HLSGZSbi/kmrhOLa4L EX5ZUpSC17COPGmOdyb+1LMl80X/c8Cx8iyKphamCX4GTnYEVZX+BwsD7SllK8gI 0Is8cCtMMhP9DwtvuGBOVt4zzrCdXPZUWWtrk= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id AF278EEC3; Tue, 1 Oct 2013 14:36:12 -0400 (EDT) Received: from bmach.nederware.nl (unknown [27.252.192.216]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id 12C1AEEC2; Tue, 1 Oct 2013 14:36:12 -0400 (EDT) Received: from quadrio.nederware.nl (quadrio.nederware.nl [192.168.33.13]) by bmach.nederware.nl (Postfix) with ESMTP id 0CE312F33D; Wed, 2 Oct 2013 07:36:11 +1300 (NZDT) Received: from quadrio.nederware.nl (quadrio.nederware.nl [127.0.0.1]) by quadrio.nederware.nl (Postfix) with ESMTP id F35924043FE8; Wed, 2 Oct 2013 07:36:10 +1300 (NZDT) Date: Wed, 02 Oct 2013 07:36:10 +1300 Message-ID: <87d2nohm91.wl%berend@pobox.com> From: Berend de Boer To: Jordan Hubbard Subject: Re: zfs: the exponential file system from hell In-Reply-To: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Xplain Technology Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Oct__2_07:36:10_2013-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 58ADB094-2AC8-11E3-B962-CE710E5B5709-48001098!a-pb-sasl-quonix.pobox.com Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:36:16 -0000 --pgp-sign-Multipart_Wed_Oct__2_07:36:10_2013-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >>>>> "Jordan" =3D=3D Jordan Hubbard writes: Jordan> Given that we have the sources to df, I guess we should Jordan> consider the question begged: Do we want to change it to Jordan> DTRT for zfs filesystems? There's no Unix Law=E2=84=A2 that sa= ys Jordan> "df(1) must use the output of statfs(2) directly and can Jordan> use no longer sources of information!" What an amount of emails to this list it would safe! --=20 In favour obviously, Berend de Boer --pgp-sign-Multipart_Wed_Oct__2_07:36:10_2013-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABCAAGBQJSSxYaAAoJEKOfeD48G3g5fOUQAKGjoblHb2tOQAxEdyX0gaI0 OEOdq3Xy7kLel0HHg5EmtAfrLChE7nK+sn/SxEqOAmNeW/Hde+LdCdM//wR8TyU3 OFLWV8Iz2XYWlscwPAJ8hZWZE83F7KvAbBWnSBTe9Z3FcYi0jZk7D4IrONkjtcTZ Z60dZFtAwCmUSvd3ba+/aPSTMr/J6oI04FBVzvcOuPn6TQS+h5Z3RueVaYLmCC6u 9zdtn0CaFLZyH9D5V76LdTmmr33GLGWSP0kL5cgZRnR4Nk4ZwWfbhO82UcnfsqMD kSGnQxJXig4Ogsy6TVsv/KDxB/JsSc+e98Xtkl52RDqY+PJIHplCxoUqUIampJ6g KkUIituwOerx4z82d/ToU0foOg84dRJPZJpqKPCgXVi7+fnbn2VhrBoMK784uZbU p9nTkA3Cp9VimHHt0Xov3l6GXNgwQ3XbX9losR7tOBLhztVPszfkuF4z4IXYTfTg Io5BbXYJTACoZjjawTsstVFkRwCutHUBNbdjfds7D0RbWZZu0/zRPYzVFWFvnXlJ YkF5o4y+BhD5nBYrc+kVF+FBUSYccgMMhkh6yD6J5l/fJif6lN1bb+24sUA8siui 7cI+ahN/p83Wf5TvY2brX/tP6UTj6XW5k39yhCyiRy3jrtseGjnIhfmpz4g7E/Ej u3Oxk3bIPjArJ8PlFm+W =gKVE -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Oct__2_07:36:10_2013-1-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 18:50:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8957A817 for ; Tue, 1 Oct 2013 18:50:17 +0000 (UTC) (envelope-from aurfalien@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 615BA2FDA for ; Tue, 1 Oct 2013 18:50:17 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so7907711pab.29 for ; Tue, 01 Oct 2013 11:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2zNDb+sAMGrnM84MRWccB4VjpoU467EQUyb9u0HOVa8=; b=BoihUcXFOUo4vimf+KRoklNx54ZTSWIY/WwfeFQz6Ct/hK/LuF+4o0IognYLsGCGKe kbCvFt0jueW8tvcuJZDcUOJqUiVHX3mm6ao9kYuOvEf5mzr3x+LbzKGPoR9fNi7yjAf5 OeJZah6wtCmRkWpazurPx1PxAwCUB3GmcHljgjVwSvVelFvgGksLeHEiDtYmLenwPqlP AY8ykUMbcmdF2vSaHQHbhEXoP3q3dlH/RX3EJRcFVeaBheSkF8OVYETe6qtnb0H4vda7 8G/0j78LQj1jgAeJIU5E+tVZZ84m75+lRkPngDIlGtVgxQ/kHxDt7ARtae5/uxiYBRE7 buSg== X-Received: by 10.67.30.100 with SMTP id kd4mr36023272pad.24.1380653417104; Tue, 01 Oct 2013 11:50:17 -0700 (PDT) Received: from briankrusicw.logan.tv ([64.17.255.138]) by mx.google.com with ESMTPSA id ta10sm9952080pab.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 11:50:15 -0700 (PDT) Subject: Re: zfs: the exponential file system from hell Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: aurfalien In-Reply-To: <87d2nohm91.wl%berend@pobox.com> Date: Tue, 1 Oct 2013 11:50:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> <87d2nohm91.wl%berend@pobox.com> To: Berend de Boer X-Mailer: Apple Mail (2.1085) Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:50:17 -0000 On Oct 1, 2013, at 11:36 AM, Berend de Boer wrote: >>>>>> "Jordan" =3D=3D Jordan Hubbard writes: >=20 > Jordan> Given that we have the sources to df, I guess we should > Jordan> consider the question begged: Do we want to change it to > Jordan> DTRT for zfs filesystems? There's no Unix Law=99 that says > Jordan> "df(1) must use the output of statfs(2) directly and can > Jordan> use no longer sources of information!" >=20 > What an amount of emails to this list it would safe! >=20 > --=20 > In favour obviously, >=20 > Berend de Boer Well, a ZFS aware df would be cool but how would NFS clients on a diff = OS handle this? I'd say leave it alone and leave it to the sys admins to write a wrapper = for clients that tosses ssh to the server and runs the appropriate zfs = tool for expected space stats. - aurf= From owner-freebsd-fs@FreeBSD.ORG Tue Oct 1 19:12:55 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C44AECE5 for ; Tue, 1 Oct 2013 19:12:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB1D92106 for ; Tue, 1 Oct 2013 19:12:55 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 502F6284C2; Tue, 1 Oct 2013 12:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1380654775; bh=Sso/TDLTW/nzAR7egTQCFB8o/b/Xd3vK7ifm8itO4ns=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=KBWMcHlynil9eCUJY9HV/zU0J8nwaqZ00136NAfTVY/R9w3cl+4UdQjKC7TcnFqI5 dYjaQNI/gxuWUxI57GMFWIWPjGTvwu+mSib0B4k05UvefyPSwb65/7PY2HzNcocci1 0CwDrTP6QgogKok6iuAzqvSdnkfRodimfXTT7790= Message-ID: <524B1EB6.2020003@delphij.net> Date: Tue, 01 Oct 2013 12:12:54 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Jordan Hubbard , freebsd-fs@FreeBSD.org Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:12:55 -0000 On 10/01/13 09:33, Jordan Hubbard wrote: > > On Sep 30, 2013, at 4:44 PM, kpneal@pobox.com wrote: > >> Bottom line: The replacement for the 'df' command when using ZFS is >> 'zfs list'. > > Given that we have the sources to df, I guess we should consider the > question begged: Do we want to change it to DTRT for zfs > filesystems? There's no Unix Law™ that says "df(1) must use the > output of statfs(2) directly and can use no longer sources of > information!" > > At the end of the day, df(1) is just a convenient status reporting > tool aimed at human consumption. It could easily reach out to "zfs > list" for the data it prints for zfs volumes if what's reported by > statfs(2) just isn't suitable. I don't think 'zfs list' reports the "right" numbers either: there is no notion of "available shared space between this, this and this file systems". The underlying problem is that it's always hard to represent mutli-dimensional value in a linear manner, to do it, we would need to create something new. I think one of a more preciese way of representing free space on ZFS would be something like this: File system Nominal Free Breakdown tank 25TB 0 + 25TB/2 tank/foo 25.001TB 1G + 25TB/2 Where, the /2 means the space is shared by two consumers. In the above example, we have a pool of 25TB free space and: tank: no reserved space tank/foo: 1G of reserved space. (Note: this is actually oversimplificating, there is refreserve and reserve that has to be handled differently) Personally I don't really like this idea as it makes it too complicated for users to understand. It would be easier to represent the situation in a chart (or a piechart), like: * - tank X - tank/foo O - tank/foo/bar _ - reserved space in tank/foo/bar ! - performance warning limit +---+-------------------+--------------+ +***|XXXXXXXXXXX[OOOO__]| !!!| +---+-------------------+--------------+ And the largest box represents the whole space for a given volume. Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 16:15:55 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 148A1D34 for ; Wed, 2 Oct 2013 16:15:55 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm8-vm9.bullet.mail.gq1.yahoo.com (nm8-vm9.bullet.mail.gq1.yahoo.com [98.136.218.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCA2A253D for ; Wed, 2 Oct 2013 16:15:54 +0000 (UTC) Received: from [98.137.12.189] by nm8.bullet.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:15:48 -0000 Received: from [98.136.164.65] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:15:48 -0000 Received: from [127.0.0.1] by smtp227.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:15:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380730548; bh=aeS3rqsVe4SLc+8Dr3eUp+oYJJHK+FWspBtBTChHM00=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=s4kcirblfZbBdJ4q05ywnV7+fTPFqUedKs99l3pbVHJwmQqWJyrbeDc1lgEIzx3hAiPpW1aeEblTueSkeOM2xO8Mr0sB6GkKs3WifIEPqNy4ULzK2oW2xzmvKOzZzxCx8UmlxjEPJRFctbBdv+HTcYCnxZQ/xyWXDn3j9Mu1fUA= X-Yahoo-Newman-Id: 190283.87177.bm@smtp227.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Fy8A8ncVM1nU3ov.KIGnRXdaAEKynEfCtPPQ05yUfNEWF1R BEgYCP4xePa22rkLgMspNqqTMxsdqQBPsQNgLtVBrMT.LLAcPN9AbXI5ZiXo PSUpfbC122.oPOsrJi0s0p01TPKuGZolLu.kDdtRrutxct_Me4VcnEA2wBui .CQbUQRjkq_rVinooTWWp89V16rjFbF0SdrjG6JrXYaEssV6_.6X_A69ABYe 8ZMqdqnTCS51K8RKgFfNkfHt5u7OttSmCFdXtAjCEacYN6eWm9kKGNQbw0.. 9X8qfuDP_q7brEFn6kWPP9Y6JdrJx0u9iApbOWB7WMHXEv7XVFdHchY9sP4j kpZ4r40.rXpHat3VMC.kvo3i1MAziawRtMJPzYAlMp0wcTzXy5_OMgfJKEgv LyPKrCBV64p2xoKs2iH_q8zUOcfoq.2PepVDo2IJ8.8jYN2mQKWqtG0hVBjl HL39WlBn5itYkudGhOR8honKNz6z8kKljQyM27jHmP5wO_yQ9U30qLMdve4Y VgsQ2Q2t552Hh8mUS_biywkriNeNUERntYTD4P8fzqrReVM0daVBXXiQTiBA 5xg-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp227.mail.gq1.yahoo.com with SMTP; 02 Oct 2013 16:15:48 +0000 UTC Subject: Endian issues, LE write to BE partitions From: Sean Bruno To: freebsd-fs@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SrhZVfgFxlg3k0ahEVKb" Date: Wed, 02 Oct 2013 09:15:46 -0700 Message-ID: <1380730546.1619.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:15:55 -0000 --=-SrhZVfgFxlg3k0ahEVKb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using makefs from an amd64 host to build a f/s in a VTOC8 partition will destroy the entire partition table. I simplified the test to simple dd to an existing partition and got the same result, exonerating mkfs I suspect a lack of endian knowledge in geom itself, not geom_part_vtoc8. =20 test case: using amd64 host (10.0 current) create monolothic image truncate -s+5G /var/tmp/myfile.img mdconfig -f /var/tmp/myfile.img build and load geom_part_vtoc8 kernel module use gpart to create VTOC8 part table add partition to part table to yeild the following: =3D> 0 10442250 md0 VTOC8 (5.0G) 0 10442250 1 freebsd-ufs (5G) =20 dd to md0a from dev zero for just a bit dd if=3D/dev/zero of=3D/dev/md0a bs=3D64k count=3D100 destroy md0 via mdconfig -d -u 0 recreate it with mdconfig -f /var/tmp/myfile.img gpart displays no partions for the image any more: gpart: No such geom: md0. bcc freebsd-geom --=-SrhZVfgFxlg3k0ahEVKb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSTEayAAoJEBkJRdwI6BaHOy8H/Aimwsjhet3TOKfv4rwRTVFo bYVoFdP8EvN9XXox6+aKxXjHrKJBhmCsCUpwWTUlrp6iNenMPTbxa+QHrgldO6wv a3gUXbU++WOc98elcFHb9fwN+Ks4lfp+ph45EFkz4w8ptmFdG5fKRZXsiNFCgzYv eerizZSK4S7FM4XtM0BH0K9ps8upLa+bQRw0sARwU8GTPB3Do+VlKWVU3f0svFPa QXpmEx1sc4SCiPZd7mO91niZ/+NMmmtGJ0k4X8LEvx1XVujxqWtlJxJ29sMEWZ5H 2GQligqDnjpmJXl4Y6tKisNFASJzMyG2TtcjiRV4AEwefgQ1UNJ/ASkZCGPTwCo= =6c4g -----END PGP SIGNATURE----- --=-SrhZVfgFxlg3k0ahEVKb-- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 16:44:15 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DB06C60; Wed, 2 Oct 2013 16:44:15 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 25AA0273D; Wed, 2 Oct 2013 16:44:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r92Gi8Ta094149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Oct 2013 09:44:08 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r92Gi8Ak094148; Wed, 2 Oct 2013 09:44:08 -0700 (PDT) (envelope-from jmg) Date: Wed, 2 Oct 2013 09:44:08 -0700 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: Endian issues, LE write to BE partitions Message-ID: <20131002164408.GB56872@funkthat.com> References: <1380730546.1619.47.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1380730546.1619.47.camel@localhost> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 02 Oct 2013 09:44:08 -0700 (PDT) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:44:15 -0000 Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:15 -0700: > Using makefs from an amd64 host to build a f/s in a VTOC8 partition will > destroy the entire partition table. I simplified the test to simple dd > to an existing partition and got the same result, exonerating mkfs > > I suspect a lack of endian knowledge in geom itself, not > geom_part_vtoc8. > > test case: > using amd64 host (10.0 current) create monolothic image > truncate -s+5G /var/tmp/myfile.img > mdconfig -f /var/tmp/myfile.img > build and load geom_part_vtoc8 kernel module > use gpart to create VTOC8 part table > add partition to part table to yeild the following: > > => 0 10442250 md0 VTOC8 (5.0G) > 0 10442250 1 freebsd-ufs (5G) This looks like a user error, or an issue that VTOC allows you to create/write to a partition that covers the label metadata... So this is most definately a VTOC8 issue... VTOC8 should at least return an error when trying to write sectors that contain it's metadata.. newfs actually skips the first few KB of the disk because bsdlabels would do the same thing... This sounds like makefs is writing to the first few KB of the disk unlike newfs which probably doesn't (because it knows it might be on a partitioned disk and could destroy the partition table)... > dd to md0a from dev zero for just a bit > dd if=/dev/zero of=/dev/md0a bs=64k count=100 > > destroy md0 via mdconfig -d -u 0 > recreate it with mdconfig -f /var/tmp/myfile.img > > gpart displays no partions for the image any more: > gpart: No such geom: md0. > > bcc freebsd-geom -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 16:56:40 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9815316D for ; Wed, 2 Oct 2013 16:56:40 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm4-vm4.bullet.mail.gq1.yahoo.com (nm4-vm4.bullet.mail.gq1.yahoo.com [98.136.218.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 680862836 for ; Wed, 2 Oct 2013 16:56:40 +0000 (UTC) Received: from [98.137.12.60] by nm4.bullet.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:56:33 -0000 Received: from [208.71.42.191] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:56:33 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 02 Oct 2013 16:56:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380732993; bh=fjSolWjN82FYuGN7sp0XFsqilsRh0adEwKcAfPWacEk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=Bx1raVTYoUluy+0Y35iha4uls3HXgBRrZxjvMZoLg+36xmGzM0c9iK2/jpt9bd9OfXzYfA/qWcBjWv1L4CH5Qy6C9sjsztl6RbDGwRHGb8LEs498DmrIFS21ihzVljVyxpvhlZ9GLHOJYRxWwBRMAEG+uMo+Z5Uk9zwI1ykB2AU= X-Yahoo-Newman-Id: 782592.9112.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YDvj1EoVM1nPm8vB_AHLa5AhkbOoJE3cB3UXj0EM7Rwx_U1 vBfqVgrbshmPen_Of6SKJ.cjniE4Rl2pF6sS0AUnBZ9CDACQZ0bK0NezdAK3 JFbFiZ6omqp7.KQsChRnPnSIqZsdk0u5rYAfp8Bw1Oz_N8c9S8ef8CyLV99t yeeYjIxAjUAA3nF54OimJygN.DkxEJBxRYY_2fzSVy0uOjYcjZo3lhRoSB9_ YM3yeCnCeM7667DT.jG1gHoCpAOl.bTGrD31pMVixjJyZNdr4Wip28XBre43 aJrrlU9O9zQv6K9QkYgvkGr48Euu_wP3KrPqCWttpsEfX6j0SBLLOIGQJe8. BYc6JMqYCIEcEg9h6a.PgXe2fzC7E87DvlIx41.XD7gsF8g5ZqF9kzT180sx 9tEv3gJhWg9ySo5hKB5_jQUZ6ibDlrnNtDfMQl8SgK_RcfNrTB6ZOR2G0YP. zLPVXsUXc.zYHI7nQawzsKU7vUBplgCb9ewPZQvATbyIPQcd.5Pm9SpUYPuK 8ftIusa6MDHh8rTKvvIk5M5UqipqyEmW_H8C56H6TrkMceihYl_QKaH7WbwR O8py1bjk- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp202.mail.gq1.yahoo.com with SMTP; 02 Oct 2013 09:56:33 -0700 PDT Subject: Re: Endian issues, LE write to BE partitions From: Sean Bruno To: John-Mark Gurney In-Reply-To: <20131002164408.GB56872@funkthat.com> References: <1380730546.1619.47.camel@localhost> <20131002164408.GB56872@funkthat.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-djOkgtXHBc5VCZFrmvcl" Date: Wed, 02 Oct 2013 09:56:32 -0700 Message-ID: <1380732992.6516.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:56:40 -0000 --=-djOkgtXHBc5VCZFrmvcl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2013-10-02 at 09:44 -0700, John-Mark Gurney wrote: > Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:15 -0700: > > Using makefs from an amd64 host to build a f/s in a VTOC8 partition wil= l > > destroy the entire partition table. I simplified the test to simple dd > > to an existing partition and got the same result, exonerating mkfs > >=20 > > I suspect a lack of endian knowledge in geom itself, not > > geom_part_vtoc8. =20 > >=20 > > test case: > > using amd64 host (10.0 current) create monolothic image > > truncate -s+5G /var/tmp/myfile.img > > mdconfig -f /var/tmp/myfile.img > > build and load geom_part_vtoc8 kernel module > > use gpart to create VTOC8 part table > > add partition to part table to yeild the following: > >=20 > > =3D> 0 10442250 md0 VTOC8 (5.0G) > > 0 10442250 1 freebsd-ufs (5G) =20 >=20 > This looks like a user error, or an issue that VTOC allows you to > create/write to a partition that covers the label metadata... So this > is most definately a VTOC8 issue... VTOC8 should at least return an > error when trying to write sectors that contain it's metadata.. >=20 Do you mean "user error" in that I personally executed a command that should not have been run or "user error" in that the geom_part_vtoc8 "user" should not allow me to dd to the partition? I suspect that on a g_write() from geom_part_vtoc8, the data is not be swapped around correctly. Should the geom_part_vtoc8 module be swapping the data in this case (writing from a LE machine to a BE f/s)? > newfs actually skips the first few KB of the disk because bsdlabels > would do the same thing... >=20 I would prefer to use newfs in this case actually, but it has no knowledge of how to write Big Endian f/s on Little Endian systems. Hence I was stuck with trying to use makefs in this case to get the f/s populated. Unless I'm mistaken, if I use newfs on this disk image from my amd64 host, it will get a little endian f/s. I'm assuming that this is part of my current problem. > This sounds like makefs is writing to the first few KB of the disk > unlike newfs which probably doesn't (because it knows it might be on > a partitioned disk and could destroy the partition table)... makefs, in this case, isn't really doing anything wrong here. Like dd, its using the target device as a destination for a file system creation. That's why I switched my test case over to dd, from makefs, for simplification of the problem. >=20 > > dd to md0a from dev zero for just a bit > > dd if=3D/dev/zero of=3D/dev/md0a bs=3D64k count=3D100 > >=20 > > destroy md0 via mdconfig -d -u 0 > > recreate it with mdconfig -f /var/tmp/myfile.img > >=20 > > gpart displays no partions for the image any more: > > gpart: No such geom: md0. > >=20 >=20 --=-djOkgtXHBc5VCZFrmvcl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSTFBAAAoJEBkJRdwI6BaHZy8H/31W9EX3qo8z8aGuGruDNFOD 7JuZPzPnHfchbih7McCJQ0+3OW09Svl2wuRUxir/G/A5ExM/2foTl0HAvkO6iky0 e/ciDzamg6lSt+oXkqmRAVyGhM17jg5KPTnpv4RA7hkDu0BRQ4nKAi6XuKk5ndsc fdGbRrLS230+6asgzRQPSCidvurBCSaYwxryY6Ck5pXmR70zvuOvl4u3Pa5RK+bN BJkIv75CJV8xneOUsYuapJz92aQ8vE0SnUOfM/YyfgyY3JumaEebNUXd9aZNPQtX prvAr1/p8oVuX+xwOF2gOYfmq73xiwBFJ+OqRb174mjwedWbzzjclr6QMrZAjfQ= =0Qk4 -----END PGP SIGNATURE----- --=-djOkgtXHBc5VCZFrmvcl-- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 16:59:59 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6CC0B255 for ; Wed, 2 Oct 2013 16:59:59 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01EB5286A for ; Wed, 2 Oct 2013 16:59:58 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b47so548751eek.3 for ; Wed, 02 Oct 2013 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iREEWdLIOz9e3IUiP5TwQTmTAXWSXngT007fQxruMeo=; b=wCrP62f/oMQcTYroROlWwSfSsvnXl8Q8TGARC3b9GwpnMIzg4UOZfpARbqhR2mafSe 6NHJjCRYp0F1pooaAiNLEg/Mo6LL5OhPm/69mwRvktaVDMqVH42EBtnZu4Iu/VfWdhKw lun0/OeYqd8j1BwlH0aqS66doeiZJJ1Pxr5I5y1JIN5QbgZSHsQ9hE+9UqbG4ecTAUm7 REWsRfaVQsy6A8XxNayxrSpa9wM6SghWYeZ8974uAkjiDNU0J1H35dTUX3qQRRLn1IuD upVk5elObOJRqbD4DsE8LEz8VQskeZGPT3ruDb02+h/Fbwpj5tzkZXHuGdzf5Oq80Ya9 iT1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myconan.net; s=myconan; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iREEWdLIOz9e3IUiP5TwQTmTAXWSXngT007fQxruMeo=; b=b8Qjlof1nMzrqCN/xkxBf4l+Z+G8CH2mdhp9QVAwAnsbqZr1w6i49fKncBSHG9ak3A x/4EXriEmZGImwVehCp89qV4xWJBY9HGnCdOPVsJFvuWqxs860KiugW2vzna0QasUZBW /lWmCL9nDFvFkt/+g+K5FnRt4+PEV+KD2+yJs= X-Received: by 10.14.198.197 with SMTP id v45mr5133359een.52.1380733197228; Wed, 02 Oct 2013 09:59:57 -0700 (PDT) MIME-Version: 1.0 Sender: edhoprima@gmail.com Received: by 10.14.80.67 with HTTP; Wed, 2 Oct 2013 09:59:17 -0700 (PDT) In-Reply-To: <524B1EB6.2020003@delphij.net> References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> <524B1EB6.2020003@delphij.net> From: Edho Arief Date: Thu, 3 Oct 2013 01:59:17 +0900 X-Google-Sender-Auth: A3SATC0P4iRvFbgIv4j8_R_JcHI Message-ID: Subject: Re: zfs: the exponential file system from hell To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:59:59 -0000 On Wed, Oct 2, 2013 at 4:12 AM, Xin Li wrote: > > I don't think 'zfs list' reports the "right" numbers either: there is no > notion of "available shared space between this, this and this file > systems". The underlying problem is that it's always hard to represent > mutli-dimensional value in a linear manner, to do it, we would need to > create something new. > Considering df output for UFS is never `size = used + avail` anyway, is there any problem with having df output for zfs to: - size: total size (zpool-wide, sans redundancy) - used: specific filesystem usage - avail: total available space ? -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:02:04 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3AE3319 for ; Wed, 2 Oct 2013 17:02:04 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (growveg-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:3d2::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE9A28BB for ; Wed, 2 Oct 2013 17:02:04 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VRPoF-0001ro-5M for freebsd-fs@freebsd.org; Wed, 02 Oct 2013 18:01:59 +0100 Date: Wed, 2 Oct 2013 18:01:59 +0100 From: John To: freebsd-fs@freebsd.org Subject: newbie zfs query - usb3 or sata? Message-ID: <20131002170159.GA6937@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:02:04 -0000 Hello freebsd-fs. I have a possible newbie question, and am not sure if this should go into -hardware: I have the situation where I need to add more hard drives but I haven't got the space in the existing box. So I have two choices - make a DAS box out of a SATA connection or make one out of a USB3 connection (using a Highpoint usb3 card with 4 ports and 4 channels). I'll be ZFS-ing them together on 9.2-R. The question is, under zfs which kind of setup will be better? I can stick 8GB RAM into the machine. I want to get 4x 4Tb drives. With the 4-port card, one will go into each port. Similarly with a 4-port SATA. Performance-wise is there much in it, and will ZFS be able to handle it. The machine is a desktop. The other thing I need to know is, should the machine die, can I just pull the card/disks and put it into another freebsd machine, install zfs and expect the data to still be there? thanks, -- John From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:02:04 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 27337316 for ; Wed, 2 Oct 2013 17:02:04 +0000 (UTC) (envelope-from raymondpwagner@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAD4428B9 for ; Wed, 2 Oct 2013 17:02:03 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id to1so2583169ieb.9 for ; Wed, 02 Oct 2013 10:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sSqAH2lQ1dorrPn+4hxnqrC14hm9P200EKh9GqlbnCU=; b=OYiPF7AragIdt/7kJknZ82flmLKKwOqD19fIIz/OGa9wsKUYTQx7RxXnqDQSJF2pCg 8UbL+hXH0pqScBDws6s94PksuwCwkvKNzVXIOVmKp466Yi9Lcqc5YQKr3OSukY/7Yx67 CQGWeCmr3jyYfgQUGsTIc95D5pVF0ppARumvWFcfKTKKw5tkSSGixKnk2urycwy0F6+j P9KlU+uB5odbG+5iRaD/3xZUiAdsioH9G1WPA1zjvMz1kxtD16tTl8IIrLO5EhRmx74j VPUCeXm33SBQnGRO5oXygM3FA2mkdNHV/t3X4Phj43altbM/2qMvGpvYG855/0XY4x7t UdJw== X-Received: by 10.50.20.99 with SMTP id m3mr2909641ige.54.1380733323290; Wed, 02 Oct 2013 10:02:03 -0700 (PDT) Received: from [192.168.2.21] (64-132-174-139.static.twtelecom.net. [64.132.174.139]) by mx.google.com with ESMTPSA id yt10sm11395068igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 10:02:02 -0700 (PDT) Sender: Raymond Wagner Message-ID: <524C5188.3030007@wagnerrp.com> Date: Wed, 02 Oct 2013 13:02:00 -0400 From: Raymond Wagner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <52497C7F.4030702@digiware.nl> In-Reply-To: <52497C7F.4030702@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:02:04 -0000 On 9/30/2013 9:28 AM, Willem Jan Withagen wrote: > On 2013-09-30 11:07, Borja Marcos wrote: > > [About ZFS and df not being friends] >> Times change, embracing the satanic filesystem implies that you have >> to change your mindset (and your scripts!) :) > > Let alone what you need to change when using net-snmp and cacti, if > you want to make some easy and obvious graphs.. > Still looking for time to figure that out. Seems like a stacked graph would be well suited for that purpose. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:15:03 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC435A3B for ; Wed, 2 Oct 2013 17:15:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB8FF29CF for ; Wed, 2 Oct 2013 17:15:03 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 7F49D28CBF; Wed, 2 Oct 2013 10:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1380734102; bh=6dSFTwnFLGa2wT9pKuv4BX16IrO591vZb0r3DhwK0qE=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=kKlnEilMFoBp6ypCHlEyVm+/zRqI8TZWGRk8kDZjvaiPiedJxOV3asW7mkABQ/zMf SRBt9FFpGPM4DMm8PYS6nQEg3DXaGQE/+wksjwtbI9jTo6iKrDC0tZ4auxXkbKQSe9 Al0IEhEzs6SPQT6zw/oxYJ+JYO1oZ6aplDydAuVc= Message-ID: <524C5495.3040800@delphij.net> Date: Wed, 02 Oct 2013 10:15:01 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Edho Arief , d@delphij.net Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> <524B1EB6.2020003@delphij.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:15:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/02/13 09:59, Edho Arief wrote: > On Wed, Oct 2, 2013 at 4:12 AM, Xin Li > wrote: >> >> I don't think 'zfs list' reports the "right" numbers either: >> there is no notion of "available shared space between this, this >> and this file systems". The underlying problem is that it's >> always hard to represent mutli-dimensional value in a linear >> manner, to do it, we would need to create something new. >> > > Considering df output for UFS is never `size = used + avail` > anyway, is there any problem with having df output for zfs to: > > - size: total size (zpool-wide, sans redundancy) - used: specific > filesystem usage - avail: total available space > > ? This doesn't solve OP's problem... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCgAGBQJSTFSVAAoJEG80Jeu8UPuzMboIAJQgYmPGMgNwkTvPOMJlkQk8 C7VM8LfnMYxXxtNfaAPt9ccJ0fU5Ib9n9z7dQFN0IuE5nQMUEAcTpiNs+lOi5Ot2 GWvRx0+Sj2mFConHT2QuXxsNSGWI5CfcLJ4oQ0RCmBCxXpI6dvD6H/L1xWq1phYN bneWbd0saCWIU+Bbiv5xvdR1JyPg7StB7R+/JrtlM5npPtFSo3EVkhyBh+G9jKop UZLGrwDgEdl7Vc06rQh+3ee9eP11o0Mm52NJPdAbCD0EuFJzgzn7psiQVZaDLYJr lYOhLqww+8R9/wZgp7XWxpTL0aOaZ+EI9NVsxfRFH7Wa0bE9BrF/0RAaZo3/M6s= =yRY2 -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:16:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 452CFBE3; Wed, 2 Oct 2013 17:16:35 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE4029FB; Wed, 2 Oct 2013 17:16:34 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r92HGXwt094627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Oct 2013 10:16:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r92HGXeq094626; Wed, 2 Oct 2013 10:16:33 -0700 (PDT) (envelope-from jmg) Date: Wed, 2 Oct 2013 10:16:33 -0700 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: Endian issues, LE write to BE partitions Message-ID: <20131002171633.GD56872@funkthat.com> References: <1380730546.1619.47.camel@localhost> <20131002164408.GB56872@funkthat.com> <1380732992.6516.11.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1380732992.6516.11.camel@localhost> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 02 Oct 2013 10:16:34 -0700 (PDT) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:16:35 -0000 Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:56 -0700: > On Wed, 2013-10-02 at 09:44 -0700, John-Mark Gurney wrote: > > Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:15 -0700: > > > Using makefs from an amd64 host to build a f/s in a VTOC8 partition will > > > destroy the entire partition table. I simplified the test to simple dd > > > to an existing partition and got the same result, exonerating mkfs > > > > > > I suspect a lack of endian knowledge in geom itself, not > > > geom_part_vtoc8. > > > > > > test case: > > > using amd64 host (10.0 current) create monolothic image > > > truncate -s+5G /var/tmp/myfile.img > > > mdconfig -f /var/tmp/myfile.img > > > build and load geom_part_vtoc8 kernel module > > > use gpart to create VTOC8 part table > > > add partition to part table to yeild the following: > > > > > > => 0 10442250 md0 VTOC8 (5.0G) > > > 0 10442250 1 freebsd-ufs (5G) > > > > This looks like a user error, or an issue that VTOC allows you to > > create/write to a partition that covers the label metadata... So this > > is most definately a VTOC8 issue... VTOC8 should at least return an > > error when trying to write sectors that contain it's metadata.. > > > Do you mean "user error" in that I personally executed a command that > should not have been run or "user error" in that the geom_part_vtoc8 > "user" should not allow me to dd to the partition? user error in that you created a partition that covered the metadata and a bug in vtoc8 that allows you to overwrite it while you hold it's child parition open for writing.. If you instead started the partition you created at 0, if you added a -b 16 to your gpart add, you'd skip over the vtoc8 meta data in the first sector and your dd wouldn't overwrite it... > I suspect that on a g_write() from geom_part_vtoc8, the data is not be > swapped around correctly. Should the geom_part_vtoc8 module be swapping > the data in this case (writing from a LE machine to a BE f/s)? Nothing to do w/ BE or LE... > > newfs actually skips the first few KB of the disk because bsdlabels > > would do the same thing... > > > > I would prefer to use newfs in this case actually, but it has no > knowledge of how to write Big Endian f/s on Little Endian systems. > Hence I was stuck with trying to use makefs in this case to get the f/s > populated. > > Unless I'm mistaken, if I use newfs on this disk image from my amd64 > host, it will get a little endian f/s. I'm assuming that this is part > of my current problem. The first statement is correct, the last is not.. there are no edian issues that I see yet... > > This sounds like makefs is writing to the first few KB of the disk > > unlike newfs which probably doesn't (because it knows it might be on > > a partitioned disk and could destroy the partition table)... > > makefs, in this case, isn't really doing anything wrong here. Like dd, > its using the target device as a destination for a file system creation. > That's why I switched my test case over to dd, from makefs, for > simplification of the problem. except it behaves differently from newfs... > > > dd to md0a from dev zero for just a bit > > > dd if=/dev/zero of=/dev/md0a bs=64k count=100 > > > > > > destroy md0 via mdconfig -d -u 0 > > > recreate it with mdconfig -f /var/tmp/myfile.img > > > > > > gpart displays no partions for the image any more: > > > gpart: No such geom: md0. See my script of doing it (though I'm not sure why -b 16 starts it at 16065): # truncate -s+5G myfile.img # mdconfig -t vnode -f myfile.img -a md0 # kldload geom_part_vtoc8 # gpart create -s vtoc8 /dev/md0 md0 created # gpart add -t freebsd-ufs -b 16 /dev/md0 md0a added # gpart show /dev/md0 => 0 10442250 md0 VTOC8 (5.0G) 0 16065 - free - (7.8M) 16065 10426185 1 freebsd-ufs (5.0G) # dd if=/dev/zero of=/dev/md0a bs=64k count=100 100+0 records in 100+0 records out 6553600 bytes transferred in 0.402172 secs (16295512 bytes/sec) # mdconfig -d -u 0 # mdconfig -a -t vnode -f myfile.img md0 # ls /dev/md0* /dev/md0 /dev/md0a # gpart show /dev/md0 => 0 10442250 md0 VTOC8 (5.0G) 0 16065 - free - (7.8M) 16065 10426185 1 freebsd-ufs (5.0G) See, the vtoc8 partition survived... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:35:39 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1261B3CF for ; Wed, 2 Oct 2013 17:35:39 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C8A722B61 for ; Wed, 2 Oct 2013 17:35:38 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id nd7so824514qeb.35 for ; Wed, 02 Oct 2013 10:35:38 -0700 (PDT) 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=u3f+GuL4YHuNBXM8S1deUMEedlPyjWc/TOxsUDgfOPM=; b=VcjsFJqWPoiumMQBhALV4jHcqLKkC7ClRxn6+a9D/iBsamBrzaDZ/aOEzrMHZQlha4 qVQqEoQGbpZEYpH4pJIvG1nIQQC3TkN33bQ1yhKXzOXC3hI1mMxxr6YUfK/LOKym42xC zbjSrzYAzwNoqXmz+kZ+m9lvy3gzkjG1PMIQq4M8XwKJHewgHnFgaVqKLLohVhhmEiMT b3AlDo4HR+4/ujtnI/2xKia2U3JbrDW/dtOHPoMyxW+pHUKB7mCZDTSoZE42Obd6mPtZ yUY14vxPgrD2GDxbESkE2730rrdPBK0o+V+cfKmuPCfwZkVqOK8iIu4Sct5SyVA0NInV J1ew== MIME-Version: 1.0 X-Received: by 10.49.131.132 with SMTP id om4mr4485337qeb.2.1380735338001; Wed, 02 Oct 2013 10:35:38 -0700 (PDT) Received: by 10.49.39.33 with HTTP; Wed, 2 Oct 2013 10:35:37 -0700 (PDT) In-Reply-To: <20131002170159.GA6937@potato.growveg.org> References: <20131002170159.GA6937@potato.growveg.org> Date: Wed, 2 Oct 2013 10:35:37 -0700 Message-ID: Subject: Re: newbie zfs query - usb3 or sata? From: Freddie Cash To: John Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:35:39 -0000 On Wed, Oct 2, 2013 at 10:01 AM, John wrote= : > Hello freebsd-fs. I have a possible newbie question, and am not sure > if this should go into -hardware: > > I have the situation where I need to add more hard drives but I haven't > got the space in the existing box. So I have two choices - make > a DAS box out of a SATA connection or make one out of a USB3 > connection (using a Highpoint usb3 card with 4 ports and 4 channels). > I'll be ZFS-ing them together on 9.2-R. > > The question is, under zfs which kind of setup will be better? > I can stick 8GB RAM into the machine. I want to get 4x 4Tb drives. > With the 4-port card, one will go into each port. Similarly > with a 4-port SATA. Performance-wise is there much in it, and > will ZFS be able to handle it. The machine is a desktop. > > The other thing I need to know is, should the machine die, can I just pul= l > the card/disks and put it into another freebsd machine, install zfs and > expect the data to still be there? =E2=80=8BIf there's an option to use SATA (even eSATA), then use it. While the theoretical performance of USB3 is good, the CPU load isn't worth it, especially if using 4 separate USB3 port. And, USB has a nasty habit of every now and then messing up a SCSI command or dropping a device off the bus, or otherwise doing "not very nice" things. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 20:13:51 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55817C16 for ; Wed, 2 Oct 2013 20:13:51 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm49-vm10.bullet.mail.bf1.yahoo.com (nm49-vm10.bullet.mail.bf1.yahoo.com [216.109.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFD332596 for ; Wed, 2 Oct 2013 20:13:50 +0000 (UTC) Received: from [98.139.212.146] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 02 Oct 2013 20:13:49 -0000 Received: from [98.139.213.9] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 02 Oct 2013 20:13:49 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 02 Oct 2013 20:13:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380744829; bh=uTqth4e9adrjYntf0xvUKX0f+t/QfgeuOMWIM3cc5KY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=L/JCEPaEABxzDzwoSc/nAMjgbq+DftcQb85UhClyuvBUUnWXPJhDmePRChhKZZhLZi2euOo7CNTTFKJn/1tHMQVA5739iS1hx2u/ShpFkX/4sNCyqtekQDQGuyEjpdYpXxk+LWPWsZzS/vOn0GqtQF5zD1VoNDEVq/pElkt8AMA= X-Yahoo-Newman-Id: 195518.85991.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Lr8YVB0VM1nsFWEiwGjJU_jkl2bTKos53PCmA42C__E7pPJ FcdSSR7nam1GLMW3rFOkvih2BLXYQFzeBMqoNkmj14YAIHV5yHBMn3CDD4ir Pq.6KrMZBdnDraPT5RkthtTJoXOpXwkUU56X9l9jlX1Q98GNbWIKwkchc3Av TM4EQoBeN0metrZyOXjVsr6nGwgjy5ip0RnT1TFbIZyaT_nEfRccM5jURqk6 UOCoGi0qGJLfBE7ngWJ7yVQ9jgArZ8utdRTLDTPuoYdrQs8D4ZmyC9MOlU2Z v0CEo_S.COA4LFdHKSxnPnSTWNnVU5UBBWvV7UNjyLtQyzoLRWZWHGrNbcs6 ZDS3ynm43vOl_8lDlPexu2ZFvPJviodl5yVNwLeTt6vCti6.r.DmuacsGMhm oSL9AZTdw92KlxWxd1Ch8brSFVk.dB1yKL4C9Lm1gG.eS0wgToqj1WD790B1 pabWRtXYVz5dFzQSc6ZzHDfZcUK4JzilCZnS0CCdwUo5KCv6u5X_yT.FsYb1 CEK2wafAOdxflZxgnZa9cJl4e0PxxLXCOv1koM7PdUz8ETixKZhSjnA4KpDX 2OQ-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp109.mail.bf1.yahoo.com with SMTP; 02 Oct 2013 13:13:49 -0700 PDT Subject: [SOLVED?] Re: Endian issues, LE write to BE partitions From: Sean Bruno To: sbruno@freebsd.org In-Reply-To: <1380730546.1619.47.camel@localhost> References: <1380730546.1619.47.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1n515Inn0ufD0tsRQbzX" Date: Wed, 02 Oct 2013 13:13:47 -0700 Message-ID: <1380744827.6516.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:13:51 -0000 --=-1n515Inn0ufD0tsRQbzX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2013-10-02 at 09:15 -0700, Sean Bruno wrote: > Using makefs from an amd64 host to build a f/s in a VTOC8 partition will > destroy the entire partition table. I simplified the test to simple dd > to an existing partition and got the same result, exonerating mkfs >=20 > I suspect a lack of endian knowledge in geom itself, not > geom_part_vtoc8. =20 >=20 > test case: > using amd64 host (10.0 current) create monolothic image > truncate -s+5G /var/tmp/myfile.img > mdconfig -f /var/tmp/myfile.img > build and load geom_part_vtoc8 kernel module > use gpart to create VTOC8 part table > add partition to part table to yeild the following: >=20 > =3D> 0 10442250 md0 VTOC8 (5.0G) > 0 10442250 1 freebsd-ufs (5G) =20 >=20 > dd to md0a from dev zero for just a bit > dd if=3D/dev/zero of=3D/dev/md0a bs=3D64k count=3D100 >=20 > destroy md0 via mdconfig -d -u 0 > recreate it with mdconfig -f /var/tmp/myfile.img >=20 > gpart displays no partions for the image any more: > gpart: No such geom: md0. >=20 > bcc freebsd-geom Nathan brought me some knowledge. newfs(8) knows that the first 16 sectors for the first partition are special and not to touch it. makefs(8) does not. So, as a proof of concept, I modified makefs to read() the first 16 sectors from the "image" (in my case, /dev/md0a) and throw it away. (lseek() failed on the partition, so read() was used) This got me to a bootable SPARC64 image in qemu-system-sparc64, and will probably allow further booting in other BE architectures. Is this patch going to break non "device" makefs calls? e.g. if I want to create an image file and not use a loopback device? Index: ffs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ffs.c (revision 255871) +++ ffs.c (working copy) @@ -470,6 +470,7 @@ char *buf; int i, bufsize; off_t bufrem; + char temp_buf[16*512]; =20 assert (image !=3D NULL); assert (fsopts !=3D NULL); @@ -480,6 +481,7 @@ warn("Can't open `%s' for writing", image); return (-1); } + read(fsopts->fd, temp_buf, 16*512); =20 /* zero image */ #if HAVE_STRUCT_STATVFS_F_IOSIZE && HAVE_FSTATVFS bcc - nwhitehorn, freebsd-geom --=-1n515Inn0ufD0tsRQbzX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSTH57AAoJEBkJRdwI6BaHgJsH/jwJnObv/zaBDTXRnwuusSV4 Cj1MSaJOVgEyrguD75FMOCD3IcvXMThzehapdrc8OoWvdFXdufeXskUfS+FTWU8w BTMir0SVaX1FGN518pXy+PHQpwEi8tfm8VTnspzUqrQwxK6qB/snwdPfO0wd88eS vy1hXcnKwSugoIrFK5RYMjyXNMIuuFKxDRbxVDOEmpN6JgNeBxwl/RYnrsxQJPme 0y+ZFDZ3Qx7gEs3NjWM80uS2iu8TXst0yoM5mgQqkHkxdQsCximIUq4zQaBtEI5/ Tx7ZoxM3SrP0o9hQBNFEn2EYbfg94NY9uTR/Z9IkEcbd2/ZMcquwFxpKq+23Vcc= =z2iu -----END PGP SIGNATURE----- --=-1n515Inn0ufD0tsRQbzX-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 3 09:45:26 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72135B3F for ; Thu, 3 Oct 2013 09:45:26 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id DA295223E for ; Thu, 3 Oct 2013 09:45:25 +0000 (UTC) Received: from cpsps-ews14.kpnxchange.com ([10.94.84.181]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 3 Oct 2013 11:44:15 +0200 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews14.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 3 Oct 2013 11:44:15 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 3 Oct 2013 11:44:15 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id F043C29B5; Thu, 3 Oct 2013 11:44:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Edho Arief" , d@delphij.net, "Xin Li" Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> <524B1EB6.2020003@delphij.net> <524C5495.3040800@delphij.net> Date: Thu, 03 Oct 2013 11:44:14 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <524C5495.3040800@delphij.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 03 Oct 2013 09:44:15.0345 (UTC) FILETIME=[1F626610:01CEC01D] X-RcptDomain: freebsd.org Cc: FreeBSD List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 09:45:26 -0000 On Wed, 02 Oct 2013 19:15:01 +0200, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 10/02/13 09:59, Edho Arief wrote: >> On Wed, Oct 2, 2013 at 4:12 AM, Xin Li >> wrote: >>> >>> I don't think 'zfs list' reports the "right" numbers either: >>> there is no notion of "available shared space between this, this >>> and this file systems". The underlying problem is that it's >>> always hard to represent mutli-dimensional value in a linear >>> manner, to do it, we would need to create something new. >>> >> >> Considering df output for UFS is never `size = used + avail` >> anyway, is there any problem with having df output for zfs to: >> >> - size: total size (zpool-wide, sans redundancy) - used: specific >> filesystem usage - avail: total available space >> >> ? > > This doesn't solve OP's problem... The OP does not even have a real problem. It is just that the available diskspace is filled by more sources than expected. Which is just a sysadmin thing. The OP was just curious how it worked because he did not expect this. You can't throw zpool+zfs at a job and expect everything to be the same as your previous multiple ufs partitions. Or think: "Wow, all my zfs filesystems are as big as the total pool. I magically gained space!" and than explain about df. Ronald. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.21 (FreeBSD) > > iQEcBAEBCgAGBQJSTFSVAAoJEG80Jeu8UPuzMboIAJQgYmPGMgNwkTvPOMJlkQk8 > C7VM8LfnMYxXxtNfaAPt9ccJ0fU5Ib9n9z7dQFN0IuE5nQMUEAcTpiNs+lOi5Ot2 > GWvRx0+Sj2mFConHT2QuXxsNSGWI5CfcLJ4oQ0RCmBCxXpI6dvD6H/L1xWq1phYN > bneWbd0saCWIU+Bbiv5xvdR1JyPg7StB7R+/JrtlM5npPtFSo3EVkhyBh+G9jKop > UZLGrwDgEdl7Vc06rQh+3ee9eP11o0Mm52NJPdAbCD0EuFJzgzn7psiQVZaDLYJr > lYOhLqww+8R9/wZgp7XWxpTL0aOaZ+EI9NVsxfRFH7Wa0bE9BrF/0RAaZo3/M6s= > =yRY2 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 3 14:57:32 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4511FC94 for ; Thu, 3 Oct 2013 14:57:32 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1597B29C8 for ; Thu, 3 Oct 2013 14:57:31 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4369F217C0 for ; Thu, 3 Oct 2013 10:57:21 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 03 Oct 2013 10:57:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=t8NanBQhXQxNUdc2xjotowofepc=; b=Ywz w5RqWQ9BH0sTqZh5Ku22ixTT7l5W3LO/rl0aljtX50lRy+jNwpVvj7HYmnQkWHal BoHclUZmKQlgiUoZt3NpwBWmZXjbiUd/nNbKYZjcqNLUJTRaQkyXoYgLrt7hxWI2 wSB+moPyXPulNJQ2fiWadyB0fPfApnVOYwTSi0Hw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id CC08A1086C5; Thu, 3 Oct 2013 10:57:21 -0400 (EDT) Message-Id: <1380812241.31283.29585397.2EC656B0@webmail.messagingengine.com> X-Sasl-Enc: 4iIs7KoKMsygR6kThsehFNMjMrGAt3EkGSxWw+D+w64a 1380812241 From: Mark Felder To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: References: <52457A32.2090105@fsn.hu> <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es> <20130930234401.GA68360@neutralgood.org> <524B1EB6.2020003@delphij.net> <524C5495.3040800@delphij.net> Subject: Re: zfs: the exponential file system from hell Date: Thu, 03 Oct 2013 09:57:21 -0500 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:57:32 -0000 I have to do some accounting on our backup servers to know what to bill customers for their space usage. I do this which is reasonably accurate for our needs chomp($kb = `zfs get -o value -Hp used $subdir` - `zfs get -r -o value -Hp usedbysnapshots $subdir | grep -v "-" | paste -sd+ - | bc`); From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 01:10:03 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B35785A for ; Fri, 4 Oct 2013 01:10:03 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58E712B5A for ; Fri, 4 Oct 2013 01:10:02 +0000 (UTC) Received: from ip-136.ish.com.au ([203.29.62.136]:63808) by fish.ish.com.au with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1VRtrD-0003j0-1T for freebsd-fs@freebsd.org; Fri, 04 Oct 2013 11:07:04 +1000 X-CTCH-RefID: str=0001.0A150203.524E14B7.00C6:SCFSTAT15613948, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Message-ID: <524E14B6.9040808@ish.com.au> Date: Fri, 04 Oct 2013 11:07:02 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: hast degraded X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 01:10:03 -0000 I am in a bit of a mess. I have a pair of servers running ZFS over HAST on four drives. Today the primary server reported that the hast array had changed role to secondary. And this started causing corruption to data since the zpool was still mounted and trying to write to this array. I was not able to make the hast primary again since when I did that it shows like this: # hastctl status Name Status Role Components ssd2 degraded primary /dev/da2 10.8.8.1 ssd3 degraded primary /dev/da3 10.8.8.1 ssd4 degraded primary /dev/da4 10.8.8.1 ssd5 degraded primary /dev/da5 10.8.8.1 On the slave server, I get exactly the same result. When I switch hast to primary role it is marked as degraded. Where to from here? How can I force the hast array to go back to primary role? I desparately need to recover from this point since the backups are missing some part of the data set. I had hoped that hast under a zfs raid would give me extra redundancy, however it appears it has instead given me a new way to corrupt all the data on both machines simultaneously. Cheers Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 02:39:46 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 896B8D6A for ; Fri, 4 Oct 2013 02:39:46 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 468F72E8A for ; Fri, 4 Oct 2013 02:39:45 +0000 (UTC) Received: from ip-136.ish.com.au ([203.29.62.136]:64383) by fish.ish.com.au with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1VRvIo-0007yT-1v for freebsd-fs@freebsd.org; Fri, 04 Oct 2013 12:39:39 +1000 X-CTCH-RefID: str=0001.0A150201.524E2A6B.0005:SCFSTAT15613948, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Message-ID: <524E2A69.9070009@ish.com.au> Date: Fri, 04 Oct 2013 12:39:37 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: hast degraded References: <524E14B6.9040808@ish.com.au> In-Reply-To: <524E14B6.9040808@ish.com.au> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 02:39:46 -0000 On 4/10/13 11:07am, Aristedes Maniatis wrote: > ssd2 degraded primary /dev/da2 10.8.8.1 OK, I think I understand better what I'm looking at now. Degraded just means that the secondary is not running. The primary is actually mounting just fine, however all the metadata in the zpool is now corrupted so I cannot recover with zpool import -F This corruption is on both the master and slave, so I think I'm completely screwed at this point. My best guess is that the hast master became slave, but didn't properly export the zpool. The slave became the master and tried to write data into the pool in the other direction until the whole thing became hopelessly messed up. I can see the power of hast, but also that it requires way more attention to the details of failover than my simplistic approach gave it. There is at least one failure mode which increases the chance of corrupting the whole filesystem on both master and slave, as compared to a more simplistic rsync periodic sychronisation. Not so cheery, Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 09:50:31 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1862AB27 for ; Fri, 4 Oct 2013 09:50:31 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F07692210 for ; Fri, 4 Oct 2013 09:50:30 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VS21f-0000JP-KZ for freebsd-fs@freebsd.org; Fri, 04 Oct 2013 02:50:23 -0700 Date: Fri, 4 Oct 2013 02:50:23 -0700 (PDT) From: Beeblebrox To: freebsd-fs@freebsd.org Message-ID: <1380880223590-5848720.post@n5.nabble.com> Subject: Questions re swap-on-zfs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:50:31 -0000 I have 2 swap devices on my system. #1-tank0/swap on ZFS, #2-/dev/ada0p1 on SSD 1GB. I have some questions for swap-on-zfs: 1. I had read in the past that swap-on-zfs can cause instability if memory gets used to full capacity. Is this still the case, or has that issue been corrected? The reason I created swap-#2 is precisely for this purpose; a small backup resource. 2. If the problem still persists, I would like to tweak the setup so that swap-#2 is only used as last resort. I tried setting the priority (pri) in fstab, but it does not seem to work - how can this be done? /dev/ada0p1 none swap sw,pri=0 0 0 tank0/swap none zfs sw,pri=9 0 0 3. Is it necessary for the data on swap to go through the Intent Log? I have a separate ZIL device for tank0 pool. What risk is there if I disable the log for the swap dataset? Is this done by modifying the "primarycache" parameter for dataset? 4. Any other ideas to speed-up swap performance on tank0/swap? Regards. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Questions-re-swap-on-zfs-tp5848720.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 10:42:27 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC958AD9 for ; Fri, 4 Oct 2013 10:42:27 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74E1C24DC for ; Fri, 4 Oct 2013 10:42:27 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id o10so1692895eaj.41 for ; Fri, 04 Oct 2013 03:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DKySxSiN3ldlD2yiFJeeXyF1RLGkY4ESIlIJPcdIY0w=; b=Jz0CeIdpaAp1zYyDeKgBiq3400sQvHYUD+QdXxwIl0ZJfkhhN+R9UuQ/6xB2g+VXND oegEBWasuM8jFcdq9T45QEayVCKGaipYWasSeefjczvgbFAZCPVbjx4ftReNyCqug3/u HGIX7B9TvBiHpMkOqKRV8L1ZDrWaUzUWCdPnnVYn3BL7TGkZXpynznheiL7T49XPUv3R afW/WaNSsLanv67amr0kNmVhKc58BAZfRipQIDCFXbPxBVGYTYWIeQJsB5wy6TPLoUNY O4saRPPwhnfPrkx6NPFbduq3vHHDrtvjMl5/t00Tro+w33s9fMrNrO16dNsjA0SWtCZG 5y6w== X-Received: by 10.14.48.14 with SMTP id u14mr1514245eeb.74.1380883345927; Fri, 04 Oct 2013 03:42:25 -0700 (PDT) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id i1sm26596111eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 03:42:25 -0700 (PDT) Message-ID: <524E9B95.9010307@gmail.com> Date: Fri, 04 Oct 2013 12:42:29 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Beeblebrox Subject: Re: Questions re swap-on-zfs References: <1380880223590-5848720.post@n5.nabble.com> In-Reply-To: <1380880223590-5848720.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:42:27 -0000 Beeblebrox wrote: > I have 2 swap devices on my system. #1-tank0/swap on ZFS, #2-/dev/ada0p1 on > SSD 1GB. I have some questions for swap-on-zfs: > > 1. I had read in the past that swap-on-zfs can cause instability if memory > gets used to full capacity. Is this still the case, or has that issue been > corrected? The reason I created swap-#2 is precisely for this purpose; a > small backup resource. > > 2. If the problem still persists, I would like to tweak the setup so that > swap-#2 is only used as last resort. I tried setting the priority (pri) in > fstab, but it does not seem to work - how can this be done? > /dev/ada0p1 none swap sw,pri=0 0 0 > tank0/swap none zfs sw,pri=9 0 0 > > 3. Is it necessary for the data on swap to go through the Intent Log? I have > a separate ZIL device for tank0 pool. What risk is there if I disable the > log for the swap dataset? Is this done by modifying the "primarycache" > parameter for dataset? > > 4. Any other ideas to speed-up swap performance on tank0/swap? > > Regards. > I have one machine that has swap on ZFS. This is the only machine that hangs completely when a swap starvation occurs. It happens regualy because it is an old machine with only 2GB of RAM. That machine is running a version of FreeBSD 9.1 stable from april i guess. It is not an heavy duty server just an offsite backup system, so I can live with it. All other machines tho heavier on RAM have no problems even when a swap starvation occurs. I will not use swap on ZFS anymore. regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 14:34:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0D372B0; Fri, 4 Oct 2013 14:34:10 +0000 (UTC) (envelope-from varanasisai@gmail.com) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F174211F; Fri, 4 Oct 2013 14:34:10 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id w16so2277891vbb.8 for ; Fri, 04 Oct 2013 07:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mhXtRfBP2DNqw48TywrkxtAVWHwVbQkPtf5e4Cw/eWw=; b=HUUN/SBIPS4A84u4t6BxDO+PHz9BPVS3zXmsWLiXU+u9kMijcg2OnKbPhDqFeOvUMP KKM9iX/FFsRJzMenvPFECk3KYgeUNbbyXe1jkajYDlNzBao29YRgheBPUHxj1rb2Y1xS ps0ypDciYc3CdYBVWslsnhfHczicmyzCeVKZRUv51IKso7SFMrQjx5VGhmWEwIZoQbx1 gtF0cwLVEgOQ0f5HbC5hD0WqFjAjEUpFgVo4fiM5hiXK0TtcoP5CrQqWTgds4yuEVf/s 7IMbWCKuYD+Zc364GuR9Nu2BDvHjL/PWMdcqJuDmPqQyP22ieVR/aP8H1xy6n7g0yLOn zKGg== MIME-Version: 1.0 X-Received: by 10.58.196.148 with SMTP id im20mr352677vec.28.1380897249461; Fri, 04 Oct 2013 07:34:09 -0700 (PDT) Received: by 10.52.30.75 with HTTP; Fri, 4 Oct 2013 07:34:09 -0700 (PDT) Date: Fri, 4 Oct 2013 20:04:09 +0530 Message-ID: Subject: gptid's in fstab while installing FreeBSD using ISO From: varanasi sainath To: freebsd-drivers@freebsd.org, freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, abgupta@microsoft.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:34:10 -0000 Hi All, How do I get gptid's as default in fstab while installing using FreeBSD iso file (Virtual,machine installation) ? Is this possible currently? if not how do I achieve this? I use guided partitioning while installing - If I were to tweak in to the source code which files or drivers I should be focusing on? which drivers write the contents of fstab? PS: any reason why we use device names in the place of gptid's as default in fstab. Thanks, Sainath. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 14:50:30 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8BD37AD8; Fri, 4 Oct 2013 14:50:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6122D2211; Fri, 4 Oct 2013 14:50:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r94EoU0o081634; Fri, 4 Oct 2013 14:50:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r94EoUbD081633; Fri, 4 Oct 2013 14:50:30 GMT (envelope-from linimon) Date: Fri, 4 Oct 2013 14:50:30 GMT Message-Id: <201310041450.r94EoUbD081633@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/182570: [zfs] [patch] ZFS panic in receive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:50:30 -0000 Old Synopsis: ZFS panic in receive New Synopsis: [zfs] [patch] ZFS panic in receive Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 4 14:49:34 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=182570 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 16:35:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3B434B1 for ; Fri, 4 Oct 2013 16:35:17 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAA3280D for ; Fri, 4 Oct 2013 16:35:17 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id z5so3590227lbh.28 for ; Fri, 04 Oct 2013 09:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gXpZ7FN8jotgJ02a26syQg6yqVl8zGYSZaEcigU/pK8=; b=eewSXOzRVptZKgp+NgouGckm1zZ/efjMKZtb3H8yKlqAUq9OYxp9/NdOnZzm+OA1QZ EtNGNE9qN626plMBxwqB5Kb+E8nt6UBEXLiouOrfGmMvDqA2rYmq2HuLZRz4Ts4YBg4X yk2wHOfQAHaCmWkhVvqmAFcz62YB3n8R7w3v7t91n1eNt1pTDk1wZZnSEgPeqDHnRW02 ddHWGj5Of//lQbwhiomTHLVJgjW6jhXXqvCmXRbNryJjUG0Kon1npTbuQJm4L5SnDKZi 2o0jp+Oxr8ff+Ye5+Lwxzu7IEAgHILaT6b03vDC2WEjscS5d1VNKPnUZBQQPRXKkH8JR G3gg== X-Received: by 10.112.167.66 with SMTP id zm2mr1938888lbb.46.1380904515324; Fri, 04 Oct 2013 09:35:15 -0700 (PDT) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id f17sm9311107lbo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 09:35:14 -0700 (PDT) Message-ID: <524EEE40.5060208@gmail.com> Date: Fri, 04 Oct 2013 19:35:12 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Beeblebrox , freebsd-fs@freebsd.org Subject: Re: Questions re swap-on-zfs References: <1380880223590-5848720.post@n5.nabble.com> In-Reply-To: <1380880223590-5848720.post@n5.nabble.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:35:17 -0000 04.10.2013 12:50, Beeblebrox wrote: > I have 2 swap devices on my system. #1-tank0/swap on ZFS, #2-/dev/ada0p1 on > SSD 1GB. I have some questions for swap-on-zfs: > > 1. I had read in the past that swap-on-zfs can cause instability if memory > gets used to full capacity. Is this still the case, or has that issue been > corrected? The reason I created swap-#2 is precisely for this purpose; a > small backup resource. Yes. > 2. If the problem still persists, I would like to tweak the setup so that > swap-#2 is only used as last resort. I tried setting the priority (pri) in > fstab, but it does not seem to work - how can this be done? > /dev/ada0p1 none swap sw,pri=0 0 0 > tank0/swap none zfs sw,pri=9 0 0 Nope. > 3. Is it necessary for the data on swap to go through the Intent Log? I have > a separate ZIL device for tank0 pool. What risk is there if I disable the > log for the swap dataset? Is this done by modifying the "primarycache" > parameter for dataset? There's no need for SWAP to go through any caches or ZIL. > 4. Any other ideas to speed-up swap performance on tank0/swap? In fact I even tried this: * primarycache=metadata (that's would speed up finding blocks without caching them; * logbias=throughput (don't use ZIL); * sync=disabled (write data fast and right now); * checksum=off (if it's gone it's gone, period). The machine still hangs from time to time so I think you wouldn't be lucky too. PS: compression=lz4 makes this host survive longer but this can be just my imagination... -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 4 18:27:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C36047BC for ; Fri, 4 Oct 2013 18:27:17 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 831762E5B for ; Fri, 4 Oct 2013 18:27:17 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id ib11so1998401vcb.28 for ; Fri, 04 Oct 2013 11:27:16 -0700 (PDT) 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=dGSlyF5OVKGxDpHg5Y4/5kTDYEFWC+6MpaXMhB7o9zk=; b=f3o+7GyfodfB69z0eZrIjfGAvRRa32jQYae+zbpMFW2dV8zs7tRaKHuFjrVf4RrnSz 4yF005iZRyQ55Qmy5JJddxLjhyXUUsc3h7OjQVFeh5W08FzuHj6RwOK+y3xDRuoDZpGM kZDUB8GLDZ83w7/U3bdER8Ic/syASzuYmTjJtlyfm928BLtmGqBflGgh7u3OfnRdek1Q roEfGq2oc9Nn3qiicEbQlsG1HjY+y4qziZokWNiqvu9w+GUeRHpAC2QU4vNbCiPJuciI psKJAcycp8TYq4Ef14WDJSD32iIseXCsIn2qgqbpNL2jjhAJ0Fcox3sIfTr80j3eMxw+ TeBA== MIME-Version: 1.0 X-Received: by 10.220.105.199 with SMTP id u7mr13062746vco.1.1380911236275; Fri, 04 Oct 2013 11:27:16 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Fri, 4 Oct 2013 11:27:16 -0700 (PDT) In-Reply-To: <524EEE40.5060208@gmail.com> References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> Date: Fri, 4 Oct 2013 14:27:16 -0400 Message-ID: Subject: Re: Questions re swap-on-zfs From: Zaphod Beeblebrox To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs , Beeblebrox X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:27:17 -0000 While I remain convinced that swap on ZFS is bad, it also precludes getting a dump, so I configure my ZFS systems with a partition for swap and a partition for ZFS on each drive. This has the additional bonus of making swap effectively faster on a 2 drive system (2 swap partitions). On Fri, Oct 4, 2013 at 12:35 PM, Volodymyr Kostyrko wrote: > 04.10.2013 12:50, Beeblebrox wrote: > >> I have 2 swap devices on my system. #1-tank0/swap on ZFS, #2-/dev/ada0p1 >> on >> SSD 1GB. I have some questions for swap-on-zfs: >> >> 1. I had read in the past that swap-on-zfs can cause instability if memory >> gets used to full capacity. Is this still the case, or has that issue been >> corrected? The reason I created swap-#2 is precisely for this purpose; a >> small backup resource. >> > > Yes. > > > 2. If the problem still persists, I would like to tweak the setup so that >> swap-#2 is only used as last resort. I tried setting the priority (pri) in >> fstab, but it does not seem to work - how can this be done? >> /dev/ada0p1 none swap sw,pri=0 0 0 >> tank0/swap none zfs sw,pri=9 0 0 >> > > Nope. > > > 3. Is it necessary for the data on swap to go through the Intent Log? I >> have >> a separate ZIL device for tank0 pool. What risk is there if I disable the >> log for the swap dataset? Is this done by modifying the "primarycache" >> parameter for dataset? >> > > There's no need for SWAP to go through any caches or ZIL. > > > 4. Any other ideas to speed-up swap performance on tank0/swap? >> > > In fact I even tried this: > > * primarycache=metadata (that's would speed up finding blocks without > caching them; > * logbias=throughput (don't use ZIL); > * sync=disabled (write data fast and right now); > * checksum=off (if it's gone it's gone, period). > > The machine still hangs from time to time so I think you wouldn't be lucky > too. > > PS: compression=lz4 makes this host survive longer but this can be just my > imagination... > > -- > Sphinx of black quartz, judge my vow. > > ______________________________**_________________ > freebsd-fs@freebsd.org mailing list > http://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 Oct 5 20:40:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 93C65884 for ; Sat, 5 Oct 2013 20:40:36 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 745AF24E6 for ; Sat, 5 Oct 2013 20:40:35 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VSYeQ-0002uB-Ad for freebsd-fs@freebsd.org; Sat, 05 Oct 2013 13:40:34 -0700 Date: Sat, 5 Oct 2013 13:40:34 -0700 (PDT) From: Beeblebrox To: freebsd-fs@freebsd.org Message-ID: <1381005634317-5849247.post@n5.nabble.com> In-Reply-To: References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> Subject: Re: Questions re swap-on-zfs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 20:40:36 -0000 @ Zaphod Beeblebrox-2 >> I have partition for swap and a partition for ZFS on each drive. This >> has the additional bonus of making swap effectively faster on a 2 drive system (2 swap partitions). That's what I have, with the difference that one of the swaps is on the ZFS pool. So I have 2 swaps as well, but want to minimise usage of swap-on-SSD so as to prevent SSD fatigue for the swap area. BTW, I'm the only legitimate President of the Galaxy. Just remember that, "Left Brain" (http://hitchhikers.wikia.com/wiki/Zaphod_Beeblebrox?action=edit§ion=1) ----- FreeBSD-9.2-stable_amd64_root-on-zfs_clang-only-world -- View this message in context: http://freebsd.1045724.n5.nabble.com/Questions-re-swap-on-zfs-tp5848720p5849247.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 5 23:05:03 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1215B38; Sat, 5 Oct 2013 23:05:03 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5FF2A4B; Sat, 5 Oct 2013 23:05:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 6ECCC5CDC9; Sun, 6 Oct 2013 00:56:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id lXNWRE-J9wTk; Sun, 6 Oct 2013 00:56:49 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 8C27A5CC5D; Sun, 6 Oct 2013 00:56:49 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id B1C1D509E7; Sun, 6 Oct 2013 00:56:48 +0200 (CEST) Message-ID: <52509930.2090608@incore.de> Date: Sun, 06 Oct 2013 00:56:48 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: zfs panic during find(1) on zfs snapshot directory References: <522DF5A9.4070103@incore.de> <522E0118.5020106@FreeBSD.org> <522F25AE.1080309@incore.de> <523621DD.7050600@FreeBSD.org> In-Reply-To: <523621DD.7050600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 23:05:03 -0000 Andriy Gapon wrote: > > Please try this patch: > http://people.freebsd.org/~avg/zfs-gfs-8.diff Without your patch my Stable-8 crashes immediately when I run while true; do ls -l /prod/.zfs >/dev/null; done Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e1d9cd stack pointer = 0x28:0xffffff82457757e0 frame pointer = 0x28:0xffffff8245775810 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 87276 (ls) [thread pid 87276 tid 100386 ] Stopped at gfs_vop_inactive+0x1d: movl 0x18(%r13),%ecx #10 0xffffffff805c2ba4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #11 0xffffffff80e1d9cd in gfs_vop_inactive (ap=0xffffff8245775850) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:1232 #12 0xffffffff80639638 in VOP_INACTIVE_APV (vop=0xffffffff80f3b3c0, a=0xffffff8245775850) at vnode_if.c:1923 #13 0xffffffff80491671 in vinactive (vp=0xffffff0103ebdb10, td=0xffffff0078da78e0) at vnode_if.h:807 #14 0xffffffff80496038 in vputx (vp=0xffffff0103ebdb10, func=2) at /usr/src/sys/kern/vfs_subr.c:2347 #15 0xffffffff8049a4ea in kern_statat_vnhook (td=0xffffff0078da78e0, flag=, fd=, path=, pathseg=, sbp=0xffffff8245775a80, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2351 #16 0xffffffff8049a645 in kern_statat (td=, flag=, fd=, path=, pathseg=, sbp=) at /usr/src/sys/kern/vfs_syscalls.c:2320 #17 0xffffffff8049a70a in lstat (td=, uap=0xffffff8245775bb0) at /usr/src/sys/kern/vfs_syscalls.c:2383 #18 0xffffffff805db824 in amd64_syscall (td=0xffffff0078da78e0, traced=0) at subr_syscall.c:114 #19 0xffffffff805c2e9c in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #20 0x000000018098f97c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 11 #11 0xffffffff80e1d9cd in gfs_vop_inactive (ap=0xffffff8245775850) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:1232 1232 gfs_file_t *fp = vp->v_data; (kgdb) info loc vp = (vnode_t *) 0xffffff0103ebdb10 fp = (gfs_file_t *) 0x0 (kgdb) l 1227 struct vnode *a_vp; 1228 struct thread *a_td; 1229 } */ *ap; 1230 { 1231 vnode_t *vp = ap->a_vp; 1232 gfs_file_t *fp = vp->v_data; 1233 1234 if (fp->gfs_type == GFS_DIR) 1235 gfs_dir_inactive(vp); Then I applied your patch to my system with some minor changes, because compile of zfs.ko was not clean: - vrecycle(vp) --> vrecycle(vp, curthread) - vn_lock --> zfs_vnode_lock - zfs_fhtovp(vfs_t *vfsp, fid_t *fidp, int flags, vnode_t **vpp) --> zfs_fhtovp(vfs_t *vfsp, fid_t *fidp, vnode_t **vpp) - in zfsctl_root_lookup arg list: flags --> 0 After loading a new system with your patch integrated in zfs.ko I could run several processes while true; do ls -l /prod/.zfs >/dev/null; done without problems. Starting one process "sudo find /prod/.zfs -mtime +30" gives immediately a panic: panic: __lockmgr_args: unknown lockmgr request 0x0 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1ce __lockmgr_args() at __lockmgr_args+0x21d vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x70 _vn_lock() at _vn_lock+0x47 gfs_dir_lookup() at gfs_dir_lookup+0x15e zfsctl_root_lookup() at zfsctl_root_lookup+0x122 zfs_dirlook() at zfs_dirlook+0x297 zfs_lookup() at zfs_lookup+0x262 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x81 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x62 vfs_cache_lookup() at vfs_cache_lookup+0xf5 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x62 lookup() at lookup+0x44c namei() at namei+0x53d vn_open_cred() at vn_open_cred+0x391 kern_openat() at kern_openat+0x16a amd64_syscall() at amd64_syscall+0x1f4 Xfast_syscall() at Xfast_syscall+0xfc --- syscall (5, FreeBSD ELF64, open), rip = 0x1807359fc, rsp = 0x7fffffffe828, rbp = 0xffffffff --- KDB: enter: panic [thread pid 91769 tid 100298 ] Stopped at kdb_enter+0x3b: movq $0,0x48aae2(%rip) Locked vnodes 0xffffff0002d91000: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0002de9ca8 ref 0 pages 3 lock type ufs: SHARED (count 1) ino 635904, on dev mirror/gm0p9.journal 0xffffff010018ece8: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0073f17d80 ref 0 pages 0 lock type zfs: SHARED (count 1) show lockchain thread 100298 (pid 91769, find) running on CPU 2 #10 0xffffffff803ff367 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:616 #11 0xffffffff803e74ad in __lockmgr_args (lk=0xffffff0073df2270, flags=0, ilk=0xffffff0073df2298, wmesg=, pri=982528, timo=1166294704, file=0xffffffff80d1faf8 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c", line=984) at /usr/src/sys/kern/kern_lock.c:1194 #12 0xffffffff804833e9 in vop_stdlock (ap=) at lockmgr.h:94 #13 0xffffffff8063a870 in VOP_LOCK1_APV (vop=0xffffffff8082af60, a=0xffffff82458441f0) at vnode_if.c:2052 #14 0xffffffff804a3137 in _vn_lock (vp=0xffffff0073df21d8, flags=0, file=0xffffffff80d1faf8 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c", line=984) at vnode_if.h:859 #15 0xffffffff80c1d5be in gfs_dir_lookup (dvp=0xffffff00739fc588, nm=0xffffffff80d31cb8 "snapshot", vpp=0xffffff8245844a10, cr=0xffffff0002345000, flags=0, direntflags=0x0, realpnp=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:984 #16 0xffffffff80cab1b2 in zfsctl_root_lookup (dvp=0xffffff00739fc588, nm=0xffffffff80d31cb8 "snapshot", vpp=0xffffff8245844a10, pnp=0x0, flags=0, rdir=0x0, cr=0xffffff0002345000, ct=0x0, direntflags=0x0, realpnp=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:544 #17 0xffffffff80cae837 in zfs_dirlook (dzp=0xffffff0073e7d450, name=, vpp=0xffffff8245844a10, flags=, deflg=, rpnp=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:400 #18 0xffffffff80cc0ac2 in zfs_lookup (dvp=0xffffff010018ece8, nm=0xffffff82458444a0 "..", vpp=0xffffff8245844a10, cnp=0xffffff8245844a38, nameiop=0, cr=0xffffff0073e09400, td=0xffffff007367b470, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1481 #19 0xffffffff80cc12f1 in zfs_freebsd_lookup (ap=0xffffff8245844610) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5839 #20 0xffffffff8063a2b2 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff80d3c100, a=0xffffff8245844610) at vnode_if.c:193 #21 0xffffffff80481215 in vfs_cache_lookup (ap=) at vnode_if.h:80 #22 0xffffffff8063a372 in VOP_LOOKUP_APV (vop=0xffffffff80d3c100, a=0xffffff8245844710) at vnode_if.c:126 #23 0xffffffff8048898c in lookup (ndp=0xffffff82458449e0) at vnode_if.h:54 #24 0xffffffff80489b0d in namei (ndp=0xffffff82458449e0) at /usr/src/sys/kern/vfs_lookup.c:269 #25 0xffffffff804a2641 in vn_open_cred (ndp=0xffffff82458449e0, flagp=0xffffff82458449dc, cmode=0, vn_open_flags=, cred=0xffffff0073e09400, fp=0xffffff0002c682d0) at /usr/src/sys/kern/vfs_vnops.c:192 #26 0xffffffff804a161a in kern_openat (td=0xffffff007367b470, fd=-100, path=0x18074e069
, pathseg=UIO_USERSPACE, flags=1, mode=) at /usr/src/sys/kern/vfs_syscalls.c:1077 #27 0xffffffff805db824 in amd64_syscall (td=0xffffff007367b470, traced=0) at subr_syscall.c:114 #28 0xffffffff805c2e9c in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #29 0x00000001807359fc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 11 #11 0xffffffff803e74ad in __lockmgr_args (lk=0xffffff0073df2270, flags=0, ilk=0xffffff0073df2298, wmesg=, pri=982528, timo=1166294704, file=0xffffffff80d1faf8 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c", line=984) at /usr/src/sys/kern/kern_lock.c:1194 1194 panic("%s: unknown lockmgr request 0x%x\n", __func__, op); (kgdb) info loc _i = class = (struct lock_class *) 0x0 iwmesg = 0xffffffff80d2d91c "zfs" tid = 0 v = x = op = 0 realexslp = error = ipri = 80 itimo = 51 queue = wakeup_swapper = __func__ = "__lockmgr_args" (kgdb) list 1189 } 1190 break; 1191 default: 1192 if (flags & LK_INTERLOCK) 1193 class->lc_unlock(ilk); 1194 panic("%s: unknown lockmgr request 0x%x\n", __func__, op); 1195 } 1196 1197 if (flags & LK_INTERLOCK) 1198 class->lc_unlock(ilk); If you like I can give more info from the dumps. >> kern/180060 > I will try to look into this issue. Would be fine, maybe you like also to look at http://lists.freebsd.org/pipermail/freebsd-fs/2013-August/018008.html Regards -- Andreas Longwitz