From owner-freebsd-fs@FreeBSD.ORG Sun Apr 5 14:23:54 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ECCFA04 for ; Sun, 5 Apr 2015 14:23:54 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE9C17C for ; Sun, 5 Apr 2015 14:23:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Da2rC/rfFP1rDuwoEezMASYct1T30kGXfj73/9Le820=; b=eY0fdWBL2QTF1Eyszcj2PvZWcR/lTdmY1B/b/InRpSo6dpg5+ygCyv9miykLbNC5CeN/x8GqOUmW0b7WSnVvFEQdTZFUGgjupj3JMNTcqcrAJ8daIfQOLNDQPC3/zNyvJMawHSadv3LUOd4ajXPZGpfK4TwdZTbxYkVcjeTBQKc=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:36308 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YelSp-0003ZG-I1 for freebsd-fs@freebsd.org; Sun, 05 Apr 2015 09:23:53 -0500 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 05 Apr 2015 09:23:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 05 Apr 2015 09:23:51 -0500 From: Larry Rosenman To: Freebsd fs Subject: Swap usage with ZFS Message-ID: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:23:54 -0000 I have a -HEAD (11-CURRENT) box that has 64G of memory, but very little load. The ZFS ARC grows to eat most of it, but I see around 200M in use in SWAP. This was under control in 10.x. I'm wondering what information y'all need to help diagnose why. borg.lerctr.org /home/ler $ uname -aKU FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #32 r281050: Fri Apr 3 16:41:13 CDT 2015 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 1100067 1100067 borg.lerctr.org /home/ler $ borg.lerctr.org /home/ler $ top last pid: 26313; load averages: 6.92, 6.79, 6.83 up 1+16:26:05 09:23:13 80 processes: 4 running, 76 sleeping CPU: 0.0% user, 46.9% nice, 0.3% system, 0.0% interrupt, 52.8% idle Mem: 281M Active, 539M Inact, 59G Wired, 18M Cache, 8128K Buf, 1241M Free ARC: 55G Total, 42G MFU, 9766M MRU, 1044K Anon, 568M Header, 3437M Other Swap: 128G Total, 205M Used, 128G Free -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-fs@FreeBSD.ORG Sun Apr 5 14:32:39 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F31BAD0 for ; Sun, 5 Apr 2015 14:32:39 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCE1224B for ; Sun, 5 Apr 2015 14:32:38 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id t35EWUhG079735 for ; Sun, 5 Apr 2015 09:32:30 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sun Apr 5 09:32:30 2015 Message-ID: <5521475B.4010703@denninger.net> Date: Sun, 05 Apr 2015 09:31:55 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Swap usage with ZFS References: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> In-Reply-To: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010508090006040107090403" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:32:39 -0000 This is a cryptographically signed message in MIME format. --------------ms010508090006040107090403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 4/5/2015 09:23, Larry Rosenman wrote: > I have a -HEAD (11-CURRENT) box that has 64G of memory, but very=20 > little load. > > The ZFS ARC grows to eat most of it, but I see around 200M in use in=20 > SWAP. This was under control > in 10.x. > > I'm wondering what information y'all need to help diagnose why. > > borg.lerctr.org /home/ler $ uname -aKU > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #32 r281050: = > Fri Apr 3 16:41:13 CDT 2015=20 > root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 1100067 1100067= > borg.lerctr.org /home/ler $ > > > borg.lerctr.org /home/ler $ top > last pid: 26313; load averages: 6.92, 6.79, 6.83 up 1+16:26:05 = > 09:23:13 > 80 processes: 4 running, 76 sleeping > CPU: 0.0% user, 46.9% nice, 0.3% system, 0.0% interrupt, 52.8% idle > Mem: 281M Active, 539M Inact, 59G Wired, 18M Cache, 8128K Buf, 1241M Fr= ee > ARC: 55G Total, 42G MFU, 9766M MRU, 1044K Anon, 568M Header, 3437M Othe= r > Swap: 128G Total, 205M Used, 128G Free > > This is consistent with how the VM system is expected to behave absent=20 the patches I developed for 10-STABLE (and continue to maintain for same.= ) In short what is going on is that ZFS (absent those patches) will allow=20 ARC to grow until the pager not only wakes up and starts scavenging=20 cache pages but actively starts evicting working set to the page file. =20 It will then pare down the ARC but at that point you have paged out=20 working set process memory. I argue this is flat-out wrong as discarding ARC instead *possibly*=20 implicates one disk I/O (to retrieve said data) if the cached data is=20 later needed but a page-out of RSS *always* implicates one disk I/O (to=20 page out said data) and *possibly* implicates two disk operations (if=20 the RSS pages are later executed.) Therefore it is /*never*/ the correct decision to favor paging out=20 resident processes rather than discarding disk cache. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 I do not know if this will apply against -HEAD. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms010508090006040107090403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGWTCC BlUwggQ9oAMCAQICARowDQYJKoZIhvcNAQELBQAwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEg U3lzdGVtcyBMTEMgQ0EwHhcNMTUwMzI1MTMxMDIwWhcNMjAwMzIzMTMxMDIwWjBTMQswCQYD VQQGEwJVUzEQMA4GA1UECBMHRmxvcmlkYTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEX MBUGA1UEAxMOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQCmk+jIznE3HgHbh4JU2s86dKGDs4f3ZdED6vCQx9+LnJl7GgT2aAUAARqNnH5dDuC4w/4h K1qb8sXu3yYWlXLLs+vw3oLnx284o0kSZZs/FQ9W90gVTeZ1iTybscN7iXkaf83g1jueBNby n4v1bJEwX/xe94NW0IwBPluOzzXVIMskaZWhqGLtSaiSo4PYUnYMXPRNG7NAWQ2VAZXJkIM2 AM0B3LfyTyZw+NDNJMMQLZBDqS5vHuS78UODXpyyliSsBgaa04KVRsrcz6S2aYxk9ZjU3yD2 JJ7ezlKnZ4j/pc+16rv5fPfJWZAmG3v3kMiMzoDMS+d6CsSYxyQYHDGt+2If0cGpFv3D7Xr6 jxHouLKtipMQ/pPd+T+lugdEj3JfRu0nIM38j+dQh1N+wdiCEgFo0XuPIWW9g7VGwk8n29KR LAT10QZH9ADYbQqwXeXe9xWXjMAXHm6NTXyxpYyuNAV5zwsT5N4fZRwxKn828XZAKLLyeDGg 2lSBKdnT3osk668Yi5hclZH3UX8JikOWzixQ7T1/lWYGAGbElwFUC3xKRv/TI8E6ZYYYbQVN 3JXLKNIfQ7I9fpqrQeMVe03zXGGsXcE1krA8M4VP1ipoDfGD0/Pt8k2mTLUc4PY9eKZJfVlY WWJ/RHPp+N+MFD1sKirYrDvCHaeWyyLDx2dcIwIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJ YIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFCMvNiXRuCcqulq6cUWK8SNwo7vhMB8G A1UdIwQYMBaAFCRxm52Fffzd3b2wypKUA6H60201MB0GA1UdEQQWMBSBEmthcmxAZGVubmlu Z2VyLm5ldDA4BglghkgBhvhCAQMEKxYpaHR0cHM6Ly9jdWRhc3lzdGVtcy5uZXQ6MTE0NDMv cmV2b2tlZC5jcmwwDQYJKoZIhvcNAQELBQADggIBAHAUwvyHIJw3LTLqpF4apSzuIm5sBqyH rYg1mk7vPkgPFSrsr3AmmtR2iifN7fgAG6NzrL7SddhTiIMbW7mL32Tuklx9sUXM6iEyuiL/ /TRZ95ob7BtM58x2R6y2p00OKOfUCmjyqWy/pAjUAk7c5m9uLr6rVQUj0lGuvCMZEo1lnG6S +EUZ1Mi2mz9HrZBR2GhNPb5UgNVsX91So+uEF+1pRg1mQO6KvX4E84MOPe++qM76o+NvlEIw IU9tYHjSgjqWrqUQgEesMjahWEblfT+XPvPwy9WtICESMQGdGzVgDBgwoFrFnS2GyKlve0rj LKBs5ZtMrsASnbSvWX5uYy6Fb0Gv/F2neStmAyxL6Kupu4D28QpbtG1nxl3pN3SyQiUfXvVm LC3JvS6r6eQsG8Q/6fxCvUNQg8AjvVSMYTspAm3O0rihPQWX1GTAWS9fIxYlo5Y3NY8SpTXD 7RU5QzbQnK/mMJkuuysQeFAmK58El/7GcUy4zt2akuTBD0YroH2FHjfNUJej0lwHgxkNU3zG quKn+Llw1/u/+cncRiVPVatbqhUtXk2a0Y6OKrcAmFwzXlAi//hzofp3Sd1sWW0SUKQIizl7 xSxyu0cnYbxiBLDn3bmCTYCowUHLm6vBDc+3l6jxOM5fWOdJwq4hakYmrGonoI0pRTG732P9 Jf5/MYIE4zCCBN8CAQEwgZYwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIw EAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMT E0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMg Q0ECARowCQYFKw4DAhoFAKCCAiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTUwNDA1MTQzMTU1WjAjBgkqhkiG9w0BCQQxFgQU06/GUko57fgToOiXyPHA 9eUrpt0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBpwYJKwYBBAGCNxAEMYGZMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEaMIGpBgsqhkiG9w0BCRACCzGBmaCBljCBkDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBT eXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJ ARYTQ3VkYSBTeXN0ZW1zIExMQyBDQQIBGjANBgkqhkiG9w0BAQEFAASCAgAK83IfLMfTwi9J OgdCYo7j7exqnc73JhwIlUnRk8CBLpOSOgLv5nKfZcwHQ1dnKI5enKZHm6rWViUkd3T3jVHa cHz8KJozhGOJodS9giAR0X8nA446f46/r7sv088QFJp/lUK67o0x8zHtNUJ0pUcVtmZnRZEZ Yyb0drmMy3TlOXWx/xGbrHwHzeegdQiEsGfqm0ACdIKe81DXD2eyRnEFouu6K5XtphiqIi9c uGbjprwdtSMJc53MGslKH4CbHk6TD3U29cZy2PcFjai/vBOawym4SW/lis5YtMhNXqUS+W3W OVc8qZaL5QPyLbFy7rjMC8C0Do+VeqmGlrRoVgd761KawbZnbl8cSWn3gs3UUHQ4THlWmdl/ oZWNBGuJXOkwx90dX/lG/bAYz6OfmhT6CyOWA/KfYGeRzsMAC5i5YeCpMhNBVw0flhpFiQBt 8RwhoDnV5ho9zT8XAgxS9AKsRpljJzfa05sGESATPnJWoizcaD+csomhInSQL/iAZDdcnbUl jERqMVVuseeZlHrLzd/ijg2SLsTDnEvOaFLYVkKDZf02E4xDfilZbbza5D6JAbYL0kXbYCEl /LZnR47rhgx900wAEUwnNcGAdNxrDlHpYsbGyJVLtqQ/XLmMICSw1CC78YAaEGjcjm4++YNz s0V3GEig/Cy+/OmrHLizCwAAAAAAAA== --------------ms010508090006040107090403-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 5 14:40:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53932B94 for ; Sun, 5 Apr 2015 14:40:41 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12949270 for ; Sun, 5 Apr 2015 14:40:40 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Yelis-0005AS-8c for freebsd-fs@freebsd.org; Sun, 05 Apr 2015 16:40:32 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: ndmp server. References: Date: Sun, 05 Apr 2015 16:40:24 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00, URIBL_BLOCKED autolearn=disabled version=3.3.1 X-Scan-Signature: 12f61b0c8dc8dcc8c992b8e1fde77987 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:40:41 -0000 On Sat, 04 Apr 2015 19:42:34 +0200, Marcelo Araujo wrote: > Hi guys, > > I saw at wiki[1], there is a project idea to have an NDMP data server. > > I have something workable based on Illumos implementation[2], it doesn't > implement all features that Illumos version has. Also the protocol > version > is 4 and not the new one 5. I can do a backup/restore between two FreeBSD > machines via NDMP with success. Also is necessary port or create another > tools such like this one on Illumos[3], I have a very simple python > script > to setup it now. > > It needs more polishment on the code and a man page, as well as maybe the > ndmpadm or something based on it. I'm wondering, if someone still has > interesting on it, because with zfs send/recv I don't see too much > utility > for NDMP. Even a rsync can do the job. > > If you guys think, that have NDMP, at least the server on FreeBSD would > be > a good idea, let me know, and I can put some effort on it and I can > provide > a patch soon for tests. > > [1] https://wiki.freebsd.org/IdeasPage#NDMP_data_server > [2] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpd > [3] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpadm > > > Best Regards, I think this is very useful as a port. It seems an easy way to copy data to/from a NetApp fileserver also. Ronald From owner-freebsd-fs@FreeBSD.ORG Sun Apr 5 18:53:44 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D7FDA29 for ; Sun, 5 Apr 2015 18:53:44 +0000 (UTC) Received: from asmtp.lnxw.com (asmtp.lnxw.com [207.21.185.2]) by mx1.freebsd.org (Postfix) with ESMTP id 23169F11 for ; Sun, 5 Apr 2015 18:53:43 +0000 (UTC) Received: from [192.168.1.75] (75-51-148-11.lightspeed.snjsca.sbcglobal.net [75.51.148.11]) (authenticated bits=0) by asmtp.lnxw.com (8.13.8/8.13.8) with ESMTP id t35Ip2Z8012798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Apr 2015 11:51:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Swap usage with ZFS From: Ed Mooring X-Mailer: iPhone Mail (12B466) In-Reply-To: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> Date: Sun, 5 Apr 2015 11:51:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> To: Larry Rosenman Cc: Freebsd fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 18:53:44 -0000 Testing Sent from one of my iThingies > On Apr 5, 2015, at 7:23 AM, Larry Rosenman wrote: >=20 > I have a -HEAD (11-CURRENT) box that has 64G of memory, but very little lo= ad. >=20 > The ZFS ARC grows to eat most of it, but I see around 200M in use in SWAP.= This was under control > in 10.x. >=20 > I'm wondering what information y'all need to help diagnose why. >=20 > borg.lerctr.org /home/ler $ uname -aKU > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #32 r281050: Fri= Apr 3 16:41:13 CDT 2015 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-L= ER amd64 1100067 1100067 > borg.lerctr.org /home/ler $ >=20 >=20 > borg.lerctr.org /home/ler $ top > last pid: 26313; load averages: 6.92, 6.79, 6.83 up 1+16:26:05 09:= 23:13 > 80 processes: 4 running, 76 sleeping > CPU: 0.0% user, 46.9% nice, 0.3% system, 0.0% interrupt, 52.8% idle > Mem: 281M Active, 539M Inact, 59G Wired, 18M Cache, 8128K Buf, 1241M Free > ARC: 55G Total, 42G MFU, 9766M MRU, 1044K Anon, 568M Header, 3437M Other > Swap: 128G Total, 205M Used, 128G Free >=20 >=20 > --=20 > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 >=20 > _______________________________________________ > 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 Sun Apr 5 21:00:10 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFDCFA47 for ; Sun, 5 Apr 2015 21:00:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6396CC9 for ; Sun, 5 Apr 2015 21:00:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t35L0A7m070905 for ; Sun, 5 Apr 2015 21:00:10 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201504052100.t35L0A7m070905@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 05 Apr 2015 21:00:10 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 21:00:11 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 3 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 01:09:53 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24E755B7 for ; Mon, 6 Apr 2015 01:09:53 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8535E877 for ; Mon, 6 Apr 2015 01:09:51 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 47F40620AE; Mon, 6 Apr 2015 11:09:46 +1000 (EST) Message-ID: <5521DCD7.1080008@herveybayaustralia.com.au> Date: Mon, 06 Apr 2015 11:09:43 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kirk McKusick Subject: Re: Delete a directory, crash the system References: <201503291946.t2TJkUMv054849@chez.mckusick.com> In-Reply-To: <201503291946.t2TJkUMv054849@chez.mckusick.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 01:09:53 -0000 On 30/03/2015 05:46, Kirk McKusick wrote: >> Date: Sun, 29 Mar 2015 08:24:24 +1000 >> From: Da Rock >> To: Kirk McKusick >> CC: Benjamin Kaduk , freebsd-fs@freebsd.org >> Subject: Re: Delete a directory, crash the system >> >> On 03/29/15 08:02, Kirk McKusick wrote: >> >>> SU without journaling will maintain consistency. It is just that you >>> will need to run fsck after a crash. That is the way FFS has been since >>> it was written in 1982 and will allow you to recover from media errors >>> which it appears your system is suffering from. SU+J is just a faster >>> way of restarting but only works when you do not have media errors. >> I guess the point I'm driving at is that on a server this may be >> an ok solution, but if you have workstations/desktops with users >> who don't know how to do this properly, that is why the journalling >> is an important feature. So its not just about faster restarts, but >> a simple reboot/boot and everything is basically ok for them. > Absent media errors, SU + fsck run at boot will always work without > any intervention on the part of the users. When you run with SU, the > default is to run fsck at every boot, so neither users nor administrators > need to do anything other than hit the power-on button. > >> If there is any issue a system squawk at the sysadmin will then >> allow them to come in at some point to run a proper check. But in >> this case, we have a system which effectively crashes if there is >> a problem. >> >> So thats why I mentioned the only other journal type fs' in freebsd, >> because in this scenario a journal is required and it appears these >> are the only alternative that don't create such a catastrophic effect. > No journaling on any system can recover from media errors. Neither > type on FreeBSD nor the one on Linux's ext4. The only way to recover > from media errors is to have redundant metadata in the filesystem. > ZFS has at least double and optionally triplely redundant metadata. > If you want a system that will cleanly recover without any system > administrator intervention in the face of media errors, that is what > you should run. As you note, it is more resource hungry than FFS, but > based on your requirement for no intervention in the face of media > errors, that is what I would recommend. As long as you run on a 64-bit > processor and have at least 4Gb of memory, it should have entirely > reasonable performance. > >> Having made my point, what could be done about it - and what can I >> do to help? Would drive details provide data required to pick up >> the solution? > Short of adding metadata redundancy to FFS, there is no solution. I > have actively avoided putting such features into FFS as FreeBSD already > has ZFS that does that (and many other things). My goal is to have a > highly performant filesystem with minimal resource requirements. It by > definition has limits, and administrator intervention in the face of > media errors is one of them. > > Kirk McKusick I think I'm getting it, but I'm considering a different angle. With just SU if the computer goes off for whatever reason it insists on single-user mode (unless this has changed since); with SU+J it runs a quick check and boots normally. Hence better for less literate users. I think I will stick with SU+J and fix as necessary though. Thanks for the help too Kirk. Cheers From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 01:19:33 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 978A97CE for ; Mon, 6 Apr 2015 01:19:33 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FFDF93C for ; Mon, 6 Apr 2015 01:19:33 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 248EB620B3 for ; Mon, 6 Apr 2015 11:19:29 +1000 (EST) Message-ID: <5521DF1E.8000703@herveybayaustralia.com.au> Date: Mon, 06 Apr 2015 11:19:26 +1000 From: R Skinner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: fuse user mounting fails Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 01:19:33 -0000 I'm just starting (regular) use with fuse, and this is using the exfat fuse module. I tried with ntfs-3g on occasion with similar results, but now I need this to work a whole lot better. As root I can get fuse modules to mount a file system with no issue; albeit I have to set mode and owner so that is usable for my purposes. I want to set things so that as a normal user (so not just myself) can mount these. Currently I get: FUSE exfat 1.0.1 mount_fusefs: /dev/fuse on /usr/home/admin/mnt: Operation not permitted fuse: failed to mount file system: No such file or directory Permissions are set for operator group rw on /dev fuse, da*, usb*, and so on... you get my drift - other cards all work if just msdosfs using usual mount ops. Just fuse is an issue. Sysctl vfs.usermount is set to 1. I've tried truss, truss -f but I can't make head or tail of it. I'm not exactly any kind of expert on fuse, is there any quick fixes I'm missing? What debug do I need to do? Most searches mention permissions issues and sysctl, can't find anything that actually helps. This on 10.0 atm as well, I have a 10.1 I can test on if required but would rather not given current operations. Cheers From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 04:10:36 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A19F9314 for ; Mon, 6 Apr 2015 04:10:36 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8240BBE6 for ; Mon, 6 Apr 2015 04:10:36 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id t364AWcW050811; Sun, 5 Apr 2015 21:10:33 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201504060410.t364AWcW050811@chez.mckusick.com> To: Da Rock Subject: Re: Delete a directory, crash the system In-reply-to: <5521DCD7.1080008@herveybayaustralia.com.au> Date: Sun, 05 Apr 2015 21:10:32 -0700 From: Kirk McKusick Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 04:10:36 -0000 > Date: Mon, 06 Apr 2015 11:09:43 +1000 > From: Da Rock > To: Kirk McKusick > CC: Benjamin Kaduk , freebsd-fs@freebsd.org > Subject: Re: Delete a directory, crash the system > > On 30/03/2015 05:46, Kirk McKusick wrote: > >> Short of adding metadata redundancy to FFS, there is no solution. I >> have actively avoided putting such features into FFS as FreeBSD already >> has ZFS that does that (and many other things). My goal is to have a >> highly performant filesystem with minimal resource requirements. It by >> definition has limits, and administrator intervention in the face of >> media errors is one of them. >> >> Kirk McKusick > > I think I'm getting it, but I'm considering a different angle. With > just SU if the computer goes off for whatever reason it insists on > single-user mode (unless this has changed since); with SU+J it runs > a quick check and boots normally. Hence better for less literate users. > > I think I will stick with SU+J and fix as necessary though. Thanks > for the help too Kirk. > > Cheers Both SU and SU+J reqiure single-user mode while they recover. The key difference is that SU+J typically requires it for under a second while SU can require it for minutes to hours depending on how long it takes to run fsck (e.g., how big the filesystems are). So, to the end user, SU+J is much less impactful since it appears as just a blip as the compter reboots, while the delay of running fsck can seem intermitable. Hence the default of running with SU+J. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 06:53:56 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB8FFD32 for ; Mon, 6 Apr 2015 06:53:56 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 5229AC25 for ; Mon, 6 Apr 2015 06:53:55 +0000 (UTC) Received: from ppp118-210-45-229.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.45.229]) by ipmail05.adl6.internode.on.net with ESMTP; 06 Apr 2015 16:18:45 +0930 Message-ID: <55222C4C.4090901@ShaneWare.Biz> Date: Mon, 06 Apr 2015 16:18:44 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Karl Denninger , freebsd-fs@freebsd.org Subject: Re: Swap usage with ZFS References: <880944c05bb859ca0fc97b2d8606fe29@thebighonker.lerctr.org> <5521475B.4010703@denninger.net> In-Reply-To: <5521475B.4010703@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 06:53:56 -0000 On 06/04/2015 00:01, Karl Denninger wrote: > On 4/5/2015 09:23, Larry Rosenman wrote: >> I have a -HEAD (11-CURRENT) box that has 64G of memory, but very >> little load. >> >> The ZFS ARC grows to eat most of it, but I see around 200M in use in >> SWAP. This was under control >> in 10.x. >> >> I'm wondering what information y'all need to help diagnose why. >> >> borg.lerctr.org /home/ler $ uname -aKU >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #32 r281050: >> Fri Apr 3 16:41:13 CDT 2015 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 1100067 1100067 >> borg.lerctr.org /home/ler $ >> >> >> borg.lerctr.org /home/ler $ top >> last pid: 26313; load averages: 6.92, 6.79, 6.83 up 1+16:26:05 >> 09:23:13 >> 80 processes: 4 running, 76 sleeping >> CPU: 0.0% user, 46.9% nice, 0.3% system, 0.0% interrupt, 52.8% idle >> Mem: 281M Active, 539M Inact, 59G Wired, 18M Cache, 8128K Buf, 1241M Free >> ARC: 55G Total, 42G MFU, 9766M MRU, 1044K Anon, 568M Header, 3437M Other >> Swap: 128G Total, 205M Used, 128G Free >> >> > This is consistent with how the VM system is expected to behave absent > the patches I developed for 10-STABLE (and continue to maintain for same.) > > In short what is going on is that ZFS (absent those patches) will allow > ARC to grow until the pager not only wakes up and starts scavenging > cache pages but actively starts evicting working set to the page file. > It will then pare down the ARC but at that point you have paged out > working set process memory. > > I argue this is flat-out wrong as discarding ARC instead *possibly* > implicates one disk I/O (to retrieve said data) if the cached data is > later needed but a page-out of RSS *always* implicates one disk I/O (to > page out said data) and *possibly* implicates two disk operations (if > the RSS pages are later executed.) > > Therefore it is /*never*/ the correct decision to favor paging out > resident processes rather than discarding disk cache. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 > > I do not know if this will apply against -HEAD. > Sounds like it's related to one of my issues. On a machine with 8G getting 7G wired is a problem. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 Is there any chance that having vfs.zfs.arc_free_target smaller than vm.v_free_target plays a part in this? or are those free targets unrelated? -- FreeBSD - the place to B...Storing Data Shane Ambler From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 13:21:59 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B34B703 for ; Mon, 6 Apr 2015 13:21:59 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 807A6848 for ; Mon, 6 Apr 2015 13:21:59 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id 96FFC1C9CB8; Mon, 6 Apr 2015 09:21:52 -0400 (EDT) Received: from [127.0.0.1] (vnat004.nandomedia.com [166.108.31.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 4758A1C9CB5; Mon, 6 Apr 2015 09:21:51 -0400 (EDT) Message-ID: <5522886E.2080504@mail.lifanov.com> Date: Mon, 06 Apr 2015 09:21:50 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ndmp server. References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marcelo Araujo X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 13:21:59 -0000 On 04/05/15 08:00, freebsd-fs-request@freebsd.org wrote: > > Hi guys, > > I saw at wiki[1], there is a project idea to have an NDMP data server. > > I have something workable based on Illumos implementation[2], it doesn't > implement all features that Illumos version has. Also the protocol version > is 4 and not the new one 5. I can do a backup/restore between two FreeBSD > machines via NDMP with success. Also is necessary port or create another > tools such like this one on Illumos[3], I have a very simple python script > to setup it now. > > It needs more polishment on the code and a man page, as well as maybe the > ndmpadm or something based on it. I'm wondering, if someone still has > interesting on it, because with zfs send/recv I don't see too much utility > for NDMP. Even a rsync can do the job. > > If you guys think, that have NDMP, at least the server on FreeBSD would be > a good idea, let me know, and I can put some effort on it and I can provide > a patch soon for tests. > > [1] https://wiki.freebsd.org/IdeasPage#NDMP_data_server > [2] https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpd > [3] https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpadm > > > Best Regards, > Please do! There is a sore lack of options to restore an NDMP backup on an open source system. This is also the only vendor-neutral interface to get a consistent backup quickly from Ontap, Fishworks, or other enterprise filers. I would personally find both the server and the client very, very useful. - Nikolai Lifanov From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 14:08:45 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C395360 for ; Mon, 6 Apr 2015 14:08:45 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DCEED15 for ; Mon, 6 Apr 2015 14:08:45 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so20089916igb.1 for ; Mon, 06 Apr 2015 07:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FuX7v/A1KIk+m9z0PmwNlc5K2F8vePLdViU1+mUE08s=; b=dsydp+m9Z8LtCAoJi6yBnp8CjXPCUEfBcPntWyWuWRJk234JHe7SDbAAiYYblKUJvb 3y2n9oxDQP/nWDvY9+8PkyeSYxXvjnpOr4OghGDsMtQGXO8vIv2Sl+ln9u60mf5Bu+Xf ZqbwrzMKF+8iK+G48zgyxzc86bB3VqN3FSrXHEvN5Fs3M10vuAdGjaXRWMKougOf46xP +d0Tqlyar8NIRzspVkv1rwsZ3IYA/PREKz1vQfaLCcwtIEsKHOD4vDReZ6B1TCByKDiS f/qf2yZOnEy/K0mhOMgqXrvafB5vNE5hOiRxrZyrwlmcNXSTmtwnDtwtF0PvYWlH1gvT 30RA== MIME-Version: 1.0 X-Received: by 10.50.43.162 with SMTP id x2mr46947387igl.46.1428329324621; Mon, 06 Apr 2015 07:08:44 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 6 Apr 2015 07:08:44 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 6 Apr 2015 07:08:44 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <5522886E.2080504@mail.lifanov.com> References: <5522886E.2080504@mail.lifanov.com> Date: Mon, 6 Apr 2015 22:08:44 +0800 Message-ID: Subject: Re: ndmp server. From: Marcelo Araujo To: Nikolai Lifanov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 14:08:45 -0000 That is nice to heard, I really would need test, because I'm using ndmpcopy only to test it. But I still have work to do, to really have something ready for review. Maybe 2 or 3 weeks to finish it. Best, On Apr 6, 2015 9:21 PM, "Nikolai Lifanov" wrote: > On 04/05/15 08:00, freebsd-fs-request@freebsd.org wrote: > > > > Hi guys, > > > > I saw at wiki[1], there is a project idea to have an NDMP data server. > > > > I have something workable based on Illumos implementation[2], it doesn't > > implement all features that Illumos version has. Also the protocol > version > > is 4 and not the new one 5. I can do a backup/restore between two FreeBSD > > machines via NDMP with success. Also is necessary port or create another > > tools such like this one on Illumos[3], I have a very simple python > script > > to setup it now. > > > > It needs more polishment on the code and a man page, as well as maybe the > > ndmpadm or something based on it. I'm wondering, if someone still has > > interesting on it, because with zfs send/recv I don't see too much > utility > > for NDMP. Even a rsync can do the job. > > > > If you guys think, that have NDMP, at least the server on FreeBSD would > be > > a good idea, let me know, and I can put some effort on it and I can > provide > > a patch soon for tests. > > > > [1] https://wiki.freebsd.org/IdeasPage#NDMP_data_server > > [2] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpd > > [3] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpadm > > > > > > Best Regards, > > > > Please do! There is a sore lack of options to restore an NDMP backup on > an open source system. This is also the only vendor-neutral interface to > get a consistent backup quickly from Ontap, Fishworks, or other > enterprise filers. > > I would personally find both the server and the client very, very useful. > > - Nikolai Lifanov > From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 14:10:46 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A0553EA; Mon, 6 Apr 2015 14:10:46 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F367D23; Mon, 6 Apr 2015 14:10:46 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id D30161C9CBB; Mon, 6 Apr 2015 10:10:45 -0400 (EDT) Received: from [127.0.0.1] (vnat004.nandomedia.com [166.108.31.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 5F35C1C9CB5; Mon, 6 Apr 2015 10:10:45 -0400 (EDT) Message-ID: <552293E4.9060109@mail.lifanov.com> Date: Mon, 06 Apr 2015 10:10:44 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: araujo@FreeBSD.org Subject: Re: ndmp server. References: <5522886E.2080504@mail.lifanov.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 14:10:46 -0000 I can test it with real enterprise storage hardware when it's ready. On 04/06/15 10:08, Marcelo Araujo wrote: > That is nice to heard, I really would need test, because I'm using > ndmpcopy only to test it. But I still have work to do, to really have > something ready for review. Maybe 2 or 3 weeks to finish it. > > Best, > > On Apr 6, 2015 9:21 PM, "Nikolai Lifanov" > wrote: > > On 04/05/15 08:00, freebsd-fs-request@freebsd.org > wrote: > > > > Hi guys, > > > > I saw at wiki[1], there is a project idea to have an NDMP data server. > > > > I have something workable based on Illumos implementation[2], it > doesn't > > implement all features that Illumos version has. Also the protocol > version > > is 4 and not the new one 5. I can do a backup/restore between two > FreeBSD > > machines via NDMP with success. Also is necessary port or create > another > > tools such like this one on Illumos[3], I have a very simple > python script > > to setup it now. > > > > It needs more polishment on the code and a man page, as well as > maybe the > > ndmpadm or something based on it. I'm wondering, if someone still has > > interesting on it, because with zfs send/recv I don't see too much > utility > > for NDMP. Even a rsync can do the job. > > > > If you guys think, that have NDMP, at least the server on FreeBSD > would be > > a good idea, let me know, and I can put some effort on it and I > can provide > > a patch soon for tests. > > > > [1] https://wiki.freebsd.org/IdeasPage#NDMP_data_server > > [2] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpd > > [3] > https://github.com/joyent/illumos-joyent/tree/master/usr/src/cmd/ndmpadm > > > > > > Best Regards, > > > > Please do! There is a sore lack of options to restore an NDMP backup on > an open source system. This is also the only vendor-neutral interface to > get a consistent backup quickly from Ontap, Fishworks, or other > enterprise filers. > > I would personally find both the server and the client very, very > useful. > > - Nikolai Lifanov > From owner-freebsd-fs@FreeBSD.ORG Mon Apr 6 16:05:09 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914B2858 for ; Mon, 6 Apr 2015 16:05:09 +0000 (UTC) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 600FCC44 for ; Mon, 6 Apr 2015 16:05:09 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 28FA3740 for ; Mon, 6 Apr 2015 12:04:58 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 06 Apr 2015 12:05:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=+m+yAplrSjU4UpO /aJyiFqdMT0o=; b=BLiUnpTXe2a7TaMU7aVSofyEw5lpiGxP5NG4mGRiz9/3hqV 0jxz2zZUzr8kU5jW159DU0MnFEJPnhZo3WuF816z2/zgh5ZuVhe/HSeZaLrg/IKW vkq00IKhiINu8ZYeN6rxEmbmr4WoGxgVgeAUxs/RUS7OXwRTwDKuHsXjOfUs= Received: by web3.nyi.internal (Postfix, from userid 99) id A20D710C1FB; Mon, 6 Apr 2015 12:05:01 -0400 (EDT) Message-Id: <1428336301.16948.249831965.53E2F0C9@webmail.messagingengine.com> X-Sasl-Enc: +DWn6zy6tyTYEkq58sPwRwRHInPCZBnPmjJTCIcfqyaZ 1428336301 From: Mark Felder To: R Skinner , freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-0b3c2300 In-Reply-To: <5521DF1E.8000703@herveybayaustralia.com.au> References: <5521DF1E.8000703@herveybayaustralia.com.au> Subject: Re: fuse user mounting fails Date: Mon, 06 Apr 2015 11:05:01 -0500 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:05:09 -0000 On Sun, Apr 5, 2015, at 20:19, R Skinner wrote: > I'm just starting (regular) use with fuse, and this is using the exfat > fuse module. I tried with ntfs-3g on occasion with similar results, but > now I need this to work a whole lot better. > > As root I can get fuse modules to mount a file system with no issue; > albeit I have to set mode and owner so that is usable for my purposes. > > I want to set things so that as a normal user (so not just myself) can > mount these. Currently I get: > > FUSE exfat 1.0.1 > mount_fusefs: /dev/fuse on /usr/home/admin/mnt: Operation not permitted > fuse: failed to mount file system: No such file or directory > > Permissions are set for operator group rw on /dev fuse, da*, usb*, and > so on... you get my drift - other cards all work if just msdosfs using > usual mount ops. Just fuse is an issue. Sysctl vfs.usermount is set to 1. > > I've tried truss, truss -f but I can't make head or tail of it. > > I'm not exactly any kind of expert on fuse, is there any quick fixes I'm > missing? What debug do I need to do? Most searches mention permissions > issues and sysctl, can't find anything that actually helps. This on 10.0 > atm as well, I have a 10.1 I can test on if required but would rather > not given current operations. > Try running this: sysctl vfs.usermount=1 And then try mounting as non-root user. If that is a satisfactory solution you can put "vfs.usermount=1" in /etc/sysctl.conf so it is set every boot. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 7 01:28:01 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E649301; Tue, 7 Apr 2015 01:28:01 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6FA633E; Tue, 7 Apr 2015 01:28:00 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 2880B620A2; Tue, 7 Apr 2015 11:27:51 +1000 (EST) Message-ID: <55233297.2050707@herveybayaustralia.com.au> Date: Tue, 07 Apr 2015 11:27:51 +1000 From: R Skinner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark Felder , freebsd-fs@freebsd.org Subject: Re: fuse user mounting fails References: <5521DF1E.8000703@herveybayaustralia.com.au> <1428336301.16948.249831965.53E2F0C9@webmail.messagingengine.com> In-Reply-To: <1428336301.16948.249831965.53E2F0C9@webmail.messagingengine.com> 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 01:28:01 -0000 On 04/07/15 02:05, Mark Felder wrote: > > On Sun, Apr 5, 2015, at 20:19, R Skinner wrote: >> I'm just starting (regular) use with fuse, and this is using the exfat >> fuse module. I tried with ntfs-3g on occasion with similar results, but >> now I need this to work a whole lot better. >> >> As root I can get fuse modules to mount a file system with no issue; >> albeit I have to set mode and owner so that is usable for my purposes. >> >> I want to set things so that as a normal user (so not just myself) can >> mount these. Currently I get: >> >> FUSE exfat 1.0.1 >> mount_fusefs: /dev/fuse on /usr/home/admin/mnt: Operation not permitted >> fuse: failed to mount file system: No such file or directory >> >> Permissions are set for operator group rw on /dev fuse, da*, usb*, and >> so on... you get my drift - other cards all work if just msdosfs using >> usual mount ops. Just fuse is an issue. Sysctl vfs.usermount is set to 1. >> >> I've tried truss, truss -f but I can't make head or tail of it. >> >> I'm not exactly any kind of expert on fuse, is there any quick fixes I'm >> missing? What debug do I need to do? Most searches mention permissions >> issues and sysctl, can't find anything that actually helps. This on 10.0 >> atm as well, I have a 10.1 I can test on if required but would rather >> not given current operations. >> > Try running this: > > sysctl vfs.usermount=1 > > > And then try mounting as non-root user. If that is a satisfactory > solution you can put "vfs.usermount=1" in /etc/sysctl.conf so it is set > every boot. As mentioned, that sysctl is actually set - I can mount other FAT devices just fine, any time fuse is in use it won't work though. Its a fuse specific issue that I haven't gotten around to looking into until now, I'll probably be forced to look into gvfs next... :) From owner-freebsd-fs@FreeBSD.ORG Tue Apr 7 06:37:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98CF190B; Tue, 7 Apr 2015 06:37:59 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FC968F7; Tue, 7 Apr 2015 06:37:59 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so68350120pac.1; Mon, 06 Apr 2015 23:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=9U8rlICfZ/9c7Gh2I50G0ofQlTcuOL955nj4G6fyJ8w=; b=AgL5xYsHCmqdtpLLKQ8fC98YnufuYm4uwUXbw/01lxw7eCsuoud7hpAlOASXbX3dF0 rhleHRuO9oRnlcb7aoMdtU8FRejHFvcz0jX2My6RFAEmvQmZErsyF0neN3BzvW0JJ45B PxgcEP9OpC8MOd6iZgQnKUB0fQxZzw0oYrIgun9zXDRCPIcatCU2f98wKdrd0A3ObGFA PGYi2lI1HqtdjrwxgTsUswR1eSNNx/6a8uzig0QE2thFcgEV1yTkrNEr4NuD8QnWMJsB v5ICZCL25E3CYTeL2+BzlSSFrrga6cB7IHrhxWVQZ5iU68r9hRRslh0gzlEGHUgcl20f quig== X-Received: by 10.70.131.76 with SMTP id ok12mr33435205pdb.155.1428388678675; Mon, 06 Apr 2015 23:37:58 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:578:9b2c:a252:4667? ([2601:8:ab80:7d6:578:9b2c:a252:4667]) by mx.google.com with ESMTPSA id pa6sm6883498pac.45.2015.04.06.23.37.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 23:37:58 -0700 (PDT) From: Garrett Cooper Content-Type: multipart/signed; boundary="Apple-Mail=_C5F0CD32-23D7-44BA-8C8E-E252FF9CCF4C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: FreeBSD/ZFS on 9.3-RELEASE chews up memory with "wide" directories when calling readdir, etc; causes trap 12 panics Date: Mon, 6 Apr 2015 23:37:56 -0700 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 06:37:59 -0000 --Apple-Mail=_C5F0CD32-23D7-44BA-8C8E-E252FF9CCF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Long story short, I had a lot of mail spooled up in /var/spool. = When I did ls /var/spool, ZFS chewed up almost all 12GB of my memory in = <10 mins (because there were enough files there) and the system = eventually panicked because [I assume that a memory allocation failed = and] a trap 12 panic was caught. I don=92t have the exact details, but = it should be relatively easy to repro (YMMV if you have a boatload of = RAM): repro_end=3D10000000000 for i in $(seq 1 $repro_end); do mktemp tmp.XXXXXXXXXXXX; done ls This might be ameliorated via r281026, but this change is only = available in CURRENT (so far), and I haven=92t tested it. Are there any comments about this scalability issue with = FreeBSD/ZFS? Thanks, --Apple-Mail=_C5F0CD32-23D7-44BA-8C8E-E252FF9CCF4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVI3tFAAoJEMZr5QU6S73eR6kH/A1XPCegxem49+98PdTl4NuY 95tQEbzANC8xbnOFueluyEk6/8/X0kIFvEwraQxJg9kPUuC1goWghzNVPp/iTXuv TOxv3jTUmg2GYP0nvkcP/0G7G/7QRthr59XYtZZQZZiw3XqjpnDLECJ37eGjAxyY QiQte9z7FnzUMAE/f+vPGTffwkEYh9+DcFwmoCfTAnS9vmt8UfyYbOyuPmP58Dyv OJkAa9WpIVUrGSlILnXi+H8A5S9BTLZb91g+pOsp1YTeXoE6X7v+JafoM6kHMZEM gV/xaHoJXeCecp1VDDt/yLXM6ZTu36GnuDBxVdtghLJPH1eRBQyOdEXJQUhEX3c= =nPfJ -----END PGP SIGNATURE----- --Apple-Mail=_C5F0CD32-23D7-44BA-8C8E-E252FF9CCF4C-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 7 08:05:52 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD064FD7 for ; Tue, 7 Apr 2015 08:05:52 +0000 (UTC) Received: from weblinux03.tecla.com.br (static.200.219.245.136.datacenter1.com.br [200.219.245.136]) by mx1.freebsd.org (Postfix) with ESMTP id 241CD3A5 for ; Tue, 7 Apr 2015 08:05:51 +0000 (UTC) Received: by weblinux03.tecla.com.br (Postfix, from userid 100) id 59251130427; Tue, 7 Apr 2015 04:42:58 -0300 (BRT) To: freebsd-fs@freebsd.org Subject: FREE, Notice to Appear X-PHP-Script: vimoso.com.br/post.php for 85.214.250.115 Date: Tue, 7 Apr 2015 04:42:58 -0300 From: "District Court" Reply-To: "District Court" Message-ID: <1d950c4e8238f8aa48d7e8d7d5fc2113@static.200.219.245.139.datacenter1.com.br> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 08:05:52 -0000 Dear Free, You have to appear in the Court on the April 15. You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date. Note: If you do not come, the case will be heard in your absence. You can find the Court Notice is in the attachment. Regards, Francisco Boone, District Clerk. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 7 13:59:39 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EADD46BE for ; Tue, 7 Apr 2015 13:59:39 +0000 (UTC) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAE74777 for ; Tue, 7 Apr 2015 13:59:39 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 5FA3575C for ; Tue, 7 Apr 2015 09:59:34 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 07 Apr 2015 09:59:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=pCFWZeIMhtOjJDI pHlyLCU8GRS0=; b=l8mMDuwyamZ/C9nc+HhJ51bxzwvu4HqObrl6GVQXOY0X6zu H2ndHSVpr5eh1IufBPmkuwcPM8XBwWn+7T2Fw+y5vANW4LZa/zDv2Q9EeD3spTV6 /kIMp8lZv5ZWEXjxkATahmIav0QphptWjPogLc5/wLXuCjlWKbp594EoElQo= Received: by web3.nyi.internal (Postfix, from userid 99) id 0CA7E10B44D; Tue, 7 Apr 2015 09:59:38 -0400 (EDT) Message-Id: <1428415177.904924.250256797.4D02E3A5@webmail.messagingengine.com> X-Sasl-Enc: w2/onlpU2BIgf63NkZi/ODO9hfn3VhJ+WnjFXcXSvORV 1428415177 From: Mark Felder To: R Skinner , freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-0b3c2300 Subject: Re: fuse user mounting fails Date: Tue, 07 Apr 2015 08:59:37 -0500 In-Reply-To: <55233297.2050707@herveybayaustralia.com.au> References: <5521DF1E.8000703@herveybayaustralia.com.au> <1428336301.16948.249831965.53E2F0C9@webmail.messagingengine.com> <55233297.2050707@herveybayaustralia.com.au> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:59:40 -0000 On Mon, Apr 6, 2015, at 20:27, R Skinner wrote: > > As mentioned, that sysctl is actually set - I can mount other FAT > devices just fine, any time fuse is in use it won't work though. > > Its a fuse specific issue that I haven't gotten around to looking into > until now, I'll probably be forced to look into gvfs next... :) I'm sorry, I somehow missed that you activated that sysctl. I suppose it might not work for fuse... You could always give sudo rights to the fuse mount command, I guess. I'm not sure what other options you might have. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 7 20:25:50 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DD9B982; Tue, 7 Apr 2015 20:25:50 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41F7AEEE; Tue, 7 Apr 2015 20:25:49 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id DAD8C620A5; Wed, 8 Apr 2015 06:25:43 +1000 (EST) Message-ID: <55243D46.5080202@herveybayaustralia.com.au> Date: Wed, 08 Apr 2015 06:25:42 +1000 From: R Skinner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark Felder , freebsd-fs@freebsd.org Subject: Re: fuse user mounting fails References: <5521DF1E.8000703@herveybayaustralia.com.au> <1428336301.16948.249831965.53E2F0C9@webmail.messagingengine.com> <55233297.2050707@herveybayaustralia.com.au> <1428415177.904924.250256797.4D02E3A5@webmail.messagingengine.com> In-Reply-To: <1428415177.904924.250256797.4D02E3A5@webmail.messagingengine.com> 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:25:50 -0000 On 04/07/15 23:59, Mark Felder wrote: > > On Mon, Apr 6, 2015, at 20:27, R Skinner wrote: >> As mentioned, that sysctl is actually set - I can mount other FAT >> devices just fine, any time fuse is in use it won't work though. >> >> Its a fuse specific issue that I haven't gotten around to looking into >> until now, I'll probably be forced to look into gvfs next... :) > I'm sorry, I somehow missed that you activated that sysctl. I suppose it > might not work for fuse... You could always give sudo rights to the fuse > mount command, I guess. I'm not sure what other options you might have. Not actually using sudo, but I thought fuse utilities were meant to work like mount? From what I've read as well through my searching, setuid won't work with fuse. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 8 05:49:25 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A644FD4; Wed, 8 Apr 2015 05:49:25 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47F70C4A; Wed, 8 Apr 2015 05:49:25 +0000 (UTC) Received: by iebrs15 with SMTP id rs15so65795804ieb.3; Tue, 07 Apr 2015 22:49:24 -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=9K+RY+DXlRLDtVWHQquUzdUyNmFntAff8DL0JaprQcQ=; b=FdoHFzxF+Nuo9g4Fa9mvQj/7av/8zIYoRTcvwL9FHayw+5EqJ5qKQuoIVHOQonHQ51 mRtkHpjAZaPL8EBLKFZS55qKpAzWl7Wx42DX2WEyAmfalTLmqK5dLWmnbqUI24YJ7hLN 5TXwcBsDv6UCJG4TXWZR1dPjt0AB1UJGU0ZHkpOt/A0z25D/6jC5+7BPdl8S+cRDRm1O datCMazYaceA+MX1EJ1e104IZtdN1Kjws8RWS59qjSdCyzRQOGmJTYIsP7bqbupo6e9a EKCt1w4t2z79OzB2Uwm4rIzWB+DmJYC99itEd5Ba8M66OM2Fowrh3nSEvUFNx2VC4TfG SvRg== MIME-Version: 1.0 X-Received: by 10.107.6.84 with SMTP id 81mr14332845iog.52.1428472164666; Tue, 07 Apr 2015 22:49:24 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Tue, 7 Apr 2015 22:49:24 -0700 (PDT) In-Reply-To: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> References: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> Date: Wed, 8 Apr 2015 01:49:24 -0400 Message-ID: Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: grarpamp To: "freebsd-hardware@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 05:49:25 -0000 The only 8T SATA options are: 8T for $675 ($84.38/T) 0F23267, 7.4W max (8k q1) 8T for $270 ($33.75/T) ST8000AS0002, 8.66W max (rand read) For TB/$ or TB/RU there is no comparison, particularly for "archive" uses. Going further: 6T for $250 ($41.67/T) 5T for $200 ($40.00/T) 4T for $140 ($35.00/T) 3T for $100 ($33.33/T) go any smaller and the dollar, RU, and watt all fail to yield. For other comparison: SSD: 1T SSD $350 ($350.00/T) Tape (excl drives and changers): 10T 3592JD $410 ($41.00/T) 2.5T LTO6 $23 ($17.20/T) 1.5T LTO5 $23 ($15.33/T) The DM drive seems priced reasonably given 8T is largest drive on market. Prices on same density always go down, storage density always goes up with a new price attached. SMR is the first real example of a "feature" drive. Want to guess where the 8T and 10T HA (performance mitigatable) drives will price out? usb-to-sata bridge not working... There are stories both ways, none of them really trustable. Doesn't matter now that the second batch of native SATA drives is out. The StorageReview tests were made with the drives in a NAS box. The tests have obvious caveats depending on your usage. A generic raid-1 rebuild is theory equivalent to a whole disk sequential dd. The drive spec says you will see avg 150MB/s (~15hr) for that. SR's NAS is obviously not doing a generic raid-1 rebuild there. The tech path is "drive managed" --> "host managed" --> "host aware", better performance mitigation on the right. Developers can get DM and HA drives from Seagate. My posts from Feb 26th and Mar 2nd have bunch of info links. In the links find statements like these: "ZAC and ZBC command sets cover both Host Aware (HA) and Host Managed (HM) devices. SMR drives are expected to saturate the HDD market over the coming years. Without this modification (ZBC command support), HM will NOT work with traditional filesystems. With this modification, HA will demonstrate performance and determinism -- as found in non-SMR drives -- in traditional & new applications." "Seagate manufactures and supports SMR Drive Managed (DM) and SMR Host Aware (HA) drives. Seagate does not currently manufacture SMR Host Managed (HM) drives. Seagate has 2 drives shipping that are SMR-DM. Seagate's new 8TB Archive HDD v2 drive is SMR-HA." Another link: http://events.linuxfoundation.org/events/vault http://events.linuxfoundation.org/sites/events/files/slides/SMR%20in%20Linux%20Systems%20-%20Vault.pdf Bottom line is that SMR and related tech is here to stay as the next step in bulk storage and cannot be ignored. http://ceph.com/ http://www.mkomo.com/cost-per-gigabyte-update From owner-freebsd-fs@FreeBSD.ORG Wed Apr 8 08:32:57 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4DE1BA9 for ; Wed, 8 Apr 2015 08:32:57 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE516C for ; Wed, 8 Apr 2015 08:32:57 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so32623601igb.1 for ; Wed, 08 Apr 2015 01:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mLSdsGPIBewzIJF9ETlTTYlTvgfO8UvsD0ziYg4MP9U=; b=c37Mo0BcC5yAHN3G4WjOjyZB9daIRo+60OtVpbiPQWaTollPdMpFJIBtZWaUIZX+Wk PvT4xaxk69QbZ9NxCk9J4t3sQusloDYOcybNHGKmxeMFykRCzYS0hbF1BufgSnshoE7h FIo1erA2+N1zE8i74jl7g5pfGZ2pG+p65hC+S02IZECw3Xuql80uv/IhtP8u3x+pwKe6 PhzhREgOr6hVc8XinMx733ILbT3uMEStQcrzflkMCF5L2+ZWFNn58MuL291cUbq3dzJf v3aJCRjtesKuJWuhBMXmC4tgKTVcmWglEBw7O9jeSrSJ7GsWZTy63OTMvvnIRaE4gVUQ BeDA== X-Received: by 10.50.29.110 with SMTP id j14mr10343176igh.4.1428481976620; Wed, 08 Apr 2015 01:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.71.205 with HTTP; Wed, 8 Apr 2015 01:32:34 -0700 (PDT) In-Reply-To: <5521DF1E.8000703@herveybayaustralia.com.au> References: <5521DF1E.8000703@herveybayaustralia.com.au> From: Konstantin Kulikov Date: Wed, 8 Apr 2015 11:32:34 +0300 Message-ID: Subject: Re: fuse user mounting fails To: R Skinner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 08:32:57 -0000 Hello. What command do you use to mount? You can't run ntfs-3g directly, instead use something like: % mount_fusefs /dev/da0 `which ntfs-3g` /dev/da0 $HOME/mnt See mount_fusefs(8) for details. Mounting ntfs-3g worked for me, but not simple-mtpfs and I didn't try exfat. On Mon, Apr 6, 2015 at 4:19 AM, R Skinner wrote: > I'm just starting (regular) use with fuse, and this is using the exfat fuse > module. I tried with ntfs-3g on occasion with similar results, but now I > need this to work a whole lot better. > > As root I can get fuse modules to mount a file system with no issue; albeit > I have to set mode and owner so that is usable for my purposes. > > I want to set things so that as a normal user (so not just myself) can mount > these. Currently I get: > > FUSE exfat 1.0.1 > mount_fusefs: /dev/fuse on /usr/home/admin/mnt: Operation not permitted > fuse: failed to mount file system: No such file or directory > > Permissions are set for operator group rw on /dev fuse, da*, usb*, and so > on... you get my drift - other cards all work if just msdosfs using usual > mount ops. Just fuse is an issue. Sysctl vfs.usermount is set to 1. > > I've tried truss, truss -f but I can't make head or tail of it. > > I'm not exactly any kind of expert on fuse, is there any quick fixes I'm > missing? What debug do I need to do? Most searches mention permissions > issues and sysctl, can't find anything that actually helps. This on 10.0 atm > as well, I have a 10.1 I can test on if required but would rather not given > current operations. > > Cheers > _______________________________________________ > 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 Wed Apr 8 16:15:16 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE3FEC59; Wed, 8 Apr 2015 16:15:16 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87B8BFBF; Wed, 8 Apr 2015 16:15:16 +0000 (UTC) Received: by obbfy7 with SMTP id fy7so145513121obb.2; Wed, 08 Apr 2015 09:15:15 -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:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TDpjwGGcPcobfZ+ZyWFBJotWSuBT7CMsjJdRtI/4voo=; b=aK1eTEYJ4eClhB6oXU1U4sAL2QfBBfByOaOShVy9RtSjIJxaTgSYs9e6zPkd9VoGCL YIVOyzabm2s2rHMLolTrqmHBLevSkTFMUpTeQqO3omKVHrZKDihyeLu5koJHqP7OL224 57hNQN2j0GWZQk/iUTDGUxKBUQ/qBr+tTik2G+lg9rrS5VrtGBNtbss32YAgHPFIbndH Pi/q5FiMgdVVUOyxQ6whDGTyvCovnUW0c+/B+yFtc5z2/LdUMcvZVDPTIIG8PjtfqXT/ 1Y/nQpk+PLxfrTY6Y/FskhvOq00bHarS76J9G/qBFDdpSPnhra87cIUWDY1gEh49bRkp 6wCQ== MIME-Version: 1.0 X-Received: by 10.60.44.241 with SMTP id h17mr6320055oem.71.1428509701489; Wed, 08 Apr 2015 09:15:01 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.215.7 with HTTP; Wed, 8 Apr 2015 09:15:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Apr 2015 10:15:01 -0600 X-Google-Sender-Auth: Y7K-IsxFppbXhZ-HG9L0ZMK3Dds Message-ID: Subject: Re: FreeBSD/ZFS on 9.3-RELEASE chews up memory with "wide" directories when calling readdir, etc; causes trap 12 panics From: Alan Somers To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:15:16 -0000 On Tue, Apr 7, 2015 at 12:37 AM, Garrett Cooper wro= te: > Hi, > Long story short, I had a lot of mail spooled up in /var/spool. W= hen I did ls /var/spool, ZFS chewed up almost all 12GB of my memory in <10 = mins (because there were enough files there) and the system eventually pani= cked because [I assume that a memory allocation failed and] a trap 12 panic= was caught. I don=E2=80=99t have the exact details, but it should be relat= ively easy to repro (YMMV if you have a boatload of RAM): > > repro_end=3D10000000000 > for i in $(seq 1 $repro_end); do mktemp tmp.XXXXXXXXXXXX; done > ls > > This might be ameliorated via r281026, but this change is only av= ailable in CURRENT (so far), and I haven=E2=80=99t tested it. > Are there any comments about this scalability issue with FreeBSD/= ZFS? > Thanks, I spent the last ~ 24 hours creating 58,567,635 empty files in one directory. I can ls it without crashing on a machine with 32 GB RAM. # /usr/bin/time -l ls /tmp/tmp | wc 1061.21 real 225.54 user 36.61 sys 9720268 maximum resident set size 28 average shared memory size 8 average unshared data size 128 average unshared stack size 2425013 page reclaims 0 page faults 0 swaps 108036 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 108004 voluntary context switches 2428 involuntary context switches 58567635 58567635 644243985 -Alan From owner-freebsd-fs@FreeBSD.ORG Wed Apr 8 16:25:07 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C1FF56 for ; Wed, 8 Apr 2015 16:25:07 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 08458173 for ; Wed, 8 Apr 2015 16:25:06 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t38GP1rY098155 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 8 Apr 2015 17:25:02 +0100 (BST) (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t38GP1rY098155 Authentication-Results: smtp.infracaninophile.co.uk/t38GP1rY098155; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <5525565D.9060901@freebsd.org> Date: Wed, 08 Apr 2015 17:25:01 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: FreeBSD specific content in zfs(8) man pages Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="68AR8CaK43pwGD5wi69ef4jLtQKxQTxO5" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:25:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --68AR8CaK43pwGD5wi69ef4jLtQKxQTxO5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I just spent an unproductive half hour or so fiddling about with 'zfs allow' in an attempt to write some backup scripts based on using zfs send / zfs receive as a non-root user. Eventually I discovered that "zfs allow username mount zroot/foo/bar" only works when 'sysctl vfs.usermount=3D1' is set. It would be handy if this was mentioned in zfs(8) However I seem to recall something about keeping ZFS related manpages in synch with upstream, so system-specific information isn't allowed? Is that the case? Otherwise I'll create a PR with a diff attached. Cheers, Matthew --68AR8CaK43pwGD5wi69ef4jLtQKxQTxO5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVJVZdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnWXwP/A5TM0fyuN8nYOy7fDi7Cgoz 8WpGNwo74b6dPV+LCGc0Ao00H2zr2APnQYLOo3jneht8utQAsXEPckqhSVcHcpLg 00c1esMDFBEhdx/QjV4W9LYITiTKPaBC6d1F6MsTy37k+k/mMhuXifac+dcMS7cb kaKfWZWD0fv7Yy+qPBk4d3H1jVEQ1yEJJQPY7xUXPcIuGyQBLqcnGWr3J9ma9B40 vnX/4bL+QWg4PeE1/iyWFktbN4ifap4DpkTJHyXXcSH0FOLFRhd6kijo2TRizqJz bVE6K8iIZarpcP0U8+EXR92d+6hYs2GtgjUvwRQktyGXJuc3pUsbXxoxndHZmPlr nREUHX4Ks7Ra2jqnNK99GK5Nrgp5AOxzsHeCwp6vYoChuBrPDwnZfDbq1EHNQ00s JHMJTggwRXU1J++qZKUtcubtaR+2np9ljIxG/uSD74ao2Y3OjHpKFqR9hfjQUdJ1 TuvSfs10FqhwJlql3XvibGDqnX98zKB/9qUFcpVmSx9J5ZOi1nV3xCjX9O4INZlX PQY+gVsl+BToi/y9vBWzZBBe24jH3fPo2qHEVDjqKneXCpQyC9xaSgYXeR3eHiku u73eZ1cm7HJAMG7OyEMyG309w4JZnaJYrvqoNZJRvrik3GSEaODkh7MTzYiiB8DN En85oNmtMw5JEQs43zKO =DbSO -----END PGP SIGNATURE----- --68AR8CaK43pwGD5wi69ef4jLtQKxQTxO5-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 8 17:22:55 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5C7258A; Wed, 8 Apr 2015 17:22:55 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 789CBBD6; Wed, 8 Apr 2015 17:22:55 +0000 (UTC) Received: by pddn5 with SMTP id n5so122075108pdd.2; Wed, 08 Apr 2015 10:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T68rGqi4L9K4jKHo1g20PvXd4bB5Mh/B/FgYnI7PDxM=; b=TjLoJW5GBjbW0rV0FSa2g8pzRG7n/2U5BT41VEU+sZHbwXmhGO7wxHRnAxxULA+96Y WvynTJ6H05hioskTmMop+6QT/He84Ho9ZkrCe4c9q2d0Y1pr9wWVskQBz18kgis7r8zh EukcpyF/j6QEuY4s9GIR8thzGv013SxFhTfgtzWXHd8YOd6vAqlM5vetP3EaPULli3Xb xIKW2JOYFnH+uP4i2Z8pzDeEft3qeaGAMvCeHDmN/bqfXw6EgCcFkIcmldR1AdLYFVlW YZBKFB3ihUE/O6CsM0RdKIzp7vyjFheoy7+xFSd2Uv1DkxSeEnuhlamdSUaqovkbSOik tfuQ== X-Received: by 10.68.102.228 with SMTP id fr4mr47217129pbb.87.1428513775143; Wed, 08 Apr 2015 10:22:55 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:489a:2140:1bdb:1a5? ([2601:8:ab80:7d6:489a:2140:1bdb:1a5]) by mx.google.com with ESMTPSA id xt9sm11661003pbc.14.2015.04.08.10.22.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 10:22:54 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_25C7EA9E-02FC-4071-AD0E-4238DBE008B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD/ZFS on 9.3-RELEASE chews up memory with "wide" directories when calling readdir, etc; causes trap 12 panics From: Garrett Cooper In-Reply-To: Date: Wed, 8 Apr 2015 10:22:54 -0700 Message-Id: <81474997-069A-4DA5-9BF7-1EC427D7FFEF@gmail.com> References: To: Alan Somers X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-fs , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:22:55 -0000 --Apple-Mail=_25C7EA9E-02FC-4071-AD0E-4238DBE008B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 8, 2015, at 9:15, Alan Somers wrote: > On Tue, Apr 7, 2015 at 12:37 AM, Garrett Cooper = wrote: >> Hi, >> Long story short, I had a lot of mail spooled up in = /var/spool. When I did ls /var/spool, ZFS chewed up almost all 12GB of = my memory in <10 mins (because there were enough files there) and the = system eventually panicked because [I assume that a memory allocation = failed and] a trap 12 panic was caught. I don=92t have the exact = details, but it should be relatively easy to repro (YMMV if you have a = boatload of RAM): >>=20 >> repro_end=3D10000000000 >> for i in $(seq 1 $repro_end); do mktemp tmp.XXXXXXXXXXXX; done >> ls >>=20 >> This might be ameliorated via r281026, but this change is only = available in CURRENT (so far), and I haven=92t tested it. >> Are there any comments about this scalability issue with = FreeBSD/ZFS? >> Thanks, >=20 > I spent the last ~ 24 hours creating 58,567,635 empty files in one > directory. I can ls it without crashing on a machine with 32 GB RAM. >=20 > # /usr/bin/time -l ls /tmp/tmp | wc > 1061.21 real 225.54 user 36.61 sys > 9720268 maximum resident set size > 28 average shared memory size > 8 average unshared data size > 128 average unshared stack size > 2425013 page reclaims > 0 page faults > 0 swaps > 108036 block input operations > 0 block output operations > 0 messages sent > 0 messages received > 0 signals received > 108004 voluntary context switches > 2428 involuntary context switches > 58567635 58567635 644243985 Strange. I wish I could gather more details about how many files were = located there. Distance and time that they were created might manner; in = my case there were _many_ spooled up emails that hadn=92t been sent = because I didn=92t take the time to fix my SMTP settings via = comcast/gmail. RAM amount might matter too. 12GB vs 32GB is a bit of a difference. Thanks! --Apple-Mail=_25C7EA9E-02FC-4071-AD0E-4238DBE008B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVJWPuAAoJEMZr5QU6S73eH0sH/13o74/hVQlD48Owq1o7nutf Lvje62TD0mfhB8owDTUNUGJ/eWun7izjb0BkjVdW1tV6736HCQyzfq7HXLj7yuZH WSzc8fHVI+Oh0E8TOSWn8tN+Th6s1lgab4Fd8Dc/CwAsI7Ai9Q29hM/0sJMjXK9r p94OtaoNO8U9wNbpwrY9DNIoVU6KOr7GsYI9WQw8RqbTYXp3YAmY/k5BmdbOWPiZ ntBYEKg0TwkFvHyiDdQqTArLI0SqmfDSPWCMkztm1JedjT1lM3fk1Vj1RqWisbvb /OAYj5sTjHryqQhvm1LuKuUbxFhWPBcv5i3wAj+tIymAjuKLERiJ24FWLpRB7TU= =Q5id -----END PGP SIGNATURE----- --Apple-Mail=_25C7EA9E-02FC-4071-AD0E-4238DBE008B4-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 05:19:34 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6D358D0 for ; Thu, 9 Apr 2015 05:19:34 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8138139C for ; Thu, 9 Apr 2015 05:19:34 +0000 (UTC) Received: by iget9 with SMTP id t9so42506793ige.1 for ; Wed, 08 Apr 2015 22:19:33 -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=UT3QENfiXodVxOXVlkLWj8g73wadF00fB2GDDhYu/F8=; b=pxffYGYJy0gOOIqOpiUmAxmXNsmernfdzEb1PphJKanchypeuf5xgBHHzi1LAFKRro IGhpUc6tJY1iTLX0H32uMLYcbnE4/KbSM/xtWwU7ZzKabQtF+u8orT3hCV7HsMI1XEBY gQNcwVgEiNj6YZjt++YkvziKjwkslsYg1EutotLYVQTxAtGS9SEaiAwK2cW3mixJScZq lGM4I9Qejw+TTBg5htcB2IlajFqEm0T3rtOsqllWpxkEbyN8nGZRdv/y4YKOUyGH7Y4Y CAoXdC/gvWIOhdQzp5nUYo38aWQULKOmRTebOb3y9H7OupuLXAj59jzA8uKKB0ZxRhtk LmYg== MIME-Version: 1.0 X-Received: by 10.42.137.202 with SMTP id z10mr27771379ict.37.1428556773817; Wed, 08 Apr 2015 22:19:33 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Wed, 8 Apr 2015 22:19:33 -0700 (PDT) Date: Thu, 9 Apr 2015 01:19:33 -0400 Message-ID: Subject: FreeBSD/ZFS on [HEAD] chews up memory From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:19:34 -0000 > RAM amount might matter too. 12GB vs 32GB is a bit of a difference. Allow me to bitch hypothetically... We, and I, get that some FS need memory, just like kernel and userspace need memory to function. But to be honest, things should fail or slow gracefully. Why in the world, regardless of directory size, should I ever need to feed ZFS 10GB of RAM? Notice I snuck in 2GB of that 12-32GB for kernels and users own bloat. Yeah ok, I get FFS DIRHASH, if I don't feed it I simply get a performance hit. But 12+ effing GB for ZFS and 80-90% free or the system crashes hard? WTF people?!?!?! Where have we gone wrong with this design? Where are the BSD principles??? I know I don't have a lot of time to characterize this issue, but I say this because we often keep seeing "add more ram" as the first/common fix, well that's not a real BSD solution. Cheers, mates. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 05:25:10 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B638FA3B for ; Thu, 9 Apr 2015 05:25:10 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81556651 for ; Thu, 9 Apr 2015 05:25:10 +0000 (UTC) Received: by igblo3 with SMTP id lo3so56490058igb.0 for ; Wed, 08 Apr 2015 22:25: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=QvLhTckYyqP7TlaJntuFTuessiZRo8zSs9vtIkJgYzA=; b=JO4sj2ttLTEUPmI+BFy/muU7uvnbJwsaXwBdNmRfsCQQMicsNVcFClNHHH28lkDoEM uv0f1WfpGSbMMsoIbygu8k/3xLg/CUQfnH43lUZ6KU8R7ZdA1IxqCnvXDucrs2pZgg0P xRFuv0SoabJJDNzfoYfZAw7AuoeHuXgzwMiwS5f/a9UJSv6xUY1fwvYYDBgzJSqom5oB 3Ve19pTLGCoKyJT9CTLrld3ft/fxcKQgfy2wvVT25P85dO4RKc1BW8dgDV7i7C2XpRHg 3zhVBPjj0uId9u3k9RdE78l75REsMNmaSgoo46KRiyjnDShRaxbZpvNywh9br8IU1HNj geMQ== MIME-Version: 1.0 X-Received: by 10.107.6.84 with SMTP id 81mr22533877iog.52.1428557109860; Wed, 08 Apr 2015 22:25:09 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Wed, 8 Apr 2015 22:25:09 -0700 (PDT) Date: Thu, 9 Apr 2015 01:25:09 -0400 Message-ID: Subject: FreeBSD specific content in zfs(8) man pages From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:25:10 -0000 The value of the open-zfs.org project is in its function as a bidirectional upstream source, with goal of minimizing the diffs, thus moving ZFS forward en masse. I think that would work if it was devoted to a single FreeBSD specific section (clear patch) at the bottom, or a handbook feature. I also think such sections could be maintained in the upstream, even as that would provide a section for each os, though with the end goal of coding or documenting to eliminate such caveats. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 05:31:09 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12FC5C4C for ; Thu, 9 Apr 2015 05:31:09 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF523782 for ; Thu, 9 Apr 2015 05:31:08 +0000 (UTC) Received: by igblo3 with SMTP id lo3so58177364igb.1 for ; Wed, 08 Apr 2015 22:31:08 -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 :content-type; bh=B5W0GCcaA767fTH4tLb+ilmcHFP+wkvBeZfU0xLXr58=; b=NNzSExtjx+tF/FAPWikoMLkKszBZu/8tBsCOJCKGT+7wzM/EzCmtY22etKq3GmSP5x v5D1Lg/x/qKUo3/zEEAVr4CVV2LmQVwy4KTjpSmfkEUEysrrshink/uwnv2h5k6SMU/L 9kz1XYDqgE5k8r77GQM31hXoWK0mOxy4Q3B+z9KT4xjnW0SagRjo+pMcfkeZpPNnfk6r F3CdvgllSdbzlAgY9Rz1K4khUSMQPDx6kLD/D3ECvQVjqVJb6ur+mYxLYPrEDSdxMA/M 9iXhK5X/zAoFiiYup1ydeKM5qFW27sk2VQXZfUmH7jQJ0rWQt+GyE/Cbx/r5+Cz9U0dt ih4w== MIME-Version: 1.0 X-Received: by 10.50.143.106 with SMTP id sd10mr17271988igb.17.1428557468118; Wed, 08 Apr 2015 22:31:08 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Wed, 8 Apr 2015 22:31:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 01:31:08 -0400 Message-ID: Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:31:09 -0000 > RAM amount might matter too. 12GB vs 32GB is a bit of a difference. Allow me to botch hypothetically... We, and I, get that some FS need memory, just like kernel and userspace need memory to function. But to be honest, things should fail or slow gracefully. Why in the world, regardless of directory size, should I ever need to feed ZFS 10GB of RAM? Notice I snuck in 2GB of that 12-32GB for kernels and users own bloat. Yeah ok, I get FFS DIRHASH, if I don't feed it I simply get a performance hit, not a crash. But 12+ efling GB for ZFS and 80-90% free or the system crashes hard? W t F people?!?!?! Where have we gone wrong with this design? Where are the BSD principles??? I know I don't have a lot of time to characterize this RAM issue, and I don't ascribe it to this case, but I say this because we often keep seeing "add more ram" as the first/common fix, well that's not a real BSD solution. Keep on BSD solutions and ZFS and all the rest will continue to be good. Cheers, mates :) From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 11:11:31 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53BF57B2 for ; Thu, 9 Apr 2015 11:11:31 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A24F619 for ; Thu, 9 Apr 2015 11:11:31 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so61549365igb.1 for ; Thu, 09 Apr 2015 04:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HInW3rdaBXM+I/hCRwbdpj1Nv8iMWcl2BcdLmXF1BR4=; b=IuwnRPSlYR/9ijWf4riVmXNTmwsd9sOFqH41BMyb0y/o9xXy7I8TVozmHdsXnY2/A1 ZZqJ36fhpHn69cv7cFsAdsrz6kaDLPJRzdmeiG9SuY6uoo3i4ONE+z3SObBhhtGoTBEO 0/uiEr6/8BGHlme7oocgkfDX12cx1prv130V8XjrulydcOJJuVAtQpSDZpYYcNaGDj3T ZQRkMA5CTSQfKzNLsD4cHRB6/Uok8ZZ2DYcL0j4KiNavAHV+yWOXxniKB/x9Jn7mNZYn a+lCC88PgRJFRHPRDbYoinqMOb8GDbNepAozRJGmOUcS3C1bKWUTc76qx0QV2Y3RTsBR qQWA== X-Received: by 10.50.109.228 with SMTP id hv4mr19313734igb.45.1428577890565; Thu, 09 Apr 2015 04:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.18 with HTTP; Thu, 9 Apr 2015 04:11:00 -0700 (PDT) In-Reply-To: References: From: Matthias Gamsjager Date: Thu, 9 Apr 2015 13:11:00 +0200 Message-ID: Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 11:11:31 -0000 When you decided to use ZFS did you read up on the design of it? Most of the RAM goes to ARC which caches all the read files for you. Beside that you can tame the ARC with parameters and FreeBSD should shrink the ARC when more memory is needed. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 13:29:36 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 141E1F6E for ; Thu, 9 Apr 2015 13:29:36 +0000 (UTC) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C403E925 for ; Thu, 9 Apr 2015 13:29:35 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id t39DJok1024652; Thu, 9 Apr 2015 08:19:50 -0500 (CDT) Date: Thu, 9 Apr 2015 08:19:50 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: grarpamp Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:29:36 -0000 On Thu, 9 Apr 2015, grarpamp wrote: >> RAM amount might matter too. 12GB vs 32GB is a bit of a difference. > > Allow me to bitch hypothetically... > > We, and I, get that some FS need memory, just like kernel and > userspace need memory to function. But to be honest, things > should fail or slow gracefully. Why in the world, regardless of > directory size, should I ever need to feed ZFS 10GB of RAM? >From my reading of this list in the past month or so, I have seen other complaints about memory usage, but also regarding UFS and NFS and not just ZFS. One is lead to think that the way the system uses memory for filesystems has changed. As others have said, ZFS ARC should automatically diminish, but perhaps ZFS ARC is not responsible for the observed memory issues. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 13:53:39 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2AF04AE for ; Thu, 9 Apr 2015 13:53:39 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7112AC3B for ; Thu, 9 Apr 2015 13:53:39 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3lN3pn4fY3z6v for ; Thu, 9 Apr 2015 15:53:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1428587614; x=1431179615; bh=i+K /618TlrRusUNB6MZ5omgAVBSYjOiJEF31kry11PI=; b=Gu5/wAj+ONomNVbEbaY XCUGhDLpZRPY7MMn4tK5u9nQFUjnT4dW3pVfygcNQbJ6+Pzvuks518KMNCKZ297G Rs1DqJ5h5WaBr+EIwI6gu+RP+BOnA3fC3GamQ6o/C5n4vK+jBASOcF+Xp4RQmSkF HC77u65+EYyCq069F7+/mySk= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id beuwaP5C_xic for ; Thu, 9 Apr 2015 15:53:34 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Thu, 9 Apr 2015 15:53:34 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3lN3pk4dwPzND for ; Thu, 9 Apr 2015 15:53:34 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Thu, 09 Apr 2015 15:53:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Apr 2015 15:53:34 +0200 From: Mark Martinec To: freebsd-fs@freebsd.org Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory Organization: J. Stefan Institute In-Reply-To: References: Message-ID: <728627c71bbc88bc9a454eda3370e485@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:53:39 -0000 2015-04-09 15:19, Bob Friesenhahn wrote: > On Thu, 9 Apr 2015, grarpamp wrote: >>> RAM amount might matter too. 12GB vs 32GB is a bit of a difference. >> Allow me to bitch hypothetically... >> We, and I, get that some FS need memory, just like kernel and >> userspace need memory to function. But to be honest, things >> should fail or slow gracefully. Why in the world, regardless of >> directory size, should I ever need to feed ZFS 10GB of RAM? > > From my reading of this list in the past month or so, I have seen > other complaints about memory usage, but also regarding UFS and NFS > and not just ZFS. One is lead to think that the way the system uses > memory for filesystems has changed. > > As others have said, ZFS ARC should automatically diminish, but > perhaps ZFS ARC is not responsible for the observed memory issues. > > Bob I'd really like to see the: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 find its way into 10-STABLE. Things behaved much more sanely some time in 9.*, before the great UMA change took place. Not everyone has dozens of gigabytes of memory. With 16 GB mem even when memory is tight (poudriere build), the wired size seems excessive, most of which is ARC. Mark From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 13:58:51 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE86D59F for ; Thu, 9 Apr 2015 13:58:51 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F9C1C80 for ; Thu, 9 Apr 2015 13:58:50 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id C5F73620DA; Thu, 9 Apr 2015 23:58:41 +1000 (EST) Message-ID: <55268590.2020803@herveybayaustralia.com.au> Date: Thu, 09 Apr 2015 23:58:40 +1000 From: R Skinner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Kulikov Subject: Re: fuse user mounting fails References: <5521DF1E.8000703@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:58:51 -0000 On 08/04/2015 18:32, Konstantin Kulikov wrote: > Hello. > > What command do you use to mount? > You can't run ntfs-3g directly, instead use something like: > % mount_fusefs /dev/da0 `which ntfs-3g` /dev/da0 $HOME/mnt > See mount_fusefs(8) for details. > Mounting ntfs-3g worked for me, but not simple-mtpfs and I didn't try exfat. I have used something similar for ntfs-3g - I believe it was mount -t ntfs-3g ... etc. Unfortunately exfat is different; you have to use mount.exfat directly which calls mount_fusefs (saw that in truss). Still didn't work either way. The more I think about, the more I think there might be something in fuse that is not quite set correctly. Can anyone suggest a good doc for fuse? The man page appeared a bit cryptic to me, I don't think I quite catch where its coming from. Might be able to rephrase my query better... Better yet, a good info page on troubleshooting fuse would be real handy :) > > On Mon, Apr 6, 2015 at 4:19 AM, R Skinner > wrote: >> I'm just starting (regular) use with fuse, and this is using the exfat fuse >> module. I tried with ntfs-3g on occasion with similar results, but now I >> need this to work a whole lot better. >> >> As root I can get fuse modules to mount a file system with no issue; albeit >> I have to set mode and owner so that is usable for my purposes. >> >> I want to set things so that as a normal user (so not just myself) can mount >> these. Currently I get: >> >> FUSE exfat 1.0.1 >> mount_fusefs: /dev/fuse on /usr/home/admin/mnt: Operation not permitted >> fuse: failed to mount file system: No such file or directory >> >> Permissions are set for operator group rw on /dev fuse, da*, usb*, and so >> on... you get my drift - other cards all work if just msdosfs using usual >> mount ops. Just fuse is an issue. Sysctl vfs.usermount is set to 1. >> >> I've tried truss, truss -f but I can't make head or tail of it. >> >> I'm not exactly any kind of expert on fuse, is there any quick fixes I'm >> missing? What debug do I need to do? Most searches mention permissions >> issues and sysctl, can't find anything that actually helps. This on 10.0 atm >> as well, I have a 10.1 I can test on if required but would rather not given >> current operations. >> >> Cheers >> _______________________________________________ >> 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 Apr 9 14:21:23 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13E0CCCF for ; Thu, 9 Apr 2015 14:21:23 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C63D1EC7 for ; Thu, 9 Apr 2015 14:21:22 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id t39ELKo4056222 for ; Thu, 9 Apr 2015 09:21:20 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Thu Apr 9 09:21:20 2015 Message-ID: <55268AB8.8010202@denninger.net> Date: Thu, 09 Apr 2015 09:20:40 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory References: <728627c71bbc88bc9a454eda3370e485@mailbox.ijs.si> In-Reply-To: <728627c71bbc88bc9a454eda3370e485@mailbox.ijs.si> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060906010304000502060807" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:21:23 -0000 This is a cryptographically signed message in MIME format. --------------ms060906010304000502060807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 4/9/2015 08:53, Mark Martinec wrote: > 2015-04-09 15:19, Bob Friesenhahn wrote: >> On Thu, 9 Apr 2015, grarpamp wrote: >>>> RAM amount might matter too. 12GB vs 32GB is a bit of a difference. >>> Allow me to bitch hypothetically... >>> We, and I, get that some FS need memory, just like kernel and >>> userspace need memory to function. But to be honest, things >>> should fail or slow gracefully. Why in the world, regardless of >>> directory size, should I ever need to feed ZFS 10GB of RAM? >> >> From my reading of this list in the past month or so, I have seen >> other complaints about memory usage, but also regarding UFS and NFS >> and not just ZFS. One is lead to think that the way the system uses >> memory for filesystems has changed. >> >> As others have said, ZFS ARC should automatically diminish, but >> perhaps ZFS ARC is not responsible for the observed memory issues. >> >> Bob > > I'd really like to see the: > > [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 > > find its way into 10-STABLE. Things behaved much more > sanely some time in 9.*, before the great UMA change > took place. Not everyone has dozens of gigabytes of memory. > With 16 GB mem even when memory is tight (poudriere build), > the wired size seems excessive, most of which is ARC. > There are a number of intertwined issues related to how the VM system=20 interacts with ZFS' use of memory for ARC; the patch listed above IMHO=20 resolves most -- but not all -- of them. The one big one remaining, that I do not have a patch to fix at present, = is the dmu_tx write cache (exposed in sysctl as=20 vfs.zfs.dirty_data_max*) It is sized based on available RAM at boot=20 with both a minimum and maximum size and is across all pools. This=20 initializes to allow up to 10% of RAM to be used for this on boot with a = cap of 4Gb. That can be a problem because in a moderately-large RAM=20 configuration machine with spinning rust it is entirely possible for=20 that write cache to represent /*tens of seconds or even more than a=20 minute */of actual I/O time to flush. (The maximum full-track=20 sequential I/O speed of a 7200RPM 4TB drive is in the ~200Mb/sec range;=20 10% of 32Gb is 3Gb, so this is ~15 seconds of time in a typical 4-unit=20 RaidZ2 zVol -- and it gets worse, much worse, with smaller-capacity=20 disks that have less areal density under the head and thus are slower=20 due to the basic physics of the matter.) The write cache is a very=20 good thing for performance in most circumstances because it allows ZFS=20 to optimize writes to minimize the number of seeks and latency required=20 but there are some pathological cases where having it too large is very=20 bad for performance. Specifically, it becomes a problem when the operation you wish to=20 perform on the filesystem requires coherency with something _*in*_ that=20 cache, and thus the cache must flush and complete before that operation=20 can succeed. This manifests as you doing something as benign as typing=20 "vi some-file" and your terminal session locks up for tens of seconds=20 to, in some cases, more than a minute! If _*all*_ the disks on your machine are of a given type and reasonably=20 coherent in I/O throughput (e.g. all SSDs, all rotating rust of the same = approximate size and throughput, etc) then you can tune this as the code = stands to get good performance and avoid the problem. But if you have=20 some volumes comprised of high-performance SSD storage (say, for=20 often-modified or accessed database tables) and other volumes comprised=20 of high-capacity spinning rust (because SSD for storage of that data=20 makes no economic sense) then you've got a problem because=20 dirty_data_max is system-wide and not per-pool. The irony is that with the patch I developed in under heavy load the=20 pathology tends to not happen because the dmu_tx cache gets cut back=20 automatically under heavy load as part of the UMA reuse mitigation=20 strategy that I implemented in that patch. But under light load it=20 still can and sometimes does bite you. The best (and I argue proper)=20 means for eliminating that is for the dmu_tx cache to be sized per-pool=20 and to be computed based on the pool's actual write I/O performance; in=20 other words, it should be sized to represent a maximum=20 latency-to-coherence time that is acceptable (and that should be able to = be tuned.) Doing so appears to be quite non-trivial though or I would=20 have already taken it on and addressed it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms060906010304000502060807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGWTCC BlUwggQ9oAMCAQICARowDQYJKoZIhvcNAQELBQAwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEg U3lzdGVtcyBMTEMgQ0EwHhcNMTUwMzI1MTMxMDIwWhcNMjAwMzIzMTMxMDIwWjBTMQswCQYD VQQGEwJVUzEQMA4GA1UECBMHRmxvcmlkYTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEX MBUGA1UEAxMOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQCmk+jIznE3HgHbh4JU2s86dKGDs4f3ZdED6vCQx9+LnJl7GgT2aAUAARqNnH5dDuC4w/4h K1qb8sXu3yYWlXLLs+vw3oLnx284o0kSZZs/FQ9W90gVTeZ1iTybscN7iXkaf83g1jueBNby n4v1bJEwX/xe94NW0IwBPluOzzXVIMskaZWhqGLtSaiSo4PYUnYMXPRNG7NAWQ2VAZXJkIM2 AM0B3LfyTyZw+NDNJMMQLZBDqS5vHuS78UODXpyyliSsBgaa04KVRsrcz6S2aYxk9ZjU3yD2 JJ7ezlKnZ4j/pc+16rv5fPfJWZAmG3v3kMiMzoDMS+d6CsSYxyQYHDGt+2If0cGpFv3D7Xr6 jxHouLKtipMQ/pPd+T+lugdEj3JfRu0nIM38j+dQh1N+wdiCEgFo0XuPIWW9g7VGwk8n29KR LAT10QZH9ADYbQqwXeXe9xWXjMAXHm6NTXyxpYyuNAV5zwsT5N4fZRwxKn828XZAKLLyeDGg 2lSBKdnT3osk668Yi5hclZH3UX8JikOWzixQ7T1/lWYGAGbElwFUC3xKRv/TI8E6ZYYYbQVN 3JXLKNIfQ7I9fpqrQeMVe03zXGGsXcE1krA8M4VP1ipoDfGD0/Pt8k2mTLUc4PY9eKZJfVlY WWJ/RHPp+N+MFD1sKirYrDvCHaeWyyLDx2dcIwIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJ YIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFCMvNiXRuCcqulq6cUWK8SNwo7vhMB8G A1UdIwQYMBaAFCRxm52Fffzd3b2wypKUA6H60201MB0GA1UdEQQWMBSBEmthcmxAZGVubmlu Z2VyLm5ldDA4BglghkgBhvhCAQMEKxYpaHR0cHM6Ly9jdWRhc3lzdGVtcy5uZXQ6MTE0NDMv cmV2b2tlZC5jcmwwDQYJKoZIhvcNAQELBQADggIBAHAUwvyHIJw3LTLqpF4apSzuIm5sBqyH rYg1mk7vPkgPFSrsr3AmmtR2iifN7fgAG6NzrL7SddhTiIMbW7mL32Tuklx9sUXM6iEyuiL/ /TRZ95ob7BtM58x2R6y2p00OKOfUCmjyqWy/pAjUAk7c5m9uLr6rVQUj0lGuvCMZEo1lnG6S +EUZ1Mi2mz9HrZBR2GhNPb5UgNVsX91So+uEF+1pRg1mQO6KvX4E84MOPe++qM76o+NvlEIw IU9tYHjSgjqWrqUQgEesMjahWEblfT+XPvPwy9WtICESMQGdGzVgDBgwoFrFnS2GyKlve0rj LKBs5ZtMrsASnbSvWX5uYy6Fb0Gv/F2neStmAyxL6Kupu4D28QpbtG1nxl3pN3SyQiUfXvVm LC3JvS6r6eQsG8Q/6fxCvUNQg8AjvVSMYTspAm3O0rihPQWX1GTAWS9fIxYlo5Y3NY8SpTXD 7RU5QzbQnK/mMJkuuysQeFAmK58El/7GcUy4zt2akuTBD0YroH2FHjfNUJej0lwHgxkNU3zG quKn+Llw1/u/+cncRiVPVatbqhUtXk2a0Y6OKrcAmFwzXlAi//hzofp3Sd1sWW0SUKQIizl7 xSxyu0cnYbxiBLDn3bmCTYCowUHLm6vBDc+3l6jxOM5fWOdJwq4hakYmrGonoI0pRTG732P9 Jf5/MYIE4zCCBN8CAQEwgZYwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIw EAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMT E0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMg Q0ECARowCQYFKw4DAhoFAKCCAiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTUwNDA5MTQyMDQwWjAjBgkqhkiG9w0BCQQxFgQUesRApQLqLF7yBIuUifcy uPwXjJEwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBpwYJKwYBBAGCNxAEMYGZMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEaMIGpBgsqhkiG9w0BCRACCzGBmaCBljCBkDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBT eXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJ ARYTQ3VkYSBTeXN0ZW1zIExMQyBDQQIBGjANBgkqhkiG9w0BAQEFAASCAgB+njxwhJwkSCuq pmsxFD4wNCxkVIMlDRxPAqqOSGcT0gL5xV3FWADoFGKgS8nItroXHQ8Xk6XsbabY3py/jS8D RRNoNxlF55hQy7VjjtrYo1PxHzlSNaawbrFxEWkkTHm8eagft4q0GZvhNm1v6CdceViJeCq3 XHh7YKiNwIaFQNHIT0+lITdk8o2n4hvz/OueMfQW8QF9rhC9G+ERKtL2322Of66By6/oMphn Tv6Kr+Ldy3wQ6VKT4Xk3DdC4tMFpq12Q9qe20BOr3vzbsbn2h/tPaGtLr0cS9laz6J0S3sVo V+G0orRY2hYirvw9q/mOl9Ri1VMO0LkdzLWtZ+3jrGnaz+8AlmEWY24Lyd4KEjVgvBi+PeHo 0iImWjTH5NDt8ALA6+xpjw3oYpYK5Xyry/PRMiWvZiq4AkhexFgVYL5hzGghV2izTKhv8AOa SImL6H74xuVt1rL5pGXlq4Bz2hPnPVuOf03zRhpJR+AEymD8wWrGRSRn3LsbKYZVHfHjnJwR 0sTVrm+nPJT7ca3Sy51APwj87+e/u22H0ktLK5BLUVFLarF5Fz2dGE7j/1OnEsx2Llp4OAv4 P+0ud3rIQoNQM6Y0mg0wZIqwmgbGOl+Jhg1sE58PmkV3KZZ0pCtg1H8vnb8BEhHTc3RF4vx5 XsvcKqY7aqGeiSHIR/cc5wAAAAAAAA== --------------ms060906010304000502060807-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 21:39:10 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8B62889 for ; Thu, 9 Apr 2015 21:39:10 +0000 (UTC) Received: from smtp101-5.vfemail.net (eightfive.vfemail.net [96.30.253.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94309F14 for ; Thu, 9 Apr 2015 21:39:09 +0000 (UTC) Received: (qmail 15432 invoked by uid 89); 9 Apr 2015 21:39:00 -0000 Received: by simscan 1.4.0 ppid: 15420, pid: 15428, t: 0.0735s scanners:none Received: from unknown (HELO d3d3MTEwQDE0Mjg2MTU1NDA=) (cmlja0BoYXZva21vbi5jb21AMTQyODYxNTU0MA==@MTcyLjE2LjEwMC45MkAxNDI4NjE1NTQw) by 172.16.100.61 with ESMTPA; 9 Apr 2015 21:39:00 -0000 Date: Thu, 09 Apr 2015 16:39:00 -0500 Message-ID: <20150409163900.Horde.ZLVwr91i2UaonmJT1bC-Pw1@www.vfemail.net> From: Rick Romero To: freebsd-fs Subject: ZFS 10.1 send single snapshot - space 'used' irregularity User-Agent: Internet Messaging Program (IMP) H5 (6.2.2) X-VFEmail-Originating-IP: MTA4Ljc2LjE3NS4xMw== X-VFEmail-AntiSpam: Notify admin@vfemail.net of any spam, and include VFEmail headers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes Content-Transfer-Encoding: 8bit Content-Disposition: inline Content-Description: Plaintext Message X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:39:10 -0000 I have 3 servers, A, B, C.  I'm building C to replace A, and replicating the data to C from backup B.  A is offsite in relation to B and C. All servers are FreeBSD 10.1, except A - which is 9.2. I'm confused on disk usage. Not so much a GB here or there, but 250GB is 'unaccounted for' on C.  C and A should be a pretty close match. A - looks correct sysvolssd2/home  used                  495G                   - sysvolssd2/home  usedbysnapshots       37.9G                  - sysvolssd2/home  usedbydataset         456G                   - sysvolssd2/home  usedbychildren        669M                   - sysvolssd2/home  usedbyrefreservation  0                      - sysvolssd2/home  logicalused           585G                   - NAME         SIZE     ALLOC   FREE    CAP    DEDUP    HEALTH  ALTROOT sysvolssd2  1.39T   744G   680G       52%      1.00x     ONLINE  - B - looks correct (backup of A, holds more snapshots and other crap than A) sysvol/primessd_home  used                  777G                   - sysvol/primessd_home  usedbysnapshots       240G                   - sysvol/primessd_home  usedbydataset         537G                   - sysvol/primessd_home  usedbychildren        0                      - sysvol/primessd_home  usedbyrefreservation  0                      - sysvol/primessd_home  logicalused           754G                   - NAME         SIZE  ALLOC   FREE   FRAG  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT sysvol          4.53T  2.43T  2.10T    20%         -                 53%  1.00x  ONLINE  -  C - missing what appears to be the multiple snapshot data.  Only the latest snapshot was sent, not the entire dataset.  So 531GB is close enough to the 537G of B's dataset. sysvol_enc/home  used                  758G                   - sysvol_enc/home  usedbysnapshots       3.00M                  - sysvol_enc/home  usedbydataset         752G                   - sysvol_enc/home  usedbychildren        5.84G                  - sysvol_enc/home  usedbyrefreservation  0                      - sysvol_enc/home  logicalused           531G                   - NAME         SIZE  ALLOC   FREE   FRAG  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT sysvol_enc  1.39T  1.12T   277G    49%         -                   80%  1.00x  ONLINE  - C is geli encrypted and B is not. Unfortunately when I check another server that's geli encrypted, it looks fine: E - nlsysvol/home  used                  13.8G                  - nlsysvol/home  usedbysnapshots       5.58G                  - nlsysvol/home  usedbydataset         7.78G                  - nlsysvol/home  usedbychildren        483M                   - nlsysvol/home  usedbyrefreservation  0                      - nlsysvol/home  logicalused           12.0G                  - NAME       SIZE  ALLOC   FREE   FRAG  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT nlsysvol   115G  42.8G    72.2G      -         -                    37%  1.00x    ONLINE  - So the difference shouldn't be related to the encryption.  It's almost as if the send from B to C included all the incremental snapshots, but didn't actually account for them.  Am I reading this wrong, or is something else not right ? Should I delete that dataset, re-send the entire original dataset, then delete the incremental snapshots? It makes me a little concerned that deleting a snapshot might delete the data which was written at that time, even though it was not deleted in followup snapshots... And I assume FRAG is fragmentation.  50% is a bit strange for a brand new receive, isn't it? help.  :) Rick From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 21:55:44 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECE32FD9 for ; Thu, 9 Apr 2015 21:55:44 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B71A017B for ; Thu, 9 Apr 2015 21:55:44 +0000 (UTC) Received: by ignm3 with SMTP id m3so3556573ign.0 for ; Thu, 09 Apr 2015 14:55:43 -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=Eg097bqO6kRjYrzOymWxPVhGndSyQGUSls7urHdH1oc=; b=D6mQKr68MRpUrRlks0jLE7QvgvJpKoBPU4KJzE6xzHAs19s+MPRGhFQAVKDXk63LDA kXFlI1dXV7Yh6q9SSitxtNemNiIm3fTTbaVrGBl8WrEKrD3nKFr0A56xTEoViPreQB2V wY2KnaGpbPWt/VWQRSdk9dCMS5szK0UGV3Nn5GmDPPw5UN1a70rmQvH+T564hIsgdHZ6 tvQD7mwpwTkkWYwG/71aZOfEcSPE1XUAG3mwKwKy5C6VV1I5qagnKk7gH1/mL3F1/cr/ eyYt7k+8wyD6o5WD54AwpI/tvS4Tlsf1r0+wy1qZlKXlS+vKBMK8F2BPaUHHMlxIqZ17 z6QQ== MIME-Version: 1.0 X-Received: by 10.50.112.98 with SMTP id ip2mr23327183igb.15.1428616543822; Thu, 09 Apr 2015 14:55:43 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Thu, 9 Apr 2015 14:55:43 -0700 (PDT) Date: Thu, 9 Apr 2015 17:55:43 -0400 Message-ID: Subject: OT - cogeco.com your mail is broken From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:55:45 -0000 Turn off your broken autoresponder or unsubscribe yourself. Received: from bupnmail1.cogeco.com (bupnmail1.cogeco.com. [24.226.15.15]) Received: from autodiscover.cogeco.com ([10.1.2.93]:53095 helo=BUPMEXCASHUB2.cogeco.com) (Exim 4.82_1-5b7a7c0-XX) Message-ID: X-Mailer: Microsoft CDO for Windows 2000 On Thu, Apr 9, 2015 at 9:30 AM, Administrator wrote: > This email has violated the PROFANITY. > and Pass has been taken on 4/9/2015 9:29:47 AM. > Server: BUPMEXCASHUB2 > Sender: bfriesen > Recipient: grarpamp.freebsd-fs > Subject: Re: memory > > The information in this message, including in all attachments, is > L'information apparaissant dans ce message electronique et dans les documents From owner-freebsd-fs@FreeBSD.ORG Fri Apr 10 02:25:04 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D92131A for ; Fri, 10 Apr 2015 02:25:04 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 453B513A for ; Fri, 10 Apr 2015 02:25:04 +0000 (UTC) Received: by iebmp1 with SMTP id mp1so7371876ieb.0 for ; Thu, 09 Apr 2015 19:25:03 -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 :content-type; bh=YesgYeyykHAN1giyf5RYLyhXV9yfvBWP+9PXFEuK4lI=; b=hC5x6N4H2kG5W0JT0TFO8NocEib2ZC3rMpAeOLCsIPUg5nU6m7cj9zCaQLEuyx+LxK 5fQ3d7tDoBU+rvxm8Z1C9iTpIwTtLBlmhm5gaAmwlCSVzH5Scg7XNvQH2GmnW660XpKr PEqLryaHDyPPHBWTmUnZhThjxENJaFCBtvgNpeIyGCFOS3EjPmjaHajI0WUQsN5jeZiP rpAcqG7r4Ghcut0yGZYZuZ3TGttuWrDm5/XL8ojXj6B6JBlT58EQdQQXgVZOlC72NE0n QkS9BIzLOD+xenD7f7yzRbY8vLg05Z8ez0HEJW5cK5Q64jsozUNH3F7uTSeJO3I7iujJ y3xQ== MIME-Version: 1.0 X-Received: by 10.107.156.19 with SMTP id f19mr51570904ioe.45.1428632703802; Thu, 09 Apr 2015 19:25:03 -0700 (PDT) Received: by 10.36.51.76 with HTTP; Thu, 9 Apr 2015 19:25:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 22:25:03 -0400 Message-ID: Subject: Re: FreeBSD/ZFS on [HEAD] chews up memory From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:25:04 -0000 > "vi some-file" and your terminal session locks up for tens of seconds > to, in some cases, more than a minute! I see this but would need to independant test whether it is more due to the FS being full or to memory condition. I really should try to test out more low physical or application memory conditions to better see any issues. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 10 08:06:25 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67524A5D for ; Fri, 10 Apr 2015 08:06:25 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26288B3F for ; Fri, 10 Apr 2015 08:06:24 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YgTvz-0005sg-D8 for freebsd-fs@freebsd.org; Fri, 10 Apr 2015 10:06:15 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: ZFS 10.1 send single snapshot - space 'used' irregularity References: <20150409163900.Horde.ZLVwr91i2UaonmJT1bC-Pw1@www.vfemail.net> Date: Fri, 10 Apr 2015 10:05:02 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20150409163900.Horde.ZLVwr91i2UaonmJT1bC-Pw1@www.vfemail.net> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_20, URIBL_BLOCKED autolearn=disabled version=3.3.1 X-Scan-Signature: 9484ae446d4f83cee8bf28db5146d16c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:06:25 -0000 How about disk types? Do they use the same sector size? Which might give a different overhead. What is the layout of your pools? ZRAID1, 2 or 3, MIRROR? Regards, Ronald. On Thu, 09 Apr 2015 23:39:00 +0200, Rick Romero wrote: > I have 3 servers, A, B, C. I'm building C to replace A, and replicating > the data to C from backup B. A is offsite in relation to B and C. > All servers are FreeBSD 10.1, except A - which is 9.2. > > I'm confused on disk usage. Not so much a GB here or there, but 250GB is > 'unaccounted for' on C. C and A should be a pretty close match. > > A - looks correct > > sysvolssd2/home used 495G - > sysvolssd2/home usedbysnapshots 37.9G - > sysvolssd2/home usedbydataset 456G - > sysvolssd2/home usedbychildren 669M - > sysvolssd2/home usedbyrefreservation0 - > sysvolssd2/home logicalused 585G - > > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > sysvolssd2 1.39T 744G 680G 52% 1.00x ONLINE - > > B - looks correct (backup of A, holds more snapshots and other crap than > A) > sysvol/primessd_home used 777G - > sysvol/primessd_home usedbysnapshots 240G - > sysvol/primessd_home usedbydataset 537G - > sysvol/primessd_home usedbychildren 0 - > sysvol/primessd_home usedbyrefreservation0 - > sysvol/primessd_home logicalused 754G - > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAPDEDUP HEALTH > ALTROOT > sysvol 4.53T 2.43T 2.10T 20% - 53% > 1.00x ONLINE - > C - missing what appears to be the multiple snapshot data. Only the > latest snapshot was sent, not the entire dataset. So 531GB is close > enough to the 537G of B's dataset. > sysvol_enc/home used 758G - > sysvol_enc/home usedbysnapshots 3.00M - > sysvol_enc/home usedbydataset 752G - > sysvol_enc/home usedbychildren 5.84G - > sysvol_enc/home usedbyrefreservation0 - > sysvol_enc/home logicalused 531G - > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAPDEDUP HEALTH > ALTROOT > sysvol_enc 1.39T 1.12T 277G 49% - 80% > 1.00x ONLINE - > > C is geli encrypted and B is not. > > Unfortunately when I check another server that's geli encrypted, it looks > fine: > > E - > nlsysvol/home used 13.8G - > nlsysvol/home usedbysnapshots 5.58G - > nlsysvol/home usedbydataset 7.78G - > nlsysvol/home usedbychildren 483M - > nlsysvol/home usedbyrefreservation0 - > nlsysvol/home logicalused 12.0G - > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAPDEDUP HEALTH > ALTROOT > nlsysvol 115G 42.8G 72.2G - - 37% > 1.00x ONLINE - > > So the difference shouldn't be related to the encryption. It's almost as > if the send from B to C included all the incremental snapshots, but > didn't > actually account for them. Am I reading this wrong, or is something else > not right ? > Should I delete that dataset, re-send the entire original dataset, then > delete the incremental snapshots? > > It makes me a little concerned that deleting a snapshot might delete the > data which was written at that time, even though it was not deleted in > followup snapshots... > And I assume FRAG is fragmentation. 50% is a bit strange for a brand new > receive, isn't it? > > help. :) > > Rick > _______________________________________________ > 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 Fri Apr 10 18:44:00 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E061391 for ; Fri, 10 Apr 2015 18:44:00 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.43]) by mx1.freebsd.org (Postfix) with ESMTP id CA71A22E for ; Fri, 10 Apr 2015 18:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vm-relay3.estpak.ee (Postfix) with ESMTP id 47FF6224F for ; Fri, 10 Apr 2015 21:43:58 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at vm-relay3.estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (vm-relay3.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1UHBd1xN8QR for ; Fri, 10 Apr 2015 21:43:49 +0300 (EEST) Received: from BACKUP-MX-Relayhost1.estpak.ee (backup-mx-relayhost1.estpak.ee [88.196.174.249]) by vm-relay3.estpak.ee (Postfix) with ESMTP id B92242230 for ; Fri, 10 Apr 2015 21:43:45 +0300 (EEST) Received-SPF: None (no SPF record) identity=mailfrom; client-ip=62.65.33.35; helo=server; envelope-from=account@regs.com; receiver=freebsd-fs@freebsd.org X-SMTP-Auth-NETI-Businessmail: no Received: from SERVER (35.33.65.62.sta.estpak.ee [62.65.33.35]) by BACKUP-MX-Relayhost1.estpak.ee (Postfix) with ESMTP id B60822C8 for ; Fri, 10 Apr 2015 21:43:45 +0300 (EEST) From: "westernunionresponse" Subject: Western Union: money transfer confirmed To: freebsd-fs@freebsd.org MIME-Version: 1.0 Date: Fri, 10 Apr 2015 20:43:46 +0200 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 18:44:00 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Dear freebsd-fs@freebsd.org, Your money transfer's now available for pickup. ----------------------------------------------------------------------= ---------- TRANSACTION DETAILS: ----------------------------------------------------------------------= ---------- Your tracking number (MTCN) is: 5233423958. Please use this number for= any questions. Transaction date: - 10/04/2015 Amount sent: - EUR 970.68 Transfer fee: - EUR 48,98 Total: - EUR 1019.66 Authorisation code: - 432112 Sender: freebsd-fs@freebsd.org Issues with this transaction? If you haven't authorized this transaction ,click the link below to ge= t full refund. Go to the Help Centre at: http:/www.westernunion.com/support/login/ Thank you for using Western Union! From owner-freebsd-fs@FreeBSD.ORG Fri Apr 10 21:43:09 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5D71701 for ; Fri, 10 Apr 2015 21:43:09 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A140BEC for ; Fri, 10 Apr 2015 21:43:09 +0000 (UTC) Received: by lagv1 with SMTP id v1so22212506lag.3 for ; Fri, 10 Apr 2015 14:43:07 -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=CMeb8pZuY79bf75So1mY5+kbRv7B/9tEelRLOMexm7U=; b=PVmSIqAkUyo43NT7YUhKC2WYDYTqkNizin2qbrsfuZ91xhTgduHmKTTx7BVRwi8tyN p8Kkja1x2gPSq/bmJ33KnvLys8TGosb3zL/foeu78bDU9HbiNaam4LS3Pz72WoWSXAJi yThQSVKE3F+Hl2bwmC+YLtHz8TKztQRMDtVZSfVoi072rADOh8gcTLoE8jIRT0/Qa5nH ykuHZSTaoJwlJRytZ2r5s7xTGkOC5JZ8nTQoeBZ3sDZv4ychLq+uhSBixOGkZ/GbaNxT YZ3PMRrHXgU9MFZ4HXtyqxPLTZxOwuqzWQpBvXUN2JywW0Ia/X28hV/jWxRiD5YwS4aO +Byw== MIME-Version: 1.0 X-Received: by 10.152.203.134 with SMTP id kq6mr3168900lac.110.1428702187105; Fri, 10 Apr 2015 14:43:07 -0700 (PDT) Received: by 10.114.24.72 with HTTP; Fri, 10 Apr 2015 14:43:07 -0700 (PDT) Date: Fri, 10 Apr 2015 14:43:07 -0700 Message-ID: Subject: Migrating ZFS from 8.3 to 10.1 From: javocado To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:43:10 -0000 Hello, I am planning to migrate (upgrade) my system from FreeBSD 8.3 RELEASE to 10.1 RELEASE (both amd64). My zfs pool exists on it's own physical device(s) so my upgrade will consist of: 1. install FreeBSD 10.1 on boot device (in a temp system) 2. remove 8.3 boot device (from production system) 3. install new 10.1 boot device and boot up production system 4. re-mount zfs FS My question is, what do I need to know about how this change will affect or impact the zpool and datasets? Is there any chance zfs data could be lost or destroyed? Might there be a performance loss due to version differences? Is upgrading the zpool (once booted to 10.1) strongly advised? Any downsides or dangers there? Some other info worth considering (production system): ZFS filesystem version 5 ZFS storage pool version 28 Thanks! From owner-freebsd-fs@FreeBSD.ORG Fri Apr 10 23:07:42 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC78E42A for ; Fri, 10 Apr 2015 23:07:42 +0000 (UTC) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73E123F7 for ; Fri, 10 Apr 2015 23:07:41 +0000 (UTC) Received: by widjs5 with SMTP id js5so25316108wid.1 for ; Fri, 10 Apr 2015 16:07:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DdRov2gkdQiK9VrzMi/D8OUegBENC5Sf45bxWpQUEUQ=; b=Nl2ufdE2A6okaMB+RuQiG0L+XEaPiw2a2/XpSUQWAr/vgYeDOElE3wa7zhfe9YfarL dyh5AXOPorksmNVjjbOn1ca14tOQn6YGdRaxgIa45PqXbOt3iJWIPNJtkmvyOTUJqQRG 15rccNfanwBpKA2ZzoOwwyl+gJODvOnBw5mpjc8Te4iX35UoQ7nzfrre+zNymCS31gkP wmUuzDGgovIKgxeVudOx92S9a4bbkzO76m+tT+Ix/9t1FNm1reL7S/tpMwgJa1zw631B TcZqF+3iV49psgUx7om8Fe39P3qdbYpf/FS9HERMXQKwH9oGEXtAwmcTY82FT1fr79/d Hp7g== X-Gm-Message-State: ALoCoQnd9hoiRc+zmJUh0UVfpWcX53O+ea3OC6dWWExUB8KKZbD2b/9oCxPFUa9/cRX2wrojicOo X-Received: by 10.180.80.199 with SMTP id t7mr1765278wix.52.1428707254508; Fri, 10 Apr 2015 16:07:34 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ch6sm292332wjc.3.2015.04.10.16.07.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 16:07:33 -0700 (PDT) Message-ID: <552857B8.6040001@multiplay.co.uk> Date: Sat, 11 Apr 2015 00:07:36 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Migrating ZFS from 8.3 to 10.1 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:07:42 -0000 We did moved from 8.3 -> 10.1 had to go via 10.0 as we did a in place source upgrade but had no issues. 10.x has block size validation which 8.3 so if your disks are 4k sectors and you didn't manually configure this on install you may end up with pools complaining about this, but that will just mean reduced performance (something you had already). Yes once your happy 10.1 is working fine you should upgrade your pools to get all the new features which are well worth having. Regards Steve On 10/04/2015 22:43, javocado wrote: > Hello, > > I am planning to migrate (upgrade) my system from FreeBSD 8.3 RELEASE to > 10.1 RELEASE (both amd64). My zfs pool exists on it's own physical > device(s) so my upgrade will consist of: > > 1. install FreeBSD 10.1 on boot device (in a temp system) > 2. remove 8.3 boot device (from production system) > 3. install new 10.1 boot device and boot up production system > 4. re-mount zfs FS > > My question is, what do I need to know about how this change will affect or > impact the zpool and datasets? Is there any chance zfs data could be lost > or destroyed? Might there be a performance loss due to version differences? > Is upgrading the zpool (once booted to 10.1) strongly advised? Any > downsides or dangers there? > > Some other info worth considering (production system): > > ZFS filesystem version 5 > ZFS storage pool version 28 > > Thanks! > _______________________________________________ > 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 Fri Apr 10 23:56:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4804CB58 for ; Fri, 10 Apr 2015 23:56:41 +0000 (UTC) Received: from smtplqs-out26.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by mx1.freebsd.org (Postfix) with ESMTP id 100B5A7B for ; Fri, 10 Apr 2015 23:56:38 +0000 (UTC) Received: from webxc18s06.ad.aruba.it ([62.149.141.208]) by smartcmd03.ad.aruba.it with bizsmtp id EPvL1q00D4Vynhq01PvMZm; Sat, 11 Apr 2015 01:55:23 +0200 Received: (qmail 5613 invoked by uid 11811215); 10 Apr 2015 23:55:20 -0000 To: freebsd-fs@freebsd.org Subject: FREE, Indebted for driving on toll road #000545436 Date: Sat, 11 Apr 2015 01:55:20 +0200 From: "E-ZPass Support" Reply-To: "E-ZPass Support" Message-ID: <89a372d730a63b4d19cbcfe41253dc4c@webx196.aruba.it> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:56:41 -0000 Dear Free, You have a unpaid bill for using toll road. You are kindly asked to pay your debt as soon as possible. The invoice is attached to this email. Kind regards, Ronald Akers, E-ZPass Support. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 10 23:58:49 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23A1BD5 for ; Fri, 10 Apr 2015 23:58:49 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BD07A85 for ; Fri, 10 Apr 2015 23:58:49 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t3ANwk7E027555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA) for ; Fri, 10 Apr 2015 19:58:46 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.9/8.14.9/Submit) id t3ANwkDI027552; Fri, 10 Apr 2015 19:58:46 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21800.25526.8680.435299@khavrinen.csail.mit.edu> Date: Fri, 10 Apr 2015 19:58:46 -0400 From: Garrett Wollman To: freebsd-fs@freebsd.org Subject: ZFS compiler warnings X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 10 Apr 2015 19:58:46 -0400 (EDT) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:58:49 -0000 I notice on my 10.1 kernel builds warnings like the following: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:2855:12: warning: comparison of constant -1 with expression of type 'zfs_prop_t' is always true [-Wtautological-constant-out-of-range-compare] if (prop != ZPROP_INVAL && !zfs_prop_inheritable(prop)) ~~~~ ^ ~~~~~~~~~~~ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:3810:11: warning: comparison of constant -1 with expression of type 'zfs_prop_t' is always false [-Wtautological-constant-out-of-range-compare] if (prop == ZPROP_INVAL) { ~~~~ ^ ~~~~~~~~~~~ The warnings indicate that these checks are being optimized away by clang. The code in head is the same. Does anyone have an idea of how this should be fixed, in a way that would be acceptable upstream? (Do we have someone who is the "official" liaison with the OpenZFS project?) My guess is that the definition of the zfs_prop_t enum itself needs to include these two constants explicitly -- but that also has the effect of changing the type of ZPROP_INVAL, which then means that zpool_prop_t needs to have its own version of "invalid property" defined, and that then requires cascading changes in a bunch of other places. The following is a minimal change that fixes the warnings in the kernel alone (beware whitespace lossage) -- I haven't checked the userland side: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c (revision 281265) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c (working copy) @@ -332,7 +332,7 @@ zprop_source_t src = ZPROP_SRC_DEFAULT; zpool_prop_t prop; - if ((prop = zpool_name_to_prop(za.za_name)) == ZPROP_INVAL) + if ((prop = zpool_name_to_prop(za.za_name)) == ZPOOL_PROP_INVAL) continue; switch (za.za_integer_length) { @@ -422,7 +422,7 @@ zpool_prop_t prop = zpool_name_to_prop(propname); switch (prop) { - case ZPROP_INVAL: + case ZPOOL_PROP_INVAL: if (!zpool_prop_feature(propname)) { error = SET_ERROR(EINVAL); break; @@ -662,7 +662,7 @@ prop == ZPOOL_PROP_READONLY) continue; - if (prop == ZPOOL_PROP_VERSION || prop == ZPROP_INVAL) { + if (prop == ZPOOL_PROP_VERSION || prop == ZPOOL_PROP_INVAL) { uint64_t ver; if (prop == ZPOOL_PROP_VERSION) { @@ -6308,7 +6308,7 @@ spa_feature_t fid; switch (prop = zpool_name_to_prop(nvpair_name(elem))) { - case ZPROP_INVAL: + case ZPOOL_PROP_INVAL: /* * We checked this earlier in spa_prop_validate(). */ Index: sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h (revision 281265) +++ sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h (working copy) @@ -152,7 +152,9 @@ ZFS_PROP_SNAPSHOT_COUNT, ZFS_PROP_REDUNDANT_METADATA, ZFS_PROP_PREV_SNAP, - ZFS_NUM_PROPS + ZFS_NUM_PROPS, + ZPROP_INVAL = -1, + ZPROP_CONT = -2 } zfs_prop_t; typedef enum { @@ -196,14 +198,18 @@ ZPOOL_PROP_FREEING, ZPOOL_PROP_FRAGMENTATION, ZPOOL_PROP_LEAKED, - ZPOOL_NUM_PROPS + ZPOOL_NUM_PROPS, + ZPOOL_PROP_INVAL = -1, + ZPOOL_PROP_CONT = -2 } zpool_prop_t; /* Small enough to not hog a whole line of printout in zpool(1M). */ #define ZPROP_MAX_COMMENT 32 +/* #define ZPROP_CONT -2 #define ZPROP_INVAL -1 +*/ #define ZPROP_VALUE "value" #define ZPROP_SOURCE "source" There is also one spot in zio_checksum.c that has a similar problem, but in this case the issue is that it assumes that an out-of-range value can be bitwise-or'ed with a small enum. (The C standard allows the compiler to use an eight-bit integer type as the underlying type of 'enum zio_checksum', so to bitwise-or it with ZIO_CHECKSUM_VERIFY, defined to be 256, is undefined.) A similar change eliminates this warning. (The effect in both cases is to convince the compiler to model the enum with a larger underlying type.) -GAWollman From owner-freebsd-fs@FreeBSD.ORG Sat Apr 11 08:15:39 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F21E9D8 for ; Sat, 11 Apr 2015 08:15:39 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAC15FFD for ; Sat, 11 Apr 2015 08:15:38 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so45356438pac.1 for ; Sat, 11 Apr 2015 01:15: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=kyS/OUIqZ1WVj6dKPoshQz3s8Tnqqc6nzhAkRVry6Rs=; b=MGXpEhGL/ww/jwDBZo1/MY1v155KR2+I2ui57HyO88f1HYEUxjae0uzM3r9WK3qq29 Hhc49BQInsH9Vk3iX7nVfz721ocs+12pQAesezNRKPAstLpc1s9DN5sRu6TxV+j5AssK ZHCgQBGfhJvUCC2Bk4KSKyWD7f+2Rl6iBmtcy8yhSb6lCHEZBobIsohhtTc3I/u0N1GV Rkl58cj+ziulfM/a9lW8MfFZ1LsBAh/UOXZiBeV2wBvPd0oUvUEWMmWHh38HIlqDVw62 k7w6xDWrKuvdvM744Oh/dBtn97naZTxPqWj8JLEQUoFS0oUPle3Yj7bGVll4vlxzZp3Q bukw== MIME-Version: 1.0 X-Received: by 10.68.167.131 with SMTP id zo3mr9179998pbb.123.1428740138441; Sat, 11 Apr 2015 01:15:38 -0700 (PDT) Received: by 10.70.104.4 with HTTP; Sat, 11 Apr 2015 01:15:38 -0700 (PDT) Received: by 10.70.104.4 with HTTP; Sat, 11 Apr 2015 01:15:38 -0700 (PDT) In-Reply-To: <552857B8.6040001@multiplay.co.uk> References: <552857B8.6040001@multiplay.co.uk> Date: Sat, 11 Apr 2015 11:15:38 +0300 Message-ID: Subject: Re: Migrating ZFS from 8.3 to 10.1 From: Sami Halabi To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 08:15:39 -0000 hi, Its worth mentioning that in 10 ZFS allocates few% (?) of disk space as reserved for fs uses that wasn't in 8/9, so if you have small ammount of free space you might end up in an full system with no free space. Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 11 =D7=91=D7=90=D7=A4=D7=A8=D7=B3 2015= 02:07,=E2=80=8F "Steven Hartland" =D7=9B=D7=AA=D7=91: > We did moved from 8.3 -> 10.1 had to go via 10.0 as we did a in place > source upgrade but had no issues. > > 10.x has block size validation which 8.3 so if your disks are 4k sectors > and you didn't manually configure this on install you may end up with poo= ls > complaining about this, but that will just mean reduced performance > (something you had already). > > Yes once your happy 10.1 is working fine you should upgrade your pools to > get all the new features which are well worth having. > > Regards > Steve > > On 10/04/2015 22:43, javocado wrote: > >> Hello, >> >> I am planning to migrate (upgrade) my system from FreeBSD 8.3 RELEASE to >> 10.1 RELEASE (both amd64). My zfs pool exists on it's own physical >> device(s) so my upgrade will consist of: >> >> 1. install FreeBSD 10.1 on boot device (in a temp system) >> 2. remove 8.3 boot device (from production system) >> 3. install new 10.1 boot device and boot up production system >> 4. re-mount zfs FS >> >> My question is, what do I need to know about how this change will affect >> or >> impact the zpool and datasets? Is there any chance zfs data could be los= t >> or destroyed? Might there be a performance loss due to version >> differences? >> Is upgrading the zpool (once booted to 10.1) strongly advised? Any >> downsides or dangers there? >> >> Some other info worth considering (production system): >> >> ZFS filesystem version 5 >> ZFS storage pool version 28 >> >> Thanks! >> _______________________________________________ >> 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" >> > > _______________________________________________ > 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" >