From eadler@freebsd.org Mon Nov 19 22:58:30 2012 Return-Path: Received: from po11.mit.edu ([unix socket]) by po11.mit.edu (Cyrus v2.1.5) with LMTP; Mon, 19 Nov 2012 22:58:30 -0500 X-Sieve: CMU Sieve 2.2 Received: from mit-mailsec-scanner-1.mit.edu by po11.mit.edu (8.13.6/4.7) id qAK3wPuI005249; Mon, 19 Nov 2012 22:58:29 -0500 (EST) Received: from mailhub-dmz-3.mit.edu ( [18.9.21.42]) by mit-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 98.6F.02128.5EFFAA05; Mon, 19 Nov 2012 22:58:29 -0500 (EST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id qAK3wNkN017014 for ; Mon, 19 Nov 2012 22:58:24 -0500 X-AuditID: 12074f0c-b7f9e6d000000850-92-50aaffe5e1c7 Authentication-Results: symauth.service.identifier Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.B1.02270.FDFFAA05; Mon, 19 Nov 2012 22:58:24 -0500 (EST) Received: by mail-lb0-f177.google.com with SMTP id n10so2389218lbo.36 for ; Mon, 19 Nov 2012 19:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=MPr3qXjquPIHhRHMsCEPq8ito35a/EVNonDz639854o=; b=jizY9+ldAnJA/yzpNhzkYdXk8Hv/52oqvHjK/+dhozY2qpfpnGrDWLF8RX46aEOdqM 9JDl6Vh/fsIt5K4alRfgpj5NJCPb+u3s/a153Kj2OUqPd1B6sfZvrkZxJVHIStQtwwT9 gAEho4mn/wuzykvZzItnbfTnAeNw5elmJ8YEg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=MPr3qXjquPIHhRHMsCEPq8ito35a/EVNonDz639854o=; b=SiFgd/tKBF7uPtPSSdc+/CAkC50GDbZDzHiRKIsthAL5LIrP+zkvCFcEk/LqlmU3xk /jWPXPza5iNxCwjksWqfzTOnKMZX0HseEg4qwgdBbrcDuVQhVVbnKeMHWXyxM2n4/JaN Jc6n6p+p2GYC1KCQzfTmB8pZc+7BxQ6ioF640r2QYvq9xidkOojlKp8c7EIR6hwP400L nB0HxABZBK9GOsgTHu+d19lzPdeBhkKgDgE0yBC62VIhYbKElZErvK6pp5WZm34eVw4f OOzJHORaIYndbXtaSQ/VVfTHmRfV2F2bnoHs9CO0vtWU6Uyhg7Opm8dfmMlgDdHuKkt6 6w6g== Received: by 10.112.103.136 with SMTP id fw8mr6045170lbb.18.1353383903456; Mon, 19 Nov 2012 19:58:23 -0800 (PST) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.112.25.166 with HTTP; Mon, 19 Nov 2012 19:57:53 -0800 (PST) In-Reply-To: References: <201211200255.qAK2tJg5005739@svn.freebsd.org> From: Eitan Adler Date: Mon, 19 Nov 2012 22:57:53 -0500 X-Google-Sender-Auth: MiR0OggEtLRPaYKk2XN4ctmf24k Message-ID: Subject: Re: svn commit: r40102 - head/en_US.ISO8859-1/books/faq To: Benjamin Kaduk Cc: bcr@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnbOUbtxW2Q4AcLxjvkGtT1WOoWH1VWPWo7WJco9c4nPRUtEjGcznjr/z8UfMA+HA54sx6O X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUgTYRz3f7fN29rFs5vl0yqJmQXCTM2iQqSCoAhqHwqiD+W5XW2wneNu q1lJJoo1yBKtdFEZJcaC7I1IJItpSeuFsrDMkVarbGFkUb5Q1t2u12+/5/97eX5/nocima9q E8X5vZzAsy6zRqditFMyLa9/hKzZ3RXmRc0XGoilsLL87k3SCht1+XbO5dzGCfMKCnWO6q7d nlaTPzp+EsqgISUAFIVRHq5vLw2AVoJT8YPnLZoA6CgGXQP8KBxVKYcngOvjLcmKKg/XBQIJ DCgXt92PqxVRFPClxreEctgHON44nMhSoSES9736lmAw6lPjM5UfCdnPIAF/uDUCMqaRAd9u iKlkbEQzcHPX4V+a1bhvULlbi5bhPa0BUpnzeKR1LyEvoUFzcMWNhFWFMnB/1RihVM3Bnf2d hBJvxf014V/xS/FI5EgiMgWZ8al7FRoZk8iI6waGQI4k0VzccpxRYgrx+b13QKnfROHwsUo4 CKbgP62Dfy2NQIRgptvptbhZp0vkbBbRxvI8J1hysqRpFmf3XQT52ZLX6q9CZ1laGBAFZj09 UBiyMmp2m1jiDsM0ijBPoQ+MS6PJRcX2EgcrOjYLPhcnhgFTpDmFLt8ucbSdLdnBCcW/qRkU Zcb0wIREGQRuK+ff4nRJP+U3TVBa2a6X7LtkDS16WLfo3KrwEZhP9QarYkANRgIxYFR8Mc+Z Uuna75IUyVKHj/+TJn+9h+t7L3TDTJORhqSkJEbv4QRpxf/5l2Cg3iUzGh3B8chiSoTGIVVa 2UjH5BJ6J+/90yEu1SOkej3WZrmel/1LmcrAYAlops+vnzWWlnXwypynb7I7Bn1+2+x25CmY mBhdgzOWZD4r/TTtWrSmqW3Fi8q2YePQ2nfXjy/8bDOdc3szivKzXgfT932JpHdoj16t3ZS+ 6PF7a8+lajp3NC92ufTHpBPL161S1+1vYg49X8BUn1gdItNyO+50nR7dsuHslZ2LN5pVooPN ySQFkf0JmGwKkIkDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA1VSW0gUURj2zKy74+rEcbwdNw2b0i6ipfYQGKUvFpm5FIFFlpN7crb2IjPr FSMTRZuHLiTaCtlWpGUPaiUpEeViSVpREpqsN0hQFpSkB0vMmtn11svhP//3/d/38Z9Dkcw3 Xx2Fi21YsHAmVq1VfTkx3B438bdFv/vhov/e5nY7kQIOVXx4S+rBKe0+AzYZC7Gwa3+Olr/W ezm/S1c8snAPlAN7sAT8KAT3oFpJ0ig1gIno5Se3r7cfij6PtaoloKUYOALQM8cU4b1cBcjt mPMgKjhDItf3RQ+CoMsXPar6QSjzDBTQ7Lt5oNQ0DETv7ZMqpQ6CEai5t26Zk45c060ebz+Y iq50SaS3b0HzXTUyh6LUMAZVvvGMqmA0Gq/+TXjjJaCe8R7CK69H4zedy/IpaL6v3iMZDFn0 4GOlWqlJGIRqJ2aAIknCbai1kfHK5KC2mn5wA4Q2rAvasMZyAKIFRBrMpXFmzmgScW6cmMtZ LFiIS4w3G23x2FDwFMiPwPiF051gtpt1AkgBNoCeyGnRM75coVhidoJwimBD6OsLcmvDOauh hOdE/qxQYMKiEyCKZIPpiiIZow1cSSkWrCvQRkrFhtFfDcOZDMzjbPgixvlYWEEJSuMEERTF InpiSZ4OFHAeLj5vNNnWc/yUQ6vYBMg2ZQqRFvM5s2jM85L6QBI13FA9CajpPmkSMCqL1YJ1 YfStPzIVKlS+wLIqufLhBkCkLogGPj4+TICcSV7F/7gbhMlrCKInFcMAo8W26ueWoxBylEF9 sxLFxq1BunJwm3bdlaTU3sFjsSnd/hl33JGbM+sudGg6wwvLjkfQVVJaf85hnSZ6yJk88Or+ llH+4POjRa+bnW0m61ZHzKg7erDxZ0Zpd3JWWtJS7JOhA/YXGdbeS0emohNVkVmnQ5Y6+KjQ pqaxOeJx369skq8P5jft6M8uPAnwSNSZ7ekDrErkuYSdpCBy/wCPssa6awMAAA== On 19 November 2012 22:39, Benjamin Kaduk wrote: >> + are bundled up into transaction groups >> + and written to disk when filled (Transaction Group >> + Commit). However syscalls like &man.fsync.2; > > Bogus whitespace. How so? >> + >> + The L2ARC is a read cache stored > No expansion of the acronym? I thought about this but didn't think it added much. (Layer 2 adaptive replacement cache) is what it would say > I think "an L2ARC" is better, as one seems likely to pronounce the 'L' as an > ell sound. This is grammatically incorrect, but I agree it feels more natural. I'm not sure what to put. > "possible" does not equate to "generally speaking, no". Perhaps "probable" > is more appropriate here? Perhaps, but this isn't worth changing. I was trying to balance between people telling me "this is evil, never do it" and "its okay if you know what to expect." > I think the parallelism is wrong in this comma-separated list, but could be > wrong. Removing the "is" might help. Good call. > > "duplicated" is probably not the best phrasing, as it does not immediately > convey the sense that another copy of the data is made, as "replicated" or > "made separate" or such would. agreed. Lets go with? commit dbf0837f882756f053be21aa22cd28f200d4bac9 Author: Eitan Adler Date: Mon Nov 19 22:56:46 2012 -0500 Minor wording fixes for the recently committed ZFS section. Submitted by: bjk Approved by: ??? (mentor) diff --git a/en_US.ISO8859-1/books/faq/book.xml b/en_US.ISO8859-1/books/faq/book.xml index 22ccf55..43cde2a 100644 --- a/en_US.ISO8859-1/books/faq/book.xml +++ b/en_US.ISO8859-1/books/faq/book.xml @@ -5357,7 +5357,8 @@ C:\="DOS" are bundled up into transaction groups and written to disk when filled (Transaction Group Commit). However syscalls like &man.fsync.2; - require a commitment to stable storage before returning. + require a commitment that the data is written to stable + storage before returning. The ZIL is needed for writes that have been acknowledged as written but which are not yet on disk as part of a transaction. The transaction groups are timestamped. @@ -5417,10 +5418,10 @@ C:\="DOS" very heavily duplicated (such as virtual machine images, or user backups) it is possible that deduplication will do more harm than good. Another consideration is the - inability to revert deduplication status. If - deduplication is enabled, data written, and then dedup - is disabled, those blocks which were deduplicated will - not be duplicated until they are next modified. + inability to revert deduplication status. If data is + written when deduplication is enabled, disabling dedup + will not cause those blocks which were deduplicated to + be replicated until they are next modified. Deduplication can also lead to some unexpected situations. In particular deleting files may become much -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams