From owner-freebsd-hackers@freebsd.org Mon Jan 16 02:40:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E23ECB2D87; Mon, 16 Jan 2017 02:40:20 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 9BBC61FC5; Mon, 16 Jan 2017 02:40:19 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id c206so155334187wme.0; Sun, 15 Jan 2017 18:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IkUw+lRenFwsponY9eox5D3RbhR1NjEGnbcBVFyhyBw=; b=ja7L/wguo0HfsbwJSmM7OfMgYejiRX0xRo9rZkeODwuK1GsbWiI2pT8mBJkWD5RZpz Ziz2AEXxjwd2EzAFEJj1wU66H08FbU3dM5zAFfzVfBmSw2+lcos5XOUqfZgZ34CiQM58 JOI7AKA7jomqFS/Qe54alTwTOLyJblTNlBYtG8KuHEN/Syla8LXTFRHhgSq0vMjwuZBh I92jlnbQ6V2uqyEJtWFFcjo9IvSm/Ul2QxZfsf+ukb5KvZRBCiHkUCNFgoUdEZ0CzZ+O /SqWY2ZLFEucNV5Zk+92e5pqxkBQ+OpzDo58VCH04sLZNVdUVccL8N8EnCuYUE9AM1BH lAuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IkUw+lRenFwsponY9eox5D3RbhR1NjEGnbcBVFyhyBw=; b=tykdDJo5qCoOXZks6Dsqhx10xt4VdPFnjAmAy5EdsgwEPrxGWlYO29dLtTMhbSZOnR B0DN63LR00FHdwz4U0zzbdVfSojQeM5vVgx//W0y414MBmMpzVUEEMZfumFkIh5qEOOq dHL9bzXdiZVQUu666IDPHvwHA5DDlqgyttXE8hgLybxnBERpIPC2PORdKx8MoaMM9pYl eGfHuvIKeRavFWvSRFl1lw9AC2+n2tQPiR79wlx0cyEVi5a4SvYq7jOvUFUnGrc1RLca y4mix6aKlPOnQ+ah53SohlzgnLDagWh2T3hxDvDRsb8M/YWaGpdJkKn6HXeilEqI4D8s eXoQ== X-Gm-Message-State: AIkVDXJDuGU6D5c8FO85MA4hkTlLYnsKrtU2ktmVEKQL2BwVJG94yvWWH9qcL4bxzUjdJCYko/R5V5cHAn4WFQ== X-Received: by 10.28.41.5 with SMTP id p5mr11353083wmp.38.1484534417292; Sun, 15 Jan 2017 18:40:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.12.46 with HTTP; Sun, 15 Jan 2017 18:40:16 -0800 (PST) From: Aijaz Baig Date: Mon, 16 Jan 2017 08:10:16 +0530 Message-ID: Subject: Understanding the rationale behind dropping of "block devices" To: FreeBSD Hackers , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 02:40:20 -0000 I am a relative noob to the storage world in general and FreeBSD in particular. OF what I have been learning of late, I have become somewhat familiar with such concepts like disk queuing, IOPs, latencies and the likes I am also reading the classic 'The design and implementation of the FreeBSD operating system'. However of what I am reading, FreeBSD has "done away" with "block devices" altogether Of what I have been reading in that book and elsewhere it appears that the "block" devices have been dropped out of the architecture. So what I, with my (still) very limited knowledge of storage, understand this as there are no drivers in FreeBSD that would deal with blocks of data. But when I check the disk nodes under /dev I get this [CODE]ls -l /dev/*disk0 brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0 crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE] where 'b' means block interface and 'c' means char or raw interface. So how do I reconcile this with what I read about "block devices being gone" before. What does 'block' mean here? Of what I know, the block device would be served through the "page cache" (a place where file system caches it's data and meta data) where as the raw device would be served via the "buffer cache" where "disk blocks" are cached by the OS. Thus a block device would be served via the file system where as the raw device won't. Is this correct?? If yes, then what does 'block' above signify? Or rephrasing the question, what was there earlier in FreeBSD before 'block device support' was dropped? I am sure seasoned storage veterans would have a lot more to add. I would be highly obliged if some one could please elaborate and add more context to it. -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Mon Jan 16 02:55:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AAB4CB1233 for ; Mon, 16 Jan 2017 02:55:33 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 E51C51A5E for ; Mon, 16 Jan 2017 02:55:32 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id DFBC213099 for ; Mon, 16 Jan 2017 02:55:30 +0000 (UTC) Subject: Re: Understanding the rationale behind dropping of "block devices" To: freebsd-hackers@freebsd.org References: From: Allan Jude Message-ID: Date: Sun, 15 Jan 2017 21:55:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xVhWjCEJP500c8JXVws17Lsxf2InQgcoF" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 02:55:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xVhWjCEJP500c8JXVws17Lsxf2InQgcoF Content-Type: multipart/mixed; boundary="4tbpeD3TsedFMNVkNAJ8NgkITvKxdeetv"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: Understanding the rationale behind dropping of "block devices" References: In-Reply-To: --4tbpeD3TsedFMNVkNAJ8NgkITvKxdeetv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-01-15 21:40, Aijaz Baig wrote: > I am a relative noob to the storage world in general and FreeBSD in > particular. OF what I have been learning of late, I have become somewha= t > familiar with such concepts like disk queuing, IOPs, latencies and the = likes > I am also reading the classic 'The design and implementation of the Fre= eBSD > operating system'. However of what I am reading, FreeBSD has "done away= " > with "block devices" altogether >=20 > Of what I have been reading in that book and elsewhere it appears that = the > "block" devices have been dropped out of the architecture. So what I, w= ith > my (still) very limited knowledge of storage, understand this as there = are > no drivers in FreeBSD that would deal with blocks of data. >=20 > But when I check the disk nodes under /dev I get this > [CODE]ls -l /dev/*disk0 > brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0 > crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE] >=20 > where 'b' means block interface and 'c' means char or raw interface. So= how > do I reconcile this with what I read about "block devices being gone" > before. What does 'block' mean here? >=20 > Of what I know, the block device would be served through the "page cach= e" > (a place where file system caches it's data and meta data) where as the= raw > device would be served via the "buffer cache" where "disk blocks" are > cached by the OS. Thus a block device would be served via the file syst= em > where as the raw device won't. Is this correct?? If yes, then what does= > 'block' above signify? Or rephrasing the question, what was there earli= er > in FreeBSD before 'block device support' was dropped? >=20 > I am sure seasoned storage veterans would have a lot more to add. I wou= ld > be highly obliged if some one could please elaborate and add more conte= xt > to it. >=20 What version of FreeBSD are you using? All modern versions of FreeBSD have no 'block' devices, and use different device names than you included in your pasted message. crw-r----- 1 root operator 0x92 Jul 27 04:44 /dev/ada0 crw-r----- 1 root operator 0xa2 Jul 27 04:44 /dev/ada1 crw-r----- 1 root operator 0xad Jul 27 04:44 /dev/da0 crw-r----- 1 root operator 0xae Jul 27 04:44 /dev/da1 (SATA disks are /dev/ada* and SAS/SCSI/USB/etc are /dev/da*) --=20 Allan Jude --4tbpeD3TsedFMNVkNAJ8NgkITvKxdeetv-- --xVhWjCEJP500c8JXVws17Lsxf2InQgcoF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJYfDYhAAoJEBmVNT4SmAt+HgsQAIu3BjLFVY0m2EkjuOVr4X0O M1ECqJfyoYxEPhtGC/pcn+zyK9i+XNznszacJqOcN6aAAO5sp4Z1bIu+PwnMuU4Y ps4JTi2dIfQZ5wWVw+6l5lhGRFHrvYf/y2rqLdnFEhQQOezPtxo1fok+3vQyROVS evDJhJ1yZhLRv8gGOeqrrXwGXWCsIaH3AqMr3f5n/+AI16KjjNBC9Myra7iEESgK zN7w2Q2c7O/reFdQdXv80CtQDBMIqAkpjd8+Wf+utGqA28n6khPnUvpJRqrmS6sQ HblZ0NA5GTuao4+LgubP/XDAIoRwHry3zK90VhvTZc25hwAAeGslQJsVEEgsq3Hw T1IjuIP7eFuLSH+GN46I0aCn0HW4mPOmF5uBr3+pETi+9HeLC9QvGN/h5VCHY76L g8fZUTuKW6u3ddYdnhVWFkmN8ayvhgHNVKy/xoUmm0F+xx0r86A04YUAsos/OPjY ocL6o8jDfDecfoavOtkArSI4tEixlvjHXh61q6zZ0XMsj91v6f3niB7avCBk/MqH vz4poWG38Ov9P621d74liq8DMFHLYrgrUNjKUgCsuP0Vn91QPqR5YmGo+ucf4Z8L VFruhGp97FROhzekSSmAxjijZT5wdduWUTLeB3SgUNTCUVaQhHrwLYNnKNwT089j e0Fx9orcowMs1cW2z2HL =3Cm2 -----END PGP SIGNATURE----- --xVhWjCEJP500c8JXVws17Lsxf2InQgcoF-- From owner-freebsd-hackers@freebsd.org Mon Jan 16 07:20:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDD56CB22A3; Mon, 16 Jan 2017 07:20:33 +0000 (UTC) (envelope-from grog@lemis.com) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id CCC651E19; Mon, 16 Jan 2017 07:20:33 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 533D51B72804; Mon, 16 Jan 2017 07:11:06 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 4DC0F4494B2; Mon, 16 Jan 2017 18:11:05 +1100 (AEDT) Date: Mon, 16 Jan 2017 18:11:05 +1100 From: Greg 'groggy' Lehey To: Aijaz Baig Cc: FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <20170116071105.GB4560@eureka.lemis.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5346-1370, +61-3-5309-0418 Mobile: 0401 265 606. Use only as instructed. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 07:20:34 -0000 --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 16 January 2017 at 8:10:16 +0530, Aijaz Baig wrote: > > But when I check the disk nodes under /dev I get this > [CODE]ls -l /dev/*disk0 > brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0 > crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE] Are you sure that this is FreeBSD? The naming convention looks more like Mac OS, though the major device number doesn't match. FreeBSD has been through a number of disk naming conventions, but I'm pretty sure that we never had anything as straightforward as 'disk'. > what was there earlier in FreeBSD before 'block device support' was > dropped? Apart from the name, things used to look similar. Here a quote from "The Complete FreeBSD", written some time at the end of the last century: crw-r----- 1 root operator 3, 131072 Oct 31 19:59 /dev/rwd0s1a brw-r----- 1 root operator 0, 131072 Oct 31 19:59 /dev/wd0s1a The minor number included partition encoding, thus the large number. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --gj572EiMnwbLXET9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlh8cgkACgkQIubykFB6QiM7jwCgoqb+1Zq6wHcox91JMKjSJCM8 7WEAmwbm2veBM5jStU+1syjSSVhxzM3D =fMg4 -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- From owner-freebsd-hackers@freebsd.org Mon Jan 16 08:49:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1514CB1980; Mon, 16 Jan 2017 08:49:21 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 7717417F7; Mon, 16 Jan 2017 08:49:21 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id f73so29182971wmf.1; Mon, 16 Jan 2017 00:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8s/68QNRCN11+Bsk89IqMlROQYvJwcEM6Qt+bNy+G+g=; b=M3gURCAiVx/b1VzinSsZ/gTB9Cvtnoyv0xfTkB3Wj4ybNSwHP7Og7fgWeVOz1gwkBV DeEzIKUn7kjKuFiBAkbciO3p4JEWalFfFQgUZdK+DaKSnuQ4TU/JnFNIBmwoh700UIdR m+T15FhiDTuGDfmo6JpcAh2h8kAcJszNvXO5i0isptFhiijrI++fdFYhsycffgY85orN 4H1FcnjuEgzhGzBUJkUww+Y52WCDiaW70DLKQGsmyiA2Jd+6lqr5khuFFdYBJ7eL6Ygl E8Fs+p1dOsGD6nxUNg9+dr4ojca7kIQxSvUheFEoOHROVSdiGj8CPXzi4SxGO0gSBo9v im3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8s/68QNRCN11+Bsk89IqMlROQYvJwcEM6Qt+bNy+G+g=; b=fYDdiwE6Teq+bVSdjr1c23pk6hb5yRPvs+ZWPioNIEQ5mtDIQGAfQciA8S3eD2p043 yHyylZUsepMdoW6m/KMizq1ebrXwHC3lbN/uwkIJUuF8Jjrd3naL3HWzSjooIN1eUt1j kF6lCie6GWpUVgybXjz0DIodvlo/VwmqvPuzTr+hjFBKmAJUP+uCjByDom0q9ElYvAKm c6nxM6pVTciZqcq9sCghXprEs7xQLxtUkao8KIpKtTqFnuj6Pw6EI1aXUGI990ecDkLS KQ017tS3gMm7iURD2HP6WMFp2xwxfYmm0n/95rAhAKpcaKKBi4R0AJe92wRQomrMg7PL OI/g== X-Gm-Message-State: AIkVDXIU7GpDXZ5LENWSnZXU44W5n+p8It74FZyYOLhBoLdXvS29zuzZjREGv4YBnnkPrzvKwKD7giCu/apWew== X-Received: by 10.28.220.135 with SMTP id t129mr12474397wmg.38.1484556558922; Mon, 16 Jan 2017 00:49:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.12.46 with HTTP; Mon, 16 Jan 2017 00:49:18 -0800 (PST) In-Reply-To: <20170116071105.GB4560@eureka.lemis.com> References: <20170116071105.GB4560@eureka.lemis.com> From: Aijaz Baig Date: Mon, 16 Jan 2017 14:19:18 +0530 Message-ID: Subject: Re: Understanding the rationale behind dropping of "block devices" To: "Greg 'groggy' Lehey" Cc: FreeBSD Hackers , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 08:49:22 -0000 Oh yes I was actually running an old release inside a VM and yes I had changed the device names myself while jotting down notes (to give it a more descriptive name like what the OSX does). So now I've checked it on a recent release and yes there is indeed no block device. root@bsd-client:/dev # gpart show => 34 83886013 da0 GPT (40G) 34 1024 1 freebsd-boot (512K) 1058 58719232 2 freebsd-ufs (28G) 58720290 3145728 3 freebsd-swap (1.5G) 61866018 22020029 - free - (10G) root@bsd-client:/dev # ls -lrt da* crw-r----- 1 root operator 0x4d Dec 19 17:49 da0p1 crw-r----- 1 root operator 0x4b Dec 19 17:49 da0 crw-r----- 1 root operator 0x4f Dec 19 23:19 da0p3 crw-r----- 1 root operator 0x4e Dec 19 23:19 da0p2 So this shows that I have a single SATA or SAS drive and there are apparently 3 partitions ( or is it four?? Why does it show unused space when I had used the entire disk?) Nevertheless my question still holds. What does 'removing support for block device' mean in this context? Was what I mentioned earlier with regards to my understanding correct? Viz. all disk devices now have a character (or raw) interface and are no longer served via the "page cache" but rather the "buffer cache". Does that mean all disk accesses are now direct by passing the file system?? On Mon, Jan 16, 2017 at 12:41 PM, Greg 'groggy' Lehey wrote: > On Monday, 16 January 2017 at 8:10:16 +0530, Aijaz Baig wrote: > > > > But when I check the disk nodes under /dev I get this > > [CODE]ls -l /dev/*disk0 > > brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0 > > crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE] > > Are you sure that this is FreeBSD? The naming convention looks more > like Mac OS, though the major device number doesn't match. FreeBSD > has been through a number of disk naming conventions, but I'm pretty > sure that we never had anything as straightforward as 'disk'. > > > what was there earlier in FreeBSD before 'block device support' was > > dropped? > > Apart from the name, things used to look similar. Here a quote from > "The Complete FreeBSD", written some time at the end of the last > century: > > crw-r----- 1 root operator 3, 131072 Oct 31 19:59 /dev/rwd0s1a > brw-r----- 1 root operator 0, 131072 Oct 31 19:59 /dev/wd0s1a > > The minor number included partition encoding, thus the large number. > > Greg > -- > Sent from my desktop computer. > Finger grog@FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Mon Jan 16 09:20:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55A9BCB2874; Mon, 16 Jan 2017 09:20:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B71319ED; Mon, 16 Jan 2017 09:20:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-228-247.lns20.per1.internode.on.net [121.45.228.247]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0G9KUFm024905 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 16 Jan 2017 01:20:36 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Understanding the rationale behind dropping of "block devices" To: Aijaz Baig , "Greg 'groggy' Lehey" References: <20170116071105.GB4560@eureka.lemis.com> Cc: FreeBSD Hackers , freebsd-scsi@freebsd.org From: Julian Elischer Message-ID: Date: Mon, 16 Jan 2017 17:20:25 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 09:20:41 -0000 On 16/01/2017 4:49 PM, Aijaz Baig wrote: > Oh yes I was actually running an old release inside a VM and yes I had > changed the device names myself while jotting down notes (to give it a more > descriptive name like what the OSX does). So now I've checked it on a > recent release and yes there is indeed no block device. > > root@bsd-client:/dev # gpart show > => 34 83886013 da0 GPT (40G) > 34 1024 1 freebsd-boot (512K) > 1058 58719232 2 freebsd-ufs (28G) > 58720290 3145728 3 freebsd-swap (1.5G) > 61866018 22020029 - free - (10G) > > root@bsd-client:/dev # ls -lrt da* > crw-r----- 1 root operator 0x4d Dec 19 17:49 da0p1 > crw-r----- 1 root operator 0x4b Dec 19 17:49 da0 > crw-r----- 1 root operator 0x4f Dec 19 23:19 da0p3 > crw-r----- 1 root operator 0x4e Dec 19 23:19 da0p2 > > So this shows that I have a single SATA or SAS drive and there are > apparently 3 partitions ( or is it four?? Why does it show unused space > when I had used the entire disk?) > > Nevertheless my question still holds. What does 'removing support for block > device' mean in this context? Was what I mentioned earlier with regards to > my understanding correct? Viz. all disk devices now have a character (or > raw) interface and are no longer served via the "page cache" but rather the > "buffer cache". Does that mean all disk accesses are now direct by passing > the file system?? Basically, FreeBSD never really buffered/cached by device. Buffering and caching is done by vnode in the filesystem. We have no device-based block cache. If you want file X at offset Y, then we can satisfy that from cache. VM objects map closely to vnode objects so the VM system IS the file system buffer cache. If you want device M, at offset N we will fetch it for you from the device, DMA'd directly into your address space, but there is no cached copy. Having said that, it would be trivial to add a 'caching' geom layer to the system but that has never been needed. The added complexity of carrying around two alternate interfaces to the same devices was judged by those who did the work to be not worth the small gain available to the very few people who used raw devices. Interestingly, since that time ZFS has implemented a block-layer cache for itself which is of course not integrated with the non-existing block level cache in the system :-). > > On Mon, Jan 16, 2017 at 12:41 PM, Greg 'groggy' Lehey > wrote: > >> On Monday, 16 January 2017 at 8:10:16 +0530, Aijaz Baig wrote: >>> But when I check the disk nodes under /dev I get this >>> [CODE]ls -l /dev/*disk0 >>> brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0 >>> crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE] >> Are you sure that this is FreeBSD? The naming convention looks more >> like Mac OS, though the major device number doesn't match. FreeBSD >> has been through a number of disk naming conventions, but I'm pretty >> sure that we never had anything as straightforward as 'disk'. >> >>> what was there earlier in FreeBSD before 'block device support' was >>> dropped? >> Apart from the name, things used to look similar. Here a quote from >> "The Complete FreeBSD", written some time at the end of the last >> century: >> >> crw-r----- 1 root operator 3, 131072 Oct 31 19:59 /dev/rwd0s1a >> brw-r----- 1 root operator 0, 131072 Oct 31 19:59 /dev/wd0s1a >> >> The minor number included partition encoding, thus the large number. >> >> Greg >> -- >> Sent from my desktop computer. >> Finger grog@FreeBSD.org for PGP public key. >> See complete headers for address and phone numbers. >> This message is digitally signed. If your Microsoft mail program >> reports problems, please read http://lemis.com/broken-MUA >> > > From owner-freebsd-hackers@freebsd.org Mon Jan 16 10:16:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1D8FCAF980 for ; Mon, 16 Jan 2017 10:16:14 +0000 (UTC) (envelope-from b.yordanov2@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 7971F1625 for ; Mon, 16 Jan 2017 10:16:14 +0000 (UTC) (envelope-from b.yordanov2@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id r126so152665168wmr.0 for ; Mon, 16 Jan 2017 02:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=kcUCpvVpbs4zb79BBAlQ2Nyquji91qCS5P1V9lTOGmg=; b=qRfry+GtvtuYGtwLsHA4i7YyCsBVbNxK5WSEeQvViEUTiWEc2rbPgk8ddc+jxSSyAD UzOyKJcVUaL9eO17+UHobO/d1dj+FnIAc7HlVCC6F4I6gG/iDwi1Cwjfpe41BOsbKw9j Z9gFNyN59sQjn8nKFBloQd94oa4Utz10DqxU/FR2ZMHPIPrEyLTq7kKCMXstN2P9TmM/ gpVPC56K91pY8cZ96N6rzX2LrWCofz2Qy5i5RxxLWYoP5BBDri1isZX6/PCia/nReVh2 CbtGa6fM8JhAMCymFFQAKTyLI4ZHb9LskIbuJR4Or9UP0mNr1Pn0hu6WBUvpYoJSbJtd o5lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=kcUCpvVpbs4zb79BBAlQ2Nyquji91qCS5P1V9lTOGmg=; b=e4jxEAb0ggOB07rl79jRjGxrtl9YEnrKKd0hBnKslA0wOrNvpXAEJCb8bLVMka2TfQ 7s6XkDa0bHRcTrPCII4KfffDeBNNaRvLnOOV9Tqnr43TT/q/+qK2Gz+SSpHWhWYOmuUc Iae9QElqptyuAAN6qUm9A96xvLZnlGnj1KNLNuTBsDYknBtp0c/dzwzYU+uCAmeT/evz 1qE1m0IUid7/UlxZUDd0roVJliQlSezTJxZtAwtbK+gGR1eXPYu0VIZJRE3ASYoOtzfa S2C+eMWvKguYu0MI+jA6/JqgA0Z+XXg3bjpNBUGHxGrZOuBdpFCw+YBOGsCgnkK2BQa+ A4uA== X-Gm-Message-State: AIkVDXJaopg/mLkUuslitxCqhXr32pU5yNF1HnkIH6scEN1bduqG5N20NVzXLjRXcedi3g== X-Received: by 10.223.175.49 with SMTP id z46mr7778467wrc.84.1484561772500; Mon, 16 Jan 2017 02:16:12 -0800 (PST) Received: from [192.168.2.211] ([94.155.134.70]) by smtp.gmail.com with ESMTPSA id y97sm27857647wmh.24.2017.01.16.02.16.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 02:16:12 -0800 (PST) From: Boyko Yordanov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 16 Jan 2017 12:16:08 +0200 Subject: Zfs nogrpid | sysvgroups option? Message-Id: <232FB341-16F8-4868-A78D-444ED9E230E3@gmail.com> To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 10:16:15 -0000 Hello! Running latest FreeBSD 11.0-RELEASE-p1, zfs as root filesystem, there = doesn't seem to be a way to switch from bsd-groups to sysv-groups style = for group ownership. Directories behave as if they have the setgid flag = set (chmod g+s or chmod 2770) while they don't. Actually, the setgid = flag is not taken in account at all - all newly created files inherit = their group from the directory they reside in. I=E2=80=99m looking for a way to change this so that newly created files = get the primary group of the user who created them (sysv behavior - = default on Linux). I checked the zfs dataset properties, mount options, = kernel options, fs acls and chmod flags and couldn't find a way to = achieve this. Am I missing something? Boyko= From owner-freebsd-hackers@freebsd.org Mon Jan 16 10:56:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18F18CB065C for ; Mon, 16 Jan 2017 10:56:45 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 8F4B1181D for ; Mon, 16 Jan 2017 10:56:44 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id c85so153390987wmi.1 for ; Mon, 16 Jan 2017 02:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lCp0Rt0cqxquCwhJ62p3HvVzGPib4b7h2MLesXrMl1o=; b=p6IQOghtsAmNv494CtsoF3NamDPbAy/welZbO18D7WSAqIok4pzLUP9djvMoS9CGol MATHKVSwRYI9FYjEEdWfUD1SK5RJ7Pd/jXlqX6MUGYf+yfIR27vEDEBzNqdhv3Il1dQt xfvy3lU8TQrJSmaOmyalX60pyKEm/1ypILOEbPMNUO19GhObut3JqACTj5iX9wjvSOnL 5A4NHrolv3GBmOy5o4qdfpW23m1Nox3XMrNXPuJ15KoHhtISJzizxWYKiKZOwU2pqDdL Cg016CuHcQASExlZKMD/Jywmu07lpcZlCb2Of3EvA+EJAd3YLeP8I4Z7joHTC9r4iA5C zXBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lCp0Rt0cqxquCwhJ62p3HvVzGPib4b7h2MLesXrMl1o=; b=rnOQ5XT3g4SwJS6bueRJXVz9//utDjWH7Rzzc85ZwsXadm1AtmhcQ4wefsrVSU5U7Q tM56f1O5sw1Y7ZZ4DNUEgozv2GOfvyrOmJNg5BkCdogqL2m7gOH9LNXfnHhTkhdEur+o TKZiq5nMP/8IO+9bW8lIFkB9RiGwnZe5OpjypiTbDwgwkT5TI7ne0hx0NnwHUmiF/Y8b U98cge3qQIEG7f1uOAU+XsNaaQScSPL+DhWSYNrdiPDozwgXKVoTWKYAwYoRwJdwvZAc rmVL/ZHQoXZtzF0OpG1C2QY2P0otupywLV4T+vX4BQCqI4unJCGE9rF4X9UqGh53tpT6 PWZA== X-Gm-Message-State: AIkVDXLKRTkiTxn37lBRaZnSZ8xOYOvLHqD36I3vTtJm01mYcC2ENhNR0T3K6jRi5T25gFdwJtVFnV03x9/x2g== X-Received: by 10.223.163.30 with SMTP id c30mr1114064wrb.40.1484564202868; Mon, 16 Jan 2017 02:56:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.12.46 with HTTP; Mon, 16 Jan 2017 02:56:42 -0800 (PST) In-Reply-To: References: <20170116071105.GB4560@eureka.lemis.com> <29469.1484559072@critter.freebsd.dk> <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de> From: Aijaz Baig Date: Mon, 16 Jan 2017 16:26:42 +0530 Message-ID: Subject: Fwd: Understanding the rationale behind dropping of "block devices" To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 10:56:45 -0000 Oh thank you everyone for clearing the air a bit. Although for a noob like myself, that was mighty concise! Nevertheless, let me re-iterate what has been summarized in the last two mails so I know I got exactly what was being said. Let me begin that I come from the Linux world where there has traditionally been two separate caches, the "buffer cache" and the "page cache" although almost all IO is now driven through the "page cache". The buffer cache still remains however it now only caches disk blocks ( https://www.quora.com/What-is-the-difference-between- Buffers-and-Cached-columns-in-proc-meminfo-output). So 'read' and 'write' were satisfied through the buffer cache whereas 'fwrite/read', 'mmap' went through the page cache (which was actually populated by reading the buffer cache thereby wasting almost twice the memory and compute cycles). Hence the merging. Nevertheless, as had been mentioned by Julian, it appears that there is no "buffer cache" so to speak (is that correct Julian??) > If you want device M, at offset N we will fetch it for you from the device, DMA'd directly into your address space, but there is no cached copy. Instead it appears FreeBSD has a generic 'VM object' that is used to address myriad entities including disks and as such all operations have to go through the VM subsystem now. Does that also mean that there is no way an application can directly use raw disks? At least it appears so > The added complexity of carrying around two alternate interfaces to the same devices was judged by those who did the work to be not worth the small gain available to the very few people who used raw devices Thank you for all your inputs and waiting to hear more! Al though a bit more context would really help noobs (both to enterprise storage and FreeBSD) like me! I must add that I am getting confused specifically between two different things here: >From the replies above it appears that all disk accesses have to go through the VM subsystem now (so no raw disk accesses) however the arch handbook says raw interfaces are the way to go for disks ( https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html)? Secondly, I presume that the VM subsystem has it's own caching and buffering mechanism that is independent to the file system so an IO can choose to skip buffering at the file-system layer however it will still be served by the VM cache irrespective of whatever the VM object maps to. Is that true? I believe this is what is meant by 'caching' at the VM layer. Keen to hear On Mon, Jan 16, 2017 at 3:56 PM, Jan Bramkamp wrote: > On 16/01/2017 10:31, Poul-Henning Kamp wrote: > >> -------- >> In message , Julian >> Elischer >> writes: >> >> Having said that, it would be trivial to add a 'caching' geom layer to >>> the system but that has never been needed. >>> >> >> A tinker-toy-cache like that would be architecturally disgusting. >> >> The right solution would be to enable mmap(2)'ing of disk(-like) >> devices, leveraging the VM systems exsting code for caching and >> optimistic prefetch/clustering, including the very primitive >> cache-control/visibility offered by madvise(2), mincore(2), mprotect(2), >> msync(2) etc. >> >> Enabling mmap(2) on devices would be nice, but it would also create > problems with revoke(2). The revoke(2) syscall allows revoking access to > open devices (e.g. a serial console). This is required to securely logout > users. The existing file descriptors are marked as revoked an will return > EIO on every access. How would you implement gracefully revoking mapped > device memory? Killing all those processes with SIGBUS/SIGSEGV would keep > the system secure, but it would be far from elegant. > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > -- Best Regards, Aijaz Baig -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Mon Jan 16 11:00:16 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45B19CB0785; Mon, 16 Jan 2017 11:00:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 CA2151A35; Mon, 16 Jan 2017 11:00:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v0GB09Je011580 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Jan 2017 13:00:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v0GB09Je011580 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v0GB09BS011579; Mon, 16 Jan 2017 13:00:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Jan 2017 13:00:09 +0200 From: Konstantin Belousov To: Julian Elischer Cc: Aijaz Baig , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <20170116110009.GN2349@kib.kiev.ua> References: <20170116071105.GB4560@eureka.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 11:00:16 -0000 On Mon, Jan 16, 2017 at 05:20:25PM +0800, Julian Elischer wrote: > On 16/01/2017 4:49 PM, Aijaz Baig wrote: > > Oh yes I was actually running an old release inside a VM and yes I had > > changed the device names myself while jotting down notes (to give it a more > > descriptive name like what the OSX does). So now I've checked it on a > > recent release and yes there is indeed no block device. > > > > root@bsd-client:/dev # gpart show > > => 34 83886013 da0 GPT (40G) > > 34 1024 1 freebsd-boot (512K) > > 1058 58719232 2 freebsd-ufs (28G) > > 58720290 3145728 3 freebsd-swap (1.5G) > > 61866018 22020029 - free - (10G) > > > > root@bsd-client:/dev # ls -lrt da* > > crw-r----- 1 root operator 0x4d Dec 19 17:49 da0p1 > > crw-r----- 1 root operator 0x4b Dec 19 17:49 da0 > > crw-r----- 1 root operator 0x4f Dec 19 23:19 da0p3 > > crw-r----- 1 root operator 0x4e Dec 19 23:19 da0p2 > > > > So this shows that I have a single SATA or SAS drive and there are > > apparently 3 partitions ( or is it four?? Why does it show unused space > > when I had used the entire disk?) > > > > Nevertheless my question still holds. What does 'removing support for block > > device' mean in this context? Was what I mentioned earlier with regards to > > my understanding correct? Viz. all disk devices now have a character (or > > raw) interface and are no longer served via the "page cache" but rather the > > "buffer cache". Does that mean all disk accesses are now direct by passing > > the file system?? > > Basically, FreeBSD never really buffered/cached by device. > > Buffering and caching is done by vnode in the filesystem. > We have no device-based block cache. If you want file X at offset Y, > then we can satisfy that from cache. > VM objects map closely to vnode objects so the VM system IS the file > system buffer cache. This is not true. We do have buffer cache of the blocks read through the device (special) vnode. This is how, typically, the metadata for filesystems which are clients of the buffer cache, is handled, i.e. UFS msdosfs cd9600 etc. It is up to the filesystem to not create aliased cached copies of the blocks both in the device vnode buffer list and in the filesystem vnode. In fact, sometimes filesystems, e.g. UFS, consciously break this rule and read blocks of the user vnode through the disk cache. For instance, this happens for the SU truncation of the indirect blocks. > If you want device M, at offset N we will fetch it for you from the > device, DMA'd directly into your address space, > but there is no cached copy. > Having said that, it would be trivial to add a 'caching' geom layer to > the system but that has never been needed. The useful interpretation of the claim that FreeBSD does not cache disk blocks is that the cache is not accessible over the user-initiated i/o (read(2) and write(2)) through the opened devfs nodes. If a program issues such request, it indeed goes directly to/from disk driver, which is supplied a kernel buffer formed by remapped user pages. Note that if this device was or is mounted and filesystem kept some metadata in the buffer cache, then the devfs i/o would make the cache inconsistent. > The added complexity of carrying around two alternate interfaces to > the same devices was judged by those who did the work to be not worth > the small gain available to the very few people who used raw devices. > Interestingly, since that time ZFS has implemented a block-layer cache > for itself which is of course not integrated with the non-existing > block level cache in the system :-). We do carry two interfaces in the cdev drivers, which are lumped into one. In particular, it is not easy to implement mapping of the block devices exactly because the interfaces are mixed. If cdev disk device is mapped, VM would try to use cdevsw d_mmap or later mapping interfaces to handle user page faults, which is incorrect for the purpose of the disk block mapping. From owner-freebsd-hackers@freebsd.org Mon Jan 16 11:04:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4446FCB0A8F; Mon, 16 Jan 2017 11:04:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1E1E1111; Mon, 16 Jan 2017 11:04:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v0GB4Zgl050449 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2017 12:04:36 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: julian@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v0GB4WYA046170 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Jan 2017 18:04:32 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: Understanding the rationale behind dropping of "block devices" To: Julian Elischer , Aijaz Baig , "Greg 'groggy' Lehey" References: <20170116071105.GB4560@eureka.lemis.com> Cc: FreeBSD Hackers , freebsd-scsi@freebsd.org From: Eugene Grosbein Message-ID: <587CA8BC.1070609@grosbein.net> Date: Mon, 16 Jan 2017 18:04:28 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 11:04:48 -0000 16.01.2017 16:20, Julian Elischer wrote: > If you want device M, at offset N we will fetch it for you from the device, DMA'd directly into your address space, > but there is no cached copy. > Having said that, it would be trivial to add a 'caching' geom layer to the system but that has never been needed. In fact, FreeBSD does have geom_cache/gcache(8) for long time. It is block-level read cache passing write requests through transparently. It is unmaintained, though and there were some reports that it is suspected to cause kernel panics if there are more than one active GEOM_CACHE instances in a system. > The added complexity of carrying around two alternate interfaces to the same devices was judged by those who did the work to be not worth the small gain available to the very few people who used raw devices. > Interestingly, since that time ZFS has implemented a block-layer cache for itself which is of course not integrated with the non-existing block level cache in the system :-). From owner-freebsd-hackers@freebsd.org Mon Jan 16 09:31:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBEC4CB2BF2; Mon, 16 Jan 2017 09:31:21 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A4EF8109A; Mon, 16 Jan 2017 09:31:21 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 41EA2273AC; Mon, 16 Jan 2017 09:31:14 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v0G9VC81029470; Mon, 16 Jan 2017 09:31:13 GMT (envelope-from phk@phk.freebsd.dk) To: Julian Elischer cc: Aijaz Baig , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" In-reply-to: From: "Poul-Henning Kamp" References: <20170116071105.GB4560@eureka.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29468.1484559072.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2017 09:31:12 +0000 Message-ID: <29469.1484559072@critter.freebsd.dk> X-Mailman-Approved-At: Mon, 16 Jan 2017 12:08:45 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 09:31:22 -0000 -------- In message , Julian Elis= cher = writes: >Having said that, it would be trivial to add a 'caching' geom layer to = >the system but that has never been needed. A tinker-toy-cache like that would be architecturally disgusting. The right solution would be to enable mmap(2)'ing of disk(-like) devices, leveraging the VM systems exsting code for caching and optimistic prefetch/clustering, including the very primitive cache-control/visibility offered by madvise(2), mincore(2), mprotect(2), msync(2) etc. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Tue Jan 17 11:45:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E41B5CB4C02; Tue, 17 Jan 2017 11:45:41 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 70BD61104; Tue, 17 Jan 2017 11:45:41 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id c85so5332970wmi.1; Tue, 17 Jan 2017 03:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MLDYWwu3C7INMUeE2EMDxPoHzJWkqo8NYwQxuuAEVmc=; b=jPo8r0s8KEyY+RsOxWCPeWVtn6xuHj0JJRSXx9znjju92dvPw4WwALRFuE/5Z6KSdr oRIxMq2UOAuRTImqcblemYv1HtX+J72aIf0oWO22do76sQUWEIdC2OkXZIrUghYoyN1H 3s6VAf4HnnTpMMHiopIAPAguyPYIx9KRegAUDUTHE6uro+n3XfkZbdSvMiBiQBvEiApd h0x0soDfvTmKKV+HCuP4g9VxnRkQhdUs+J9wHWzjFABISN8gGnd/3UwgLPM5cGMahRky xqaejkc9gf6ghZ02rGA2Xor2oKBLj/Z9IN9A+Mjj61xyQfIJbGroL/oqtoSrjyrruRum Eneg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MLDYWwu3C7INMUeE2EMDxPoHzJWkqo8NYwQxuuAEVmc=; b=b/m0Y2o76bn54eEBpqWrhydzelQFB7PdHwEPd/eUvyyAoOeqrUC2Ff8S4OoFT5C3dj /5fzNqnCdlBIu9TkO+iRAu2gySz8JDrPU8X0oHuZjlZVr5lX2Ajta+As1EKb0P8HH64T PmA9DtZL6MQlk4O1xH3GLnh/eeC6mFKJMZx0rX5eZVGlXIU10ljnCevwRFfmij+qaXoH d9MlFZEBr3FZi4oFbWIxXhUui3Q/riF306zvocfEW6jlsQCp9SLF4AyiOowb5qSAnnyg 3jSJJrRUSc8Z4oz73BF7eIZIi0bwdY+RJUufzxyEEK5FKssiMJ7EQfFI1btnZGbtpn3v tohQ== X-Gm-Message-State: AIkVDXKYjPnAiBrWVEI1kL2PG1TnY8/gF3CH/SVyP809UPbO80q8Xj/uLABeNOJ+/br+nI2CbW287tLCPp/Qxw== X-Received: by 10.223.166.106 with SMTP id k97mr30867636wrc.170.1484653539455; Tue, 17 Jan 2017 03:45:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.12.46 with HTTP; Tue, 17 Jan 2017 03:45:38 -0800 (PST) In-Reply-To: <20170116110009.GN2349@kib.kiev.ua> References: <20170116071105.GB4560@eureka.lemis.com> <20170116110009.GN2349@kib.kiev.ua> From: Aijaz Baig Date: Tue, 17 Jan 2017 17:15:38 +0530 Message-ID: Subject: Re: Understanding the rationale behind dropping of "block devices" To: Konstantin Belousov Cc: Julian Elischer , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 11:45:42 -0000 First of all, a very big thank you to Konstantin for such a detailed reply! It has been a pleasure to go through. My replies are inline On Mon, Jan 16, 2017 at 4:30 PM, Konstantin Belousov wrote: > This is not true. > > We do have buffer cache of the blocks read through the device (special) > vnode. This is how, typically, the metadata for filesystems which are > clients of the buffer cache, is handled, i.e. UFS msdosfs cd9600 etc. > It is up to the filesystem to not create aliased cached copies of the > blocks both in the device vnode buffer list and in the filesystem vnode. > > In fact, sometimes filesystems, e.g. UFS, consciously break this rule > and read blocks of the user vnode through the disk cache. For instance, > this happens for the SU truncation of the indirect blocks. > This makes a lot more sense now. This basically means that no matter the underlying entity (for the vnode), be it a device special file or a remote location it always has to go through the VFS layer. So as you clearly said, the file-system has the sole discretion what to do with them. And as example, UFS does break this rule by having caching disk blocks which have already been cached by the VFS. > > If you want device M, at offset N we will fetch it for you from the > > device, DMA'd directly into your address space, > > but there is no cached copy. > > Having said that, it would be trivial to add a 'caching' geom layer to > > the system but that has never been needed. > The useful interpretation of the claim that FreeBSD does not cache > disk blocks is that the cache is not accessible over the user-initiated > i/o (read(2) and write(2)) through the opened devfs nodes. If a program > issues such request, it indeed goes directly to/from disk driver, which > is supplied a kernel buffer formed by remapped user pages. So basically read(2) and write(2) calls on device nodes bypass the VFS buffer cache as well and the IO indeed goes directly through the kernel memory pages (which as you said are in fact remapped user-land pages) So does that mean only the file-system code now uses the disk buffer cache? > Note that if this device was or is mounted and filesystem kept some > metadata in the buffer cache, then the devfs i/o would make the > cache inconsistent. > Device being mounted as a file-system you mean? Could you please elaborate? > > The added complexity of carrying around two alternate interfaces to > > the same devices was judged by those who did the work to be not worth > > the small gain available to the very few people who used raw devices. > > Interestingly, since that time ZFS has implemented a block-layer cache > > for itself which is of course not integrated with the non-existing > > block level cache in the system :-). > We do carry two interfaces in the cdev drivers, which are lumped into > one. In particular, it is not easy to implement mapping of the block > devices exactly because the interfaces are mixed. By "mapping" of the block devices, you mean serving the IO intended for the said disk blocks right? So as you said, we can either serve the IO via the VFS directly using buffer cache or we could do that via the file system cache > If cdev disk device is mapped, VM would try to use cdevsw'd_mmap > or later mapping interfaces to handle user page faults, which is incorrect > for the purpose of the disk block mapping. Could you please elaborate? > > I must add that I am getting confused specifically between two different > > things here: > > >From the replies above it appears that all disk accesses have to go through > > the VM subsystem now (so no raw disk accesses) however the arch handbook > > says raw interfaces are the way to go for disks ( > > https://www.freebsd.org/doc/en/books/arch-handbook/ driverbasics-block.html)? > Do not mix the concept of raw disk access and using some VM code to > implement this access. See my other reply for some more explanation of > the raw disk access, physio in the kernel source files terminology, > sys/kern/kern_physio.c. > yes I have taken a note of your earlier replies (thank you for being so elaborate) and as I have re-iterated earlier, I now understand that raw disk access is now direct between the kernel memory and the underlying device. So as you mentioned, the file system code (and perhaps only a few other entities) use the disk buffer cache that the VM implements. So an end user cannot interact with the buffer cache in any way is that what it is? > > Secondly, I presume that the VM subsystem has it's own caching and > > buffering mechanism that is independent to the file system so an IO can > > choose to skip buffering at the file-system layer however it will still be > > served by the VM cache irrespective of whatever the VM object maps to. Is > > that true? I believe this is what is meant by 'caching' at the VM layer. > First, the term page cache has different meaning in the kernel code, > and that page cache was removed from the kernel very recently. > More correct but much longer term is 'page queue of the vm object'. If > given vnode has a vm object associated with it, then buffer cache ensures > that buffers for the given chunk of the vnode data range are created from > appropriately indexed pages from the queue. This way, buffer cache becomes > consistent with the page queue. > The vm object is created on the first vnode open by filesystem-specific > code, at least for UFS/devfs/msdosfs/cd9600 etc. I understand page cache as a cache implemented by the file system to speed up IO access (at least this is what Linux defines it as). Does it have a different meaning in FreeBSD? So a vnode is a VFS entity right? And I presume a VM object is any object from the perspective of the virtual memory subsystem. Since we no longer run in real mode isn't every vnode actually supposed to have an entity in the VM subsystem? May be I am not understanding what 'page cache' means in FreeBSD? I mean every vnode in the VFS layer must have a backing VM object right? May be only mmap(2)'ed device nodes don't have a backing VM object or do they? If this assumption is correct than I cannot get my mind around what you mentioned regarding buffer caches coming into play for vnodes *only* if it has a backing vm object > > Caching policy for buffers is determined both by buffer cache and by > (somewhat strong) hints from the filesystems interfacing with the cache. > The pages constituting the buffer are wired, i.e. VM subsystem is informed > by buffer cache to not reclaim pages while the buffer is alive. > > VM page caching, i.e. storing them in the vnode page queue, is only > independent from the buffer cache when VM need/can handle something > that does not involve the buffer cache. E.g. on page fault in the > region backed by the file, VM allocates neccessary fresh (AKA without > valid content) pages and issues read request into the filesystem which > owns the vnode. It is up to the filesystem to implement read in any > reasonable way. > > Until recently, UFS and other local filesystems provided raw disk block > indexes for the generic VM code which then read content from the disk > blocks into the pages. This has its own shares of problems (but not > the consistency issue, since pages are allocated in the vnode vm > object page queue). I changes that path to go through the buffer cache > explicitely several months ago. > > But all this is highly depended on the filesystem. As the polar case, > tmpfs reuses the swap-backed object, which holds the file data, as the > vnode' vm object. The result is that paging requests from the tmpfs > mapped file is handled as if it is swap-backed anonymous memory. > > ZFS cannot reuse vm object page queue for its very special cache ARC. > So it keeps the consistency between writes and mmaps by copying the > data on write(2) both into ARC buffer, and into the pages from vm object. Well this is rather confusing (sorry again) may be too much detail for a noob like myself to appreciate at this stage of my journey. Nevertheless to summarize this, raw disk block access bypasses the buffer cache (as you had so painstakingly explained about read(2) and write(2) above) but is still cache by the VFS in the page queue. However this is also at the sole discretion of the file-system right? To summarize, the page cache (or rather the page queue for a given vnode) and the buffer cache are in fact separate entities although they are very tightly coupled for the most part except in cases like what you mentioned (about file backed data). So if we think of these as vertical layers, how would they look? From what you talk about page faults, it appears that the VM subsystem is apparently placed above or perhaps adjacent to the VFS layer Is that correct? Also about these caches, the buffer cache is a global cache available to both the VM subsystem as well as the VFS layer whereas the page queue for the vnode is the responsibility of the underlying file-system. Is that true? > Hope this helps. Of course this has helped. AL though it has raised a lot more questions as you can see at least it has got me thinking in (hopefully) the right direction. Once again a very big thank you!! Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Tue Jan 17 12:05:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DB5DCB4B37 for ; Tue, 17 Jan 2017 12:05:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 31E0D1F8C for ; Tue, 17 Jan 2017 12:05:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 99D341FE025; Tue, 17 Jan 2017 13:05:05 +0100 (CET) Subject: Re: Fwd: Understanding the rationale behind dropping of "block devices" To: Aijaz Baig , FreeBSD Hackers References: <20170116071105.GB4560@eureka.lemis.com> <29469.1484559072@critter.freebsd.dk> <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de> From: Hans Petter Selasky Message-ID: Date: Tue, 17 Jan 2017 13:04:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:05:24 -0000 On 01/16/17 11:56, Aijaz Baig wrote: > Nevertheless, as had been mentioned by Julian, it appears that there is no > "buffer cache" so to speak (is that correct Julian??) Hi, When you open the raw disk block device, like /dev/da0 for a USB disk, there is no buffering involved. Every read() and write() request which you make is transformed into a SCSI command and directly passed to the underlying device driver. I know Linux implements a cache for its "/dev/da0" and FreeBSD not. However, if you do "mount -t xxx /dev/da0 /mnt" the filesystem layer might implement a cache for accessing files inside the mounted directory. Some filesystems like ZFS requires more memory for caching data to be efficient than UFS, for example. In FreeBSD you can use a tool called "dd" to measure basic disk performance. Compare it with Linux if you like: Read test (block device): dd if=/dev/da0 of=/dev/null bs=65536 count=10000 Write test (WARNING: This will destroy your disk contents) dd if=/dev/zero of=/dev/da0 bs=65536 count=10000 Write test (filesystem): dd if=/dev/zero of=/mnt/myfile.bin bs=65536 count=10000 Read test (filesystem): dd if=/mnt/myfile.bin of=/dev/null bs=65536 count=10000 You can try running: umount /mnt mount -t XXX /dev/daX /mnt Between the tests and see what happens. Also see the "sync" command. For more serious benchmarking you'll find some utilities in FreeBSD ports, /usr/ports/benchmarks . --HPS From owner-freebsd-hackers@freebsd.org Wed Jan 18 11:46:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7119CB69A5; Wed, 18 Jan 2017 11:46:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 5E5681F3E; Wed, 18 Jan 2017 11:46:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v0IBkN08064452 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jan 2017 13:46:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v0IBkN08064452 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v0IBkNQG064451; Wed, 18 Jan 2017 13:46:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Jan 2017 13:46:23 +0200 From: Konstantin Belousov To: Aijaz Baig Cc: Julian Elischer , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <20170118114623.GF2349@kib.kiev.ua> References: <20170116071105.GB4560@eureka.lemis.com> <20170116110009.GN2349@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 11:46:33 -0000 On Tue, Jan 17, 2017 at 05:15:38PM +0530, Aijaz Baig wrote: > First of all, a very big thank you to Konstantin for such a detailed reply! > It has been a > pleasure to go through. My replies are inline > > On Mon, Jan 16, 2017 at 4:30 PM, Konstantin Belousov > wrote: > > > This is not true. > > > > We do have buffer cache of the blocks read through the device (special) > > vnode. This is how, typically, the metadata for filesystems which are > > clients of the buffer cache, is handled, i.e. UFS msdosfs cd9600 etc. > > It is up to the filesystem to not create aliased cached copies of the > > blocks both in the device vnode buffer list and in the filesystem vnode. > > > > In fact, sometimes filesystems, e.g. UFS, consciously break this rule > > and read blocks of the user vnode through the disk cache. For instance, > > this happens for the SU truncation of the indirect blocks. > > > This makes a lot more sense now. This basically means that no matter > the underlying entity (for the vnode), be it a device special file or a > remote location it always has to go through the VFS layer. So as you > clearly said, the file-system has the sole discretion what to do with them. > And as example, UFS does break this rule by having caching disk blocks > which have already been cached by the VFS. I do not understand what the 'it' that has to go through the VFS layer. > > > > If you want device M, at offset N we will fetch it for you from the > > > device, DMA'd directly into your address space, > > > but there is no cached copy. > > > Having said that, it would be trivial to add a 'caching' geom layer to > > > the system but that has never been needed. > > The useful interpretation of the claim that FreeBSD does not cache > > disk blocks is that the cache is not accessible over the user-initiated > > i/o (read(2) and write(2)) through the opened devfs nodes. If a program > > issues such request, it indeed goes directly to/from disk driver, which > > is supplied a kernel buffer formed by remapped user pages. > So basically read(2) and write(2) calls on device nodes bypass the VFS > buffer cache as well and the IO indeed goes directly through the kernel > memory pages (which as you said are in fact remapped user-land pages) > So does that mean only the file-system code now uses the disk buffer > cache? Right now, in the tree, only filesystems calls into vfs_bio.c. > > > Note that if this device was or is mounted and filesystem kept some > > metadata in the buffer cache, then the devfs i/o would make the > > cache inconsistent. > > > Device being mounted as a file-system you mean? Could you please > elaborate? Yes, device which carries a volume, and the volume is mounted. > > > > The added complexity of carrying around two alternate interfaces to > > > the same devices was judged by those who did the work to be not worth > > > the small gain available to the very few people who used raw devices. > > > Interestingly, since that time ZFS has implemented a block-layer cache > > > for itself which is of course not integrated with the non-existing > > > block level cache in the system :-). > > We do carry two interfaces in the cdev drivers, which are lumped into > > one. In particular, it is not easy to implement mapping of the block > > devices exactly because the interfaces are mixed. > By "mapping" of the block devices, you mean serving the IO intended for the > said disk blocks right? I mean, using mmap(2) interface on the file which references device special node. > > So as you said, we can either serve the IO via the > VFS > directly using buffer cache or we could do that via the file system cache > > > If cdev disk device is mapped, VM would try to use cdevsw'd_mmap > > or later mapping interfaces to handle user page faults, which is incorrect > > for the purpose of the disk block mapping. > Could you please elaborate? Read the code, I do not see much sense in rewording things that are stated in the code. > > > > I must add that I am getting confused specifically between two different > > > things here: > > > >From the replies above it appears that all disk accesses have to go > through > > > the VM subsystem now (so no raw disk accesses) however the arch handbook > > > says raw interfaces are the way to go for disks ( > > > https://www.freebsd.org/doc/en/books/arch-handbook/ > driverbasics-block.html)? > > Do not mix the concept of raw disk access and using some VM code to > > implement this access. See my other reply for some more explanation of > > the raw disk access, physio in the kernel source files terminology, > > sys/kern/kern_physio.c. > > > yes I have taken a note of your earlier replies (thank you for being so > elaborate) and > as I have re-iterated earlier, I now understand that raw disk access is now > direct > between the kernel memory and the underlying device. Such io is always direct between memory and device. The differences is in who owns the memory used for io, and how this is interpreted by system. > So as you mentioned, > the > file system code (and perhaps only a few other entities) use the disk > buffer cache > that the VM implements. So an end user cannot interact with the buffer > cache in > any way is that what it is? This question does not make any sense. Buffer cache is the kernel subsystem, used as a library for other parts of the kernel. > > > > Secondly, I presume that the VM subsystem has it's own caching and > > > buffering mechanism that is independent to the file system so an IO can > > > choose to skip buffering at the file-system layer however it will > still be > > > served by the VM cache irrespective of whatever the VM object maps to. > Is > > > that true? I believe this is what is meant by 'caching' at the VM layer. > > First, the term page cache has different meaning in the kernel code, > > and that page cache was removed from the kernel very recently. > > More correct but much longer term is 'page queue of the vm object'. If > > given vnode has a vm object associated with it, then buffer cache ensures > > that buffers for the given chunk of the vnode data range are created from > > appropriately indexed pages from the queue. This way, buffer cache > becomes > > consistent with the page queue. > > The vm object is created on the first vnode open by filesystem-specific > > code, at least for UFS/devfs/msdosfs/cd9600 etc. > I understand page cache as a cache implemented by the file system to speed > up IO access (at least this is what Linux defines it as). Does it have a > different > meaning in FreeBSD? I explicitely answered this question in advance, above. > > So a vnode is a VFS entity right? And I presume a VM object is any object > from > the perspective of the virtual memory subsystem. No, vm object is struct vm_object. > Since we no longer run in > real mode > isn't every vnode actually supposed to have an entity in the VM subsystem? > May be > I am not understanding what 'page cache' means in FreeBSD? At this point, I am not able to add any information to you. Unless you read the code, any further explanations would not provide any useful sense. > > I mean every vnode in the VFS layer must have a backing VM object right? No. > May be only mmap(2)'ed device nodes don't have a backing VM object or do > they? Device vnodes do have backing VM object, but they cannot be mapped. > If this assumption is correct than I cannot get my mind around what you > mentioned > regarding buffer caches coming into play for vnodes *only* if it has a > backing vm object I never said this. > > > > > Caching policy for buffers is determined both by buffer cache and by > > (somewhat strong) hints from the filesystems interfacing with the cache. > > The pages constituting the buffer are wired, i.e. VM subsystem is informed > > by buffer cache to not reclaim pages while the buffer is alive. > > > > VM page caching, i.e. storing them in the vnode page queue, is only > > independent from the buffer cache when VM need/can handle something > > that does not involve the buffer cache. E.g. on page fault in the > > region backed by the file, VM allocates neccessary fresh (AKA without > > valid content) pages and issues read request into the filesystem which > > owns the vnode. It is up to the filesystem to implement read in any > > reasonable way. > > > > Until recently, UFS and other local filesystems provided raw disk block > > indexes for the generic VM code which then read content from the disk > > blocks into the pages. This has its own shares of problems (but not > > the consistency issue, since pages are allocated in the vnode vm > > object page queue). I changes that path to go through the buffer cache > > explicitely several months ago. > > > > But all this is highly depended on the filesystem. As the polar case, > > tmpfs reuses the swap-backed object, which holds the file data, as the > > vnode' vm object. The result is that paging requests from the tmpfs > > mapped file is handled as if it is swap-backed anonymous memory. > > > > ZFS cannot reuse vm object page queue for its very special cache ARC. > > So it keeps the consistency between writes and mmaps by copying the > > data on write(2) both into ARC buffer, and into the pages from vm object. > Well this is rather confusing (sorry again) may be too much detail for a > noob > like myself to appreciate at this stage of my journey. > > Nevertheless to summarize this, raw disk block access bypasses the > buffer cache (as you had so painstakingly explained about read(2) and > write(2) above) but is still cache by the VFS in the page queue. However > this > is also at the sole discretion of the file-system right? > > To summarize, the page cache (or rather the page queue for a given vnode) > and the buffer cache are in fact separate entities although they are very > tightly coupled > for the most part except in cases like what you mentioned (about file > backed data). > > So if we think of these as vertical layers, how would they look? From what > you talk > about page faults, it appears that the VM subsystem is apparently placed > above or > perhaps adjacent to the VFS layer Is that correct? Also about these caches, > the buffer cache is a global cache available to both the VM subsystem as > well as > the VFS layer whereas the page queue for the vnode is the responsibility of > the > underlying file-system. Is that true? > > > Hope this helps. > Of course this has helped. AL though it has raised a lot more questions as > you can see > at least it has got me thinking in (hopefully) the right direction. Once > again a very big > thank you!! > > Best Regards, > Aijaz Baig From owner-freebsd-hackers@freebsd.org Wed Jan 18 17:25:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E5AACB6FFB; Wed, 18 Jan 2017 17:25:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45C091D36; Wed, 18 Jan 2017 17:25:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-228-247.lns20.per1.internode.on.net [121.45.228.247]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0IHPOh1038197 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Jan 2017 09:25:27 -0800 (PST) (envelope-from julian@freebsd.org) To: "ports@FreeBSD.org" , freebsd , pkg@freebsd.org From: Julian Elischer Subject: standard settings for ports. Message-ID: Date: Thu, 19 Jan 2017 01:25:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:25:29 -0000 I know there are some standard setting one can set.. make ports shows 8 but I know there are many more. like what version of perl you want to use throughout your system or whether you want to use openssl from ports or system or what version of python.. or whether to use some version of gcc or ... Is there a list somewhere as to where all these are found? for example setting NO-X11-yes (or someting like that) things I'd like to turn off include DOCS, EXAMPLES, MAN, X11, Also I'd like to specify that I'd like everything to try use python 2.7 and jdk8 can I set the USES stuff from the command line?(no?) pointers appreciated... Julian From owner-freebsd-hackers@freebsd.org Wed Jan 18 17:28:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A620CB615E; Wed, 18 Jan 2017 17:28:31 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A3EBF1F9C; Wed, 18 Jan 2017 17:28:30 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v0IHSKqp040029 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jan 2017 18:28:21 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v0IHSKvL040026; Wed, 18 Jan 2017 18:28:20 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 18 Jan 2017 18:28:20 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Julian Elischer cc: "ports@FreeBSD.org" , freebsd , pkg@freebsd.org Subject: Re: standard settings for ports. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:28:31 -0000 On Thu, 19 Jan 2017 01:25+0800, Julian Elischer wrote: > pointers appreciated... Try something like this in /etc/make.conf: DEFAULT_VERSIONS=apache=2.4 bdb=6 firebird=2.5 gcc=4.9 ghostscript=9 lua=5.2 mysql=5.7 perl5=5.22 php=5.6 pgsql=9.5 python=2.7 python2=2.7 python3=3.5 ruby=2.2 ssl=openssl tcltk=8.6 -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@freebsd.org Wed Jan 18 18:34:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 898D6CB5929 for ; Wed, 18 Jan 2017 18:34:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C3D281819 for ; Wed, 18 Jan 2017 18:34:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA05852 for ; Wed, 18 Jan 2017 20:34:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1cTv3f-0000XP-Mo for freebsd-hackers@FreeBSD.org; Wed, 18 Jan 2017 20:34:07 +0200 To: FreeBSD Hackers From: Andriy Gapon Subject: don't abort writing of a core dump after EFAULT Message-ID: Date: Wed, 18 Jan 2017 20:33:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:34:10 -0000 https://reviews.freebsd.org/D9233 Anyone interested in reviewing this is welcome! -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Jan 19 03:15:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2C70CB7D89; Thu, 19 Jan 2017 03:15:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0018155B; Thu, 19 Jan 2017 03:15:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-228-247.lns20.per1.internode.on.net [121.45.228.247]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0J3Dnbx040347 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Jan 2017 19:13:52 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: standard settings for ports. To: =?UTF-8?Q?Trond_Endrest=c3=b8l?= References: Cc: "ports@FreeBSD.org" , freebsd , pkg@freebsd.org From: Julian Elischer Message-ID: <8c5be14a-b847-2aa7-60f4-a2dee72f3230@freebsd.org> Date: Thu, 19 Jan 2017 11:13:44 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:15:18 -0000 On 19/01/2017 1:28 AM, Trond Endrestøl wrote: > On Thu, 19 Jan 2017 01:25+0800, Julian Elischer wrote: > >> pointers appreciated... > Try something like this in /etc/make.conf: > > DEFAULT_VERSIONS=apache=2.4 bdb=6 firebird=2.5 gcc=4.9 ghostscript=9 lua=5.2 mysql=5.7 perl5=5.22 php=5.6 pgsql=9.5 python=2.7 python2=2.7 python3=3.5 ruby=2.2 ssl=openssl tcltk=8.6 > that's good but where is it documented? thanks anyway! From owner-freebsd-hackers@freebsd.org Thu Jan 19 07:22:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B1C1CB7873; Thu, 19 Jan 2017 07:22:32 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E676C10E5; Thu, 19 Jan 2017 07:22:31 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v0J7M8NA073320 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Jan 2017 08:22:08 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v0J7M79f073317; Thu, 19 Jan 2017 08:22:07 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 19 Jan 2017 08:22:07 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Julian Elischer cc: "ports@FreeBSD.org" , freebsd , pkg@freebsd.org Subject: Re: standard settings for ports. In-Reply-To: <8c5be14a-b847-2aa7-60f4-a2dee72f3230@freebsd.org> Message-ID: References: <8c5be14a-b847-2aa7-60f4-a2dee72f3230@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-ID: X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 07:22:32 -0000 On Thu, 19 Jan 2017 11:13+0800, Julian Elischer wrote: > On 19/01/2017 1:28 AM, Trond Endrestøl wrote: > > On Thu, 19 Jan 2017 01:25+0800, Julian Elischer wrote: > > > > > pointers appreciated... > > Try something like this in /etc/make.conf: > > > > DEFAULT_VERSIONS=apache=2.4 bdb=6 firebird=2.5 gcc=4.9 ghostscript=9 lua=5.2 > > mysql=5.7 perl5=5.22 php=5.6 pgsql=9.5 python=2.7 python2=2.7 python3=3.5 > > ruby=2.2 ssl=openssl tcltk=8.6 > > > that's good but where is it documented? Have a look at /usr/ports/Mk/bsd.default-versions.mk. Also, if you like to force emacs to be without X11, you should also set EMACS_PORT_NAME=emacs-nox11, see /usr/ports/Mk/bsd.emacs.mk. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@freebsd.org Fri Jan 20 09:50:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0130CB76F8 for ; Fri, 20 Jan 2017 09:50:14 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6B01883 for ; Fri, 20 Jan 2017 09:50:12 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39581169 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 15:45:44 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0K9oAGn075182 for ; Fri, 20 Jan 2017 16:50:10 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0K9o8aU075177 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 16:50:08 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Fri, 20 Jan 2017 16:50:08 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Subject: make.conf options and poudriere Message-ID: <20170120095008.GA75122@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: AO "Svyaztransneft", SibPTUS User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 09:50:15 -0000 Dear Colleagues, I'm trying to set per-port specific options as written in https://forums.freebsd.org/threads/52871/ For example, I have tried: "net-mgmt_flow-tools_UNSET= GCC" and "net-mgmt_flow-tools_UNSET= USE_GCC" but the port still requires lang/gcc. However, if I comment out "USE_GCC" directly in the net-mgmt/flow-tools/Makefile, it works for me. What am I doing wrong? I would like to be able to set/unset this variable for different sets in poudriere, without editing the ports's Makefile itself. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Fri Jan 20 10:27:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9730ECB9214 for ; Fri, 20 Jan 2017 10:27:01 +0000 (UTC) (envelope-from b.yordanov2@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C3361B43 for ; Fri, 20 Jan 2017 10:27:01 +0000 (UTC) (envelope-from b.yordanov2@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id c206so36615594wme.0 for ; Fri, 20 Jan 2017 02:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=GzigQnnJRl6EVBUaYa0UfoBbCjCHO35b/rOHpk6bRQQ=; b=Qsv3nnm10EJBuVho/eS6S/8jWTmqeVJn7uBuNdGFegkn4Or84xk53uSIFSo2RWL55r K3LM/2V88m7SWvVRm2JV3E+sip8JaZQpccqtJNBt8JVVWCWI/0Wy/bwKphh4bJmnXdl+ aovxU8cqWMsKT6R+6dZfzEcV+OpB0pf7BVIDVCbTaJ4WLKlgN7BEk9INOySNjRhk8JGQ G1n5vYezwklL1lPhvZZuzc6jWEZ/B50qRnbhSLXr+Pu77z2IRbtg7+XrH6izoPg0O00/ we4uuT5MXZsjzXcPCiFQvY+vmcQakzQJ0nkIW9dqE2nRH8Yreeu3ZWpBCE5CA2YA2Uxv IEfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=GzigQnnJRl6EVBUaYa0UfoBbCjCHO35b/rOHpk6bRQQ=; b=Up72K4gw65zQFQdcvJKRGR5wVgHnTCHei/xLVEjB5gY7zDwLZhPzUXncL5cXPuANjt B32E5jmpkBm7ZesEWMcq85OYMM0DhiT9kv/OP+8Flvtb2Byt58zdneIyh9HuqQc4RN9K DzhFPos26wBiGdJJGswfgOCYohAaDmxR0E8fVDdEzh9ikeG8ga3KI2CDbtWri+vnKag+ BuZOIL5d9F+/mLxNZNACAEOfog5voPuoWgScvtBogITI1r5nECQnpHwcn4ktCAdzmaY1 mkoZT1q7PTEd+oO+nrri1NwQFVUxVLOgEZWiiFQwG81hv5RMu5XctgIUZHDsWdSremFb dc7w== X-Gm-Message-State: AIkVDXJ2r7JZLMfTgZ7zYxAX3VA2qAmyD7eA2QCz6NJaxyDeAPzp2knyWvSj0MNHPvaNJg== X-Received: by 10.223.142.131 with SMTP id q3mr10986762wrb.195.1484908019166; Fri, 20 Jan 2017 02:26:59 -0800 (PST) Received: from [192.168.2.211] ([94.155.134.70]) by smtp.gmail.com with ESMTPSA id 63sm5186689wmg.2.2017.01.20.02.26.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 02:26:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Zfs nogrpid | sysvgroups option? From: Boyko Yordanov In-Reply-To: <232FB341-16F8-4868-A78D-444ED9E230E3@gmail.com> Date: Fri, 20 Jan 2017 12:26:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E6F9D2D-97E9-405A-8E8B-7AFA00E7E026@gmail.com> References: <232FB341-16F8-4868-A78D-444ED9E230E3@gmail.com> To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 10:27:01 -0000 Hi, If this is the wrong list for the subject please point me to the right = one, thanks! Boyko > On Jan 16, 2017, at 12:16 PM, Boyko Yordanov = wrote: >=20 > I=E2=80=99m looking for a way to change this so that newly created = files get the primary group of the user who created them (sysv behavior = - default on Linux). I checked the zfs dataset properties, mount = options, kernel options, fs acls and chmod flags and couldn't find a way = to achieve this. From owner-freebsd-hackers@freebsd.org Fri Jan 20 10:29:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4942DCB92EE for ; Fri, 20 Jan 2017 10:29:36 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD3051CB2 for ; Fri, 20 Jan 2017 10:29:35 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from zero-gravitas.local (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 11D8F2F28 for ; Fri, 20 Jan 2017 10:29:30 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/11D8F2F28; dkim=none; dkim-atps=neutral Subject: Re: make.conf options and poudriere To: freebsd-hackers@freebsd.org References: <20170120095008.GA75122@admin.sibptus.transneft.ru> From: Matthew Seaman Message-ID: <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> Date: Fri, 20 Jan 2017 10:29:31 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170120095008.GA75122@admin.sibptus.transneft.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iI2G1q1NapegJUTpjWTBIwxIA0VudNnJm" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 10:29:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iI2G1q1NapegJUTpjWTBIwxIA0VudNnJm Content-Type: multipart/mixed; boundary="UqxNCNrRdTnbxRuq9AD2jWFcXdE5FmDGE"; protected-headers="v1" From: Matthew Seaman To: freebsd-hackers@freebsd.org Message-ID: <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> Subject: Re: make.conf options and poudriere References: <20170120095008.GA75122@admin.sibptus.transneft.ru> In-Reply-To: <20170120095008.GA75122@admin.sibptus.transneft.ru> --UqxNCNrRdTnbxRuq9AD2jWFcXdE5FmDGE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017/01/20 09:50, Victor Sudakov wrote: > I'm trying to set per-port specific options as written in > https://forums.freebsd.org/threads/52871/ >=20 > For example, I have tried: > "net-mgmt_flow-tools_UNSET=3D GCC" > and=20 > "net-mgmt_flow-tools_UNSET=3D USE_GCC" >=20 > but the port still requires lang/gcc. However, if I comment out > "USE_GCC" directly in the net-mgmt/flow-tools/Makefile, it works for me= =2E >=20 > What am I doing wrong? I would like to be able to set/unset this > variable for different sets in poudriere, without editing the ports's > Makefile itself. Settings like 'net-mgmt_flow-tools_UNSET=3D GCC' only apply to the option= s defined by the port, and net-mgmt/flow-tools doesn't define a 'GCC' optio= n. Where the port Makefile says: USE_GCC=3Dany it means the port will (in preference order) * use the version of gcc specified in DEFAULT_VERSIONS -- this defaults to gcc-4.9 at the moment * use an installed version of gcc from ports, where it checks each of the versions available from ports, preferring the oldest available one. * uses gcc from base There is no longer any option to use DEFAULT_VERSIONS to specify the base system gcc, since gcc is no longer in base for any supported version= =2E However, if you find that net-mgmt/flow-tools will compile and run successfully with the system Clang, please submit a PR to have the 'USE_GCC' line deleted. Cheers, Matthew --UqxNCNrRdTnbxRuq9AD2jWFcXdE5FmDGE-- --iI2G1q1NapegJUTpjWTBIwxIA0VudNnJm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJYgeaRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnywgP/i3KQkfl+cAPXdWG856C5Z5X 6Qr+DvS2Yk1gBLgoM3OV7gppPx8FVHWSMRdl0OmBlYqIpCvCyEiWgn2/pR6MYove mNZrvYxbjAXvUHn3ytAvU1dey4lYYmit0rCt4zLzye7MC7uLdScUopp9Kv5SoKtz XTQVJMJsmpBwQw9prQpw5hyb0Zy0JudyMYoF4QDqr/1V/p+Gw2wG3/2uQbjvq9N0 OFmRWbnLpp8IULClo82lLMntAMvNeHzalNGICHFiG8YrLa91oXE25pdmS28c938b qoZgw7SfUUiQI/yjWgaHnKpSnPhLUM+rQnlvH7UkxzFhfFCjtD281qgyaZ17Nw75 VGiwUJ/GOtUigW8FCM9HKkmRqUp32k4qeQxP/N6Z6WC6tNFKnFdHImOHVOHC3j3T 30KUMzctk9K0rxbYeR0dYTbCN+3WXI8u452aCpyXSNcLSFhcnKRDLFxa18JaNyKQ Yyte5Lzs2MaEiIAJTs55YnynWEhY3k8Ib36yEOTLx9pmrW7t625W+unutDzVxtTN yN50wF8MJmnu1B64w3+cjXPhVbRO8f4wxwt+3aS6x5SPElk/ksSmaEY6kPSaiWrX oDKZZwu/DCOPSJV10jQhkFM86VwkTelswF2diFI/DfUgAy0Fvj4YYTRNd1+7RHYO 0CdYWc0L6N3XtacmSTLO =qzBO -----END PGP SIGNATURE----- --iI2G1q1NapegJUTpjWTBIwxIA0VudNnJm-- From owner-freebsd-hackers@freebsd.org Fri Jan 20 09:17:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA3A0CB7128 for ; Fri, 20 Jan 2017 09:17:24 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3D51C03 for ; Fri, 20 Jan 2017 09:17:23 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39581143 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 15:12:53 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0K9HKjB073768 for ; Fri, 20 Jan 2017 16:17:20 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0K9HJA7073766 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 16:17:19 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Fri, 20 Jan 2017 16:17:19 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Subject: make.conf options and poudriere Message-ID: <20170120091718.GA73239@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-Mailman-Approved-At: Fri, 20 Jan 2017 12:26:01 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 09:17:24 -0000 Dear Colleagues, I'm trying to set per-port specific options as written in https://forums.freebsd.org/threads/52871/ For example, I have tried: "net-mgmt_flow-tools_UNSET= GCC" and "net-mgmt_flow-tools_UNSET= USE_GCC" but the port still requires lang/gcc. However, if I comment out "USE_GCC" directly in the net-mgmt/flow-tools/Makefile, it works for me. What am I doing wrong? I would like to be able to set/unset this variable for different sets in poudriere, without editing the ports's Makefile itself. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Fri Jan 20 12:47:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81247CB723C for ; Fri, 20 Jan 2017 12:47:47 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id E33F41646 for ; Fri, 20 Jan 2017 12:47:45 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39581306 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 18:43:07 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0KClY2a076774 for ; Fri, 20 Jan 2017 19:47:34 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0KClV5S076773 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 19:47:31 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Fri, 20 Jan 2017 19:47:31 +0700 From: sudakov+freebsd@sibptus.tomsk.ru To: freebsd-hackers@freebsd.org Subject: Re: make.conf options and poudriere Message-ID: <20170120124731.GA75275@admin.sibptus.transneft.ru> References: <20170120095008.GA75122@admin.sibptus.transneft.ru> <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 12:47:47 -0000 Matthew Seaman wrote: > > I'm trying to set per-port specific options as written in > > https://forums.freebsd.org/threads/52871/ > > > > For example, I have tried: > > "net-mgmt_flow-tools_UNSET= GCC" > > and > > "net-mgmt_flow-tools_UNSET= USE_GCC" > > > > but the port still requires lang/gcc. However, if I comment out > > "USE_GCC" directly in the net-mgmt/flow-tools/Makefile, it works for me. > > > > What am I doing wrong? I would like to be able to set/unset this > > variable for different sets in poudriere, without editing the ports's > > Makefile itself. > > Settings like 'net-mgmt_flow-tools_UNSET= GCC' only apply to the options > defined by the port, and net-mgmt/flow-tools doesn't define a 'GCC' option. > > Where the port Makefile says: > > USE_GCC=any The question is not about this particular option but in fact any arbitrary Makefile variable. Maybe FLOW_CAPTURE_SPOOL= just for example. How do I redefine or unset such variables depending on the port, without actually editing the port's Makefile itself? I would prefer to do it from /usr/local/etc/poudriere.d/foo-bar-make.conf > > However, if you find that net-mgmt/flow-tools will compile and run > successfully with the system Clang, please submit a PR to have the > 'USE_GCC' line deleted. Yes, I have patched it to compile with the system Clang, and am going to submit a PR about it, but that's another matter. My question is more generic. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Fri Jan 20 14:03:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4FF0CB89EF for ; Fri, 20 Jan 2017 14:03:30 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D80F1385 for ; Fri, 20 Jan 2017 14:03:30 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from zero-gravitas.local (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 44D1F2FCE for ; Fri, 20 Jan 2017 14:03:25 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/44D1F2FCE; dkim=none; dkim-atps=neutral Subject: Re: make.conf options and poudriere To: freebsd-hackers@freebsd.org References: <20170120095008.GA75122@admin.sibptus.transneft.ru> <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> <20170120124731.GA75275@admin.sibptus.transneft.ru> From: Matthew Seaman Message-ID: <554f6171-cb2e-596b-595c-9cde36cf3f6f@FreeBSD.org> Date: Fri, 20 Jan 2017 14:03:18 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170120124731.GA75275@admin.sibptus.transneft.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2XudjqLasgmDtmriSfnG3B4URMqWwbfv2" X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,RCVD_IN_RP_RNBL, RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 14:03:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2XudjqLasgmDtmriSfnG3B4URMqWwbfv2 Content-Type: multipart/mixed; boundary="RdU1XndORX4GHnElDG2iAs7Oxn56UJmHR"; protected-headers="v1" From: Matthew Seaman To: freebsd-hackers@freebsd.org Message-ID: <554f6171-cb2e-596b-595c-9cde36cf3f6f@FreeBSD.org> Subject: Re: make.conf options and poudriere References: <20170120095008.GA75122@admin.sibptus.transneft.ru> <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> <20170120124731.GA75275@admin.sibptus.transneft.ru> In-Reply-To: <20170120124731.GA75275@admin.sibptus.transneft.ru> --RdU1XndORX4GHnElDG2iAs7Oxn56UJmHR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017/01/20 12:47, sudakov+freebsd@sibptus.tomsk.ru wrote: > The question is not about this particular option but in fact any arbitr= ary > Makefile variable. Maybe FLOW_CAPTURE_SPOOL=3D just for example. >=20 > How do I redefine or unset such variables depending on the port, > without actually editing the port's Makefile itself? I would prefer to > do it from /usr/local/etc/poudriere.d/foo-bar-make.conf Ah -- then you need to set variables conditionally on what the current working directory is. =2Eif $(.CURDIR:M*/net-mgmt/flow-tools) FLOW_CAPTURE_SPOOL=3D something =2Eendif You may need to use ?=3D rather than =3D for the assignment. Unfortunate= ly this cannot be guaranteed to work, but mostly it does. Cheers, Matthew --RdU1XndORX4GHnElDG2iAs7Oxn56UJmHR-- --2XudjqLasgmDtmriSfnG3B4URMqWwbfv2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJYghisXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnTf0P/34kQmd4s3E19crEtpgsFncW bo2IIwO/bmcRu6jyYd0ETOpHn1kbyHEbbfr25E4x2qB6b451r9TtgDJnygFlDKG1 jNWFq/oYLQ/I8gjfq1zs/1p0mNL4nCSU1iUAms2aZCcq4XyWddpdeYU+pa4M0jvy 1yuFnCh0v5ywd+TKHPn6awsnl0MZnLsALD8MnUlsbTZG0GaXfa6d9NHhBBqseZJm phQGBfeV8V+mv7W2ESxxGoEYDE5mY+X4sNvvEKDpfH8KqdkyfYxevm7AIpylDDEU sKbmgDch41RQSEGSWs1g3X50OUsWPExtjm7ewsI/AHzH/aIpUZqfvmXAfdc40qCL dTH+Gb/YOTwECygKfyj1YYrk9TWtnGLQDai7RnC3qD7x2czv+tUZ5yn6hOUVQuPC OO7oKTWDCL8sbHHn4Fscc9oaJtKUwIGYQkfYu5FKtPCWi4k1M/eIDugWO+9zY8ZA M/j28i/URH/uNTO4QjHjQiafdr3Hez3J6f7lGO6rGHcNAWinDJoxK+y8ArBdNolt cBrRk62LHuqOsr7mk7VVyUeiKyLdeKoo16g/LDIF7BwXBfzByGa/RkarhQDC9T31 SjD3I6YFcDM/3XO5Ci9AETXEtLFeYjrsfcNTPAq/LZ9viUIGPav4lqYO9pJ049ys T8oEdmAvuewJAkEycQOm =SNPZ -----END PGP SIGNATURE----- --2XudjqLasgmDtmriSfnG3B4URMqWwbfv2-- From owner-freebsd-hackers@freebsd.org Fri Jan 20 15:30:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44A48CB9D13 for ; Fri, 20 Jan 2017 15:30:18 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id A7CAD1EB1 for ; Fri, 20 Jan 2017 15:30:16 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39581433 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 21:25:48 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0KFUF5S077924 for ; Fri, 20 Jan 2017 22:30:15 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0KFUCVH077923 for freebsd-hackers@freebsd.org; Fri, 20 Jan 2017 22:30:12 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Fri, 20 Jan 2017 22:30:12 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Subject: Re: make.conf options and poudriere Message-ID: <20170120153012.GA77842@admin.sibptus.transneft.ru> References: <20170120095008.GA75122@admin.sibptus.transneft.ru> <1a270201-74ff-0e9b-7eb6-0af7c9846a12@FreeBSD.org> <20170120124731.GA75275@admin.sibptus.transneft.ru> <554f6171-cb2e-596b-595c-9cde36cf3f6f@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554f6171-cb2e-596b-595c-9cde36cf3f6f@FreeBSD.org> Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:30:18 -0000 Matthew Seaman wrote: > On 2017/01/20 12:47, sudakov+freebsd@sibptus.tomsk.ru wrote: > > The question is not about this particular option but in fact any arbitrary > > Makefile variable. Maybe FLOW_CAPTURE_SPOOL= just for example. > > > > How do I redefine or unset such variables depending on the port, > > without actually editing the port's Makefile itself? I would prefer to > > do it from /usr/local/etc/poudriere.d/foo-bar-make.conf > > Ah -- then you need to set variables conditionally on what the current > working directory is. > > .if $(.CURDIR:M*/net-mgmt/flow-tools) > FLOW_CAPTURE_SPOOL= something > .endif And to unset the variable altogether? > > You may need to use ?= rather than = for the assignment. Unfortunately > this cannot be guaranteed to work, but mostly it does. I thought there was a FreeBSD ports specific mechanism, but there seems to be none. Generic makefile syntax should be used. Thank you for clarification. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Fri Jan 20 16:32:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 148E9CB9401 for ; Fri, 20 Jan 2017 16:32:04 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 761521BE0 for ; Fri, 20 Jan 2017 16:32:02 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39581469; Fri, 20 Jan 2017 22:27:34 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0KGW0XK078392; Fri, 20 Jan 2017 23:32:00 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0KGVwsA078391; Fri, 20 Jan 2017 23:31:58 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Fri, 20 Jan 2017 23:31:58 +0700 From: Victor Sudakov To: Joe Nosay Cc: FreeBSD Hackers Subject: Re: make.conf options and poudriere Message-ID: <20170120163158.GA78266@admin.sibptus.transneft.ru> References: <20170120091718.GA73239@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 16:32:04 -0000 Joe Nosay wrote: > Category ports-mgmt > *jailaudit-1.5.2 > *Script to > generate portaudit reports for jails > Long description > > *:* Changes > > *Maintained by:* cryx-ports@h3q.com > > *pkg_jail-1.89 > *Manage > your own package jail > Long description > > *:* Changes > > *Maintained by:* dinoex@FreeBSD.org > > > > Use one of those to build your edited version. > > Install from that source. > > > This will bounce from one and not the other. Joe, Are you suggesting some alternative to poudriere? Of course I can create a dedicated ports tree in poudriere, edit the Makefile manually and never update that special tree. But isn't it something of an overkill if I just want to protect my precious changes from being overwritten by the next ports tree update? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Sat Jan 21 03:04:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40B32CBA215; Sat, 21 Jan 2017 03:04:20 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 132C51B1D; Sat, 21 Jan 2017 03:04:20 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-pg0-x242.google.com with SMTP id 194so8281002pgd.0; Fri, 20 Jan 2017 19:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :to:cc; bh=bJOdgRP6JH7kZiRo43OK3vrIWakt7Gu0nda9nKRecVQ=; b=SIfrxiiyklWKaDTzX33GMyXpdUjCDo4yYMLlVj6lMtu4WC+eeOAB0V7foRL4B90wyS Jozjp8vjZtWb7MA+BNkISxfuZmkekULrqk8tc/NqNxMbK7aubMzi7ElG2BrI2i8LeM5N QWAxEe9uvl814yFJI8K7Pvu9KyzqQQd+V4ZcMxIK5candNJZQn1oXRBL6pRbddmffqOi rhexdbJzViF576QXvgF6gAhxfsf874RSQEO0CXJUWMHWpMYTqVrt6vCrMvmnaTef7Rux UPikT82d0VJucAKRwQwcqEPC72Jp0HsGcwunutmwkPF5DyhWOnZsGiMvfhpmaZRJTESW 3eTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:to:cc; bh=bJOdgRP6JH7kZiRo43OK3vrIWakt7Gu0nda9nKRecVQ=; b=LHKMLX2Z84ciK/sfgnStVGye3GQWtTssBtQ/8fJSOPMUyiGZ36LpBys8CTSSEMDNpC rDsdvh2o4lpNPWfWF1+oo1wz3H3QXslO/zLpW0S1Jr3OvIQj4cFg1ElqX7OwA3o5snv3 ybn7cZGbMvUD8FMlNkDrVXYoAOUext78+TyjHNf5Z1xnggbw3CTVgECdkW6lXKq1xhvp DCU84zy6Yt9XFACk5n9WvrNq4TFG0WC056oSHUdE4PmXumAILnT3GC+dq8x1pfrbKVVM m7YaQFzgAURjTWlffIw2myXmE3HXRDzGMSEwJ9DdSEXMZGUjK/YgprbVpNA1YVKKwt5Q rW8w== X-Gm-Message-State: AIkVDXKSPvSah/TRmvYWD788wiW47jQliqwN05IsksdHaixh8VGykunwv5qGP5lmafRiJw== X-Received: by 10.98.95.70 with SMTP id t67mr17417170pfb.37.1484967859327; Fri, 20 Jan 2017 19:04:19 -0800 (PST) Received: from [127.0.0.1] ([27.7.0.247]) by smtp.gmail.com with ESMTPSA id s64sm19857248pfe.27.2017.01.20.19.04.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Jan 2017 19:04:17 -0800 (PST) X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170121030415.5111889.13690.2248@gmail.com> Date: Sat, 21 Jan 2017 08:34:15 +0530 Subject: Re: Understanding the rationale behind dropping of "block devices" From: Aijaz Baig To: Konstantin Belousov Cc: Julian Elischer , Greg 'groggy' Lehey , FreeBSD Hackers , freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 03:04:20 -0000