From owner-freebsd-doc@FreeBSD.ORG Sun Feb 16 23:36:14 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF80C77D; Sun, 16 Feb 2014 23:36:14 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2A191940; Sun, 16 Feb 2014 23:36:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1GNaEVM078865; Sun, 16 Feb 2014 23:36:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1GNaEUw078864; Sun, 16 Feb 2014 23:36:14 GMT (envelope-from linimon) Date: Sun, 16 Feb 2014 23:36:14 GMT Message-Id: <201402162336.s1GNaEUw078864@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: docs/186663: [handbook] mention old xorg in handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 23:36:15 -0000 Old Synopsis: Old xorg installed and not running New Synopsis: [handbook] mention old xorg in handbook Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 16 23:35:42 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=186663 From owner-freebsd-doc@FreeBSD.ORG Mon Feb 17 11:06:04 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FFC3ADB for ; Mon, 17 Feb 2014 11:06:04 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4306B1149 for ; Mon, 17 Feb 2014 11:06:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1HB644o032149 for ; Mon, 17 Feb 2014 11:06:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1HB639o032147 for freebsd-doc@FreeBSD.org; Mon, 17 Feb 2014 11:06:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:03 GMT Message-Id: <201402171106.s1HB639o032147@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:06:04 -0000 (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=doc .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/186663 doc [handbook] mention old xorg in handbook o docs/186625 doc Handbook rebuilding "world" upgrade procedure wrong me o docs/186608 doc typo in 'ctime(3) man page p docs/186191 doc Typo in bhyveload.8 o docs/185764 doc mention of libiconv in FreeBSD 10.0 release note o docs/185531 doc etherswitchcfg(8) refers to etherswitch(4) which does o docs/185481 doc sh/bash Parameter Expansion +/- syntax not documented o docs/185422 doc [handbook] brazilian portuguese translation to "Append o docs/185421 doc [handbook] brazilian portuguese translation to "Append o docs/185392 doc [handbook] brazilian portuguese translation to "The Fr o docs/185391 doc [handbook] brazilian portuguese translation to "GEOM: o docs/185353 docs nc(1) does not exit after transfer (should be document o docs/185281 doc [handbook] brazilian portuguese translation to "Jails" o docs/185280 doc [handbook] brazilian portuguese translation to "Introd o docs/184758 doc error in rtadvd.conf example o docs/184755 doc The vmstat(8) manualpage synopsis doesn't show all opt o docs/184459 doc Documentation Bug in the man Page for the who Command o docs/184110 doc blackhole(4) manpage doesn`t describe net.inet.sctp.b o docs/184051 doc Update configuration example for staging o docs/184048 doc developers handbook, 10.7 Debugging Deadlocks - must i o docs/184046 doc bhyve(4) manpage references non-existant manpages bhyv o docs/184029 doc Description of /usr/tests is missing in hier(7) o docs/183927 doc missing info about kernel toolchain in kernel building o docs/183653 doc [patch] Add some more *BSD releases to the groff_mdoc o docs/183427 doc Online man pages don't include latest release + ports o docs/183333 doc Misnamed constant in bpf(4) o docs/183246 doc FreeBSD 8.4-RELEASE Installation Instructions don't pr o docs/183024 doc textdump(4) mentions call doadump, should be textdump o docs/183002 doc Fix instructions in "6.5.3. Anti-Aliased Fonts" regard o docs/182876 doc CURRENT release notes webpage out of date and inconsis o docs/182218 doc Add an ipfilter rc.conf option in handbook for IPv6 o docs/181845 doc Virtualbox Host Setup needs acd0 in /etc/devfs.conf, a o docs/181844 doc FreeBSD Handbook Virtualbox Host Section missing confi o docs/181808 doc Chapter 15.15 (Resource Limits) misses important infor o docs/181785 doc [patch] Man page for tmpfile() is inconsistent o docs/181390 doc seq(1) first appeared in 8th UNIX o docs/181376 doc CLOCK_THREAD_CPUTIME_ID is not documented in clock_get o docs/181280 doc suggestion: split zfs man page in a zfs- way o docs/181134 doc Fix example for boot0cfg utility o docs/180970 doc [request] No manpage for ps_strings o docs/180767 doc [patch] printf.3: fix off-by-one in snprintf descripti o docs/180493 doc [handbook] Single-user mode console confusion o docs/180332 doc SSD Kernel Instructions Out of Date: options MFS throw o docs/180331 doc SSD Kernel Instructions Out of Date: options MD_ROOT a o docs/180330 doc SSD Kernel Instructions Out of Date: pseudo-device no o docs/180027 doc Missing man page entries for callout_reset_sbt in time o docs/179988 doc [faq] [patch] ThwackAFAQ - sandbox p docs/179914 doc remove inactive user dougb from mergemaster maintainer o docs/179697 doc Handbook incomplete WRT Opera flash usage (linproc) o docs/179497 doc [patch] service.8 add csh completion example o docs/179246 doc [patch] gnome porting updates o docs/178818 doc gmirror(8) says to use rc.early which is no longer ava o docs/178730 doc move roff papers out of src into doc o docs/178286 doc [PATCH] document the LOCAL_* vars in build(7) o docs/178221 doc Addition to handbook jails chapter: warning about make o www/178190 doc myths web page should be updated o docs/178119 doc [ports] Porter's handbook lacks examples for using Opt o docs/177968 doc bpf(4): documentation of BIOCROTZBUF is incomplete o docs/177699 doc Documentation (handbook and manpage) for mac_biba does o docs/177514 doc [handbook] ZFS examples do not cover dataset creation o docs/177457 doc diskinfo(8): diskinfo -v shows inacurate drive size o docs/177431 doc Handbook & Announcements recommend poor dd options for o docs/177429 doc dd(1) man page is unclear about semantics of conv=sync o docs/177215 doc [handbook] [patch] FreeBSD uses SHA512 and no more MD5 o docs/176806 doc recv(2) man page grammatical fixes o docs/176648 doc restore(8) man page is misleading/confusing o docs/176645 doc The example in netmap.4 is wrong o docs/176363 doc Remove mention of 'CVSup' from "Mirroring FreeBSD arti o docs/176355 doc Attribution and correction of quote in fortune o docs/176251 doc FreeBSD Handbook assumes too much pre-knowledge o docs/176127 doc [handbook] add information about all missing mailing l o docs/176125 doc missing summary of freebsd-jail mailing list o docs/176123 doc missing summary of freebsd-sysinstall mailing list o docs/176015 doc [handbook] wrong order in docs for major upgrade o docs/175995 doc Setting MALLOC_PRODUCTION stops buildworld o docs/175983 doc man zfs are missing "hold, release" from "zfs allow" o docs/175712 doc Update 'disk naming' handbook page o docs/175687 doc pthread_setschedparam(3) may fail for undocumented rea o docs/175560 doc ugen(4) man page contains incorrect device node path o docs/175239 doc sem_wait can be interrupted o docs/175123 doc [geom] gpart list/status isn't documented in usage sec o docs/174868 doc mount(2) doesn't do a good job at describing all possi o docs/174792 doc synopsis for nsupdate(1) missing options -L, and -p o docs/174581 doc man page of recvmsg(2) does not mention return value 0 o docs/173710 doc Added section "MTP storage" to handbook o docs/173539 doc [patch] statfs(2) man page missed the error code ENOSY o docs/173321 doc ports(7) man page -- no info on building with debuggin o docs/173013 doc FreeBSD Boot Menu documentation lacks detail o docs/172927 doc ipfw(8): ipfw manual page doesn't show simpliest NAT c o docs/172913 doc [ipsec] [patch] setkey(8) is unclear on anti-replay wi o docs/172869 doc [PATCH] Add in nifty lang icons to index.html (home) o docs/172743 doc IPv6 handbooks lacks info about accepting router adver o docs/172626 doc [PATCH] modify the community/* pages to look more plea o docs/172370 doc [handbook] Handbook should be updated for Blu-Ray driv o docs/172369 doc mkisofs(8)/growisofs(1m) don't specify UDF version o docs/172368 doc mount_udf(8) doesn't specify which versions of UDF are o docs/172367 doc ata(4) man page needs an updated for Blu-Ray o docs/172330 doc [PATCH] Fix some errors introduced to announce.xml by o docs/172144 doc psignal(9) manpage is outdated for FreeBSD-9 systems o docs/172137 doc deprecated information for adduser(8) man pages o docs/171199 doc the GDB man page is outdated o docs/170691 doc Difference between zfs manpages and reality o docs/170119 doc at behaviour and man at inconsistency o docs/169712 doc [patch] porters-handbook zh_TW.Big5 apache section o docs/169711 doc [patch] porters-handbook zh_CN.GB2312 apache section o docs/169544 doc serial port console documentation changes s docs/169401 doc passify dead links in release links, move www to lists o docs/169377 doc [patch] ipmon(8) man page refers to a different facili o docs/169317 doc zfs umount refers to umount(1M) but should to umount(8 o docs/169158 doc [patch] iasl(8) man page is out of date f docs/168939 doc Port upgrade documentation missing from Application Ja o docs/168930 doc map_mincore(9) not up-to-date o docs/168915 doc size of integers used by test(1) and sh(1) is not docu o docs/168823 doc 404s in fr_FR French web pages o docs/168814 doc [patch] remove `d` negative pointer EINVAL requirement o docs/168803 doc Remove outdated smp info o docs/167429 doc geli(8) needs to mention unencrypted /etc/fstab requir o docs/166553 doc find(1): find -delete documentation is misleading o docs/166358 doc No networking in Jail build via: handbook/jail-tuning o conf/166330 doc [rc] [patch] Thin server configuration revision reques o docs/165551 doc ipfw(8): no info in "ipfw pipe show" about ipv6 o docs/165249 doc Multibyte characters in manpages still not displaying o docs/164803 doc Unclear manual page for mount_unionfs(8) o docs/164099 doc gparm(8): man page for gparm set is incorrect and inco o docs/164034 doc acl(9) documentation lacking o docs/163879 doc [handbook] handbook does not say about how to force to o docs/163830 doc device smbios: missing documentation, no manpage o docs/163149 doc [patch] Red Hat Linux/i386 9 HTML format sudo man page o docs/162765 doc [patch] lseek(2) may return successful although no see o docs/162587 doc unclear/incomplete description of per-interface statis o docs/162419 doc [request] please document (new) zfs and zpool cmdline o docs/162404 doc [handbook] IPv6 link-local address compared with IPv4 o docs/161754 doc p4tcc(4), est(4) and qpi(4) are not documented o docs/161496 doc zfs(1): Please document that sysctl vfs.usermount must o docs/160460 doc [handbook] Network setup guide suggestion o docs/160399 doc Man page for re(4) missing jumbo frames info o docs/159307 doc [patch] lpd smm chapter unconditionally installed o docs/158388 doc Incorrect documentation of LOCAL_SCRIPT in release(7) o docs/158387 doc The tree(3) man should mention the RB_FOREACH_SAFE() A o docs/157908 doc [handbook] Description of post-install should include o docs/157698 doc [patch] gpart(8) man page contains old/incorrect size o docs/157316 doc [patch] update devstat(9) man page o docs/156920 doc isspecial(3) is not helpful o docs/156815 doc chmod(1): manpage should describe that chmod kicks +t o docs/156689 doc stf(4) output-only documentation gives bad configurati f docs/156187 doc [handbook] [patch] Add bsnmpd to handbook o docs/156081 doc troff falls with troff.core with UTF-8 man with incorr o docs/155982 doc [handbook] reaper of the dead: remove reference to flo o docs/155149 doc [patch] don't encourage using xorg.conf outside of PRE o docs/154838 doc update cvs-tags information on releng_* to reflect sup o docs/153958 doc ksu man-page documented, but not installed a docs/153012 doc [patch] iostat(8) requires an argument to -c option o docs/151752 doc pw.conf(5) doesn't define format for file clearly o docs/150991 doc [patch] Install upgtfw using pkg_add as advised in upg o docs/150917 doc [patch] icmp.4, wrong description of icmplim and icmpl o docs/150255 doc dtrace description should mention makeoptions DEBUG=-g o docs/149574 doc [patch] update mi_switch(9) man page o docs/148987 doc [patch] {MD[245]|SHA_|SHA1_|SHA256_}{End|File|FileChun o docs/148984 doc [handbook] Mistake in section 16.15.4 of the handbook o docs/148680 doc [sysctl][patch] Document some sys/kern sysctls o docs/148071 doc Failover mode between wired and wireless interfaces o docs/147995 doc elf.5 man page has has missing reference o docs/146521 doc [handbook] Update IPv6 system handbook section to ment o docs/145699 doc hexdump(1) mutes all format qualifier output following o docs/145069 doc Dialup firewalling with FreeBSD article out dated. o docs/145066 doc Update for new uart dev names for serial port. s docs/144818 doc all mailinglist archives dated 19970101 contain traili o docs/143472 doc gethostname(3) references undefined value: HOST_NAME_M o docs/143416 doc [handbook] IPFW handbook page issues o docs/143408 doc man filedesc(9) is missing o docs/141032 doc misleading documentation for rtadvd.conf(5) raflags se s docs/140847 doc [request] add documentation on ECMP and new route args o docs/140444 doc [patch] New Traditional Chinese translation of custom- o docs/140375 doc [UPDATE] Updated zh_TW.Big5/articles/nanobsd o docs/139336 doc [request] ZFS documentation suggestion o docs/139165 doc gssapi.3 man page out of sync with between crypto and o docs/139018 doc translation of submitting.sgml from docproj/submitting o docs/138485 doc bpf(4) and ip(4) man pages missing important corner ca o docs/136712 doc [handbook] [patch] draft new section on gmirror per pa o docs/136666 doc [handbook] Configure serial port for remote kernel deb o docs/136035 doc ftpchroot(5) omits an important option o docs/132839 doc [patch] Fix example script in ldap-auth article o docs/132190 doc EPERM explanation for send(2), sendto(2), and sendmsg( o docs/131918 doc [patch] Fixes for the BPF(4) man page o docs/131626 doc [patch] dump(8) "recommended" cache option confusing o docs/130238 doc nfs.lockd man page doesn't mention NFSLOCKD option or o docs/129671 doc New TCP chapter for Developer's Handbook (from rwatson o docs/129464 doc using packages system o docs/129095 doc ipfw(8): Can not check that packet originating/destine o docs/128356 doc [request] add Firefox plugin for FreeBSD manual pages s docs/127844 doc Example code skeleton_capture_n.c in meteor(4) manpage o docs/126484 doc libc function res-zonscut2 is not documented f docs/122052 doc minor update on handbook section 20.7.1 o docs/121952 doc Handbook chapter on Network Address Translation wrong o docs/121585 doc [handbook] Wrong multicast specification s docs/121541 doc [request] no man pages for wlan_scan_ap o docs/121312 doc RELNOTES_LANG breaks release if not en_US.ISO8859-1 o docs/121173 doc [patch] mq_getattr(2): mq_flags mistakenly described a s docs/120917 doc [request]: Man pages mising for thr_xxx syscalls o docs/120125 doc [patch] Installing FreeBSD 7.0 via serial console and o docs/120024 doc resolver(5) and hosts(5) need updated for IPv6 o docs/119545 doc books/arch-handbook/usb/chapter.sgml formatting o docs/118214 doc close(2) error returns incomplete o docs/116588 doc No IPFW tables or dummynet in Handbook o docs/114371 doc [patch] [ip6] rtadvd.con(5) should show how to adverti o docs/114139 doc mbuf(9) has misleading comments on M_DONTWAIT and M_TR o docs/113194 doc [patch] [request] crontab.5: handling of day-in-month o docs/112579 doc [request] No ipv6 related pf examples in /usr/share/ex o docs/111425 doc Missing chunks of text in historical manpages o docs/111265 doc [request] Clarify how to set common shell variables o docs/110999 doc carp(4) should document unsupported interface types o docs/110692 doc wi(4) man page doesn't say WPA is not supported o docs/110376 doc [patch] add some more explanations for the iwi/ipw fir o docs/109981 doc No manual entry for post-grohtml o docs/109977 doc No manual entry for ksu f docs/109226 doc [request] No manual entry for sntp o docs/109201 doc [request]: manual for callbootd a docs/108980 doc list of missing man pages o docs/105608 doc fdc(4) debugging description staled o docs/104879 doc Howto: Listen to IMA ADPCM .wav files on FreeBSD box o docs/102719 doc [patch] ng_bpf(4) example leads to unneeded promiscuos o docs/101271 doc serial console documentation implies kernel rebuild re p docs/100196 doc man login.conf does explain not "unlimited" o docs/98974 doc Missing tunables in loader(8) manpage o docs/96207 doc Comments of a sockaddr_un structure could confuse one o docs/95408 doc install over serial console does not work as documente o docs/94625 doc [patch] growfs man page -- document "panic: not enough o docs/92626 doc jail manpage should mention disabling some periodic sc o docs/91149 doc read(2) can return EINVAL for unaligned access to bloc o docs/88512 doc [patch] mount_ext2fs(8) man page has no details on lar o docs/87936 doc Handbook chapter on NIS/YP lacks good information on a o docs/87857 doc ifconfig(8) wireless options order matters o docs/85128 doc [patch] loader.conf(5) autoboot_delay incompletly desc o docs/84956 doc [patch] intro(5) manpage doesn't mention API coverage o docs/84932 doc new document: printing with an Epson ALC-3000N on Free o docs/84670 doc [patch] tput(1) manpage missing ENVIRONMENT section wi o docs/84317 doc fdp-primer doesn't show class=USERNAME distinctively o docs/84271 doc [patch] compress(1) doesn't warn about nasty link hand o docs/83820 doc getino(3) manpage not installed o docs/81611 doc [patch] natd runs with -same_ports by default o docs/78480 doc Networked printer setup unnecessarily complex in handb o docs/61301 doc [patch] Manpage patch for aue(4) to enable HomePNA fun o docs/59835 doc ipfw(8) man page does not warn about accepted but mean o docs/57298 doc [patch] add using compact flash cards info to handbook s docs/54752 doc bus_dma explained in ISA section in Handbook: should b o docs/53751 doc bus_dma(9) incorrectly documents BUS_DMA_ALLOCNOW o docs/53596 doc Updates to mt(1) manual page o docs/53271 doc bus_dma(9) fails to document alignment restrictions o docs/51480 doc Multiple undefined references in the FreeBSD manual pa o kern/51341 doc [ipfw] [patch] ipfw rule 'deny icmp from any to any ic o docs/50211 doc [patch] doc.docbook.mk: fix textfile creation o docs/48101 doc [patch] Add documentation on the fixit disk o docs/47594 doc [patch] passwd(5) incorrectly states allowed username o docs/43823 doc [patch] update to environ(7) manpage o docs/41089 doc pax(1) -B option does not mention interaction with -z o docs/40423 doc Keyboard(4)'s definition of parameters to GETFKEY/SETF o docs/36724 doc ipnat(5) manpage grammar is incomplete and inconsisten o docs/26286 doc *printf(3) etc should gain format string warnings o docs/24786 doc missing FILES descriptions in sa(4) s docs/20028 doc ASCII docs should reflect tags in the sourc 260 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Feb 17 18:18:13 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4644798F for ; Mon, 17 Feb 2014 18:18:13 +0000 (UTC) Received: from mail.magehandbook.com (173-8-4-45-WashingtonDC.hfc.comcastbusiness.net [173.8.4.45]) by mx1.freebsd.org (Postfix) with ESMTP id 208C51137 for ; Mon, 17 Feb 2014 18:18:12 +0000 (UTC) Received: from [192.168.1.50] (Mac-Pro.magehandbook.com [192.168.1.50]) by mail.magehandbook.com (Postfix) with ESMTP id 3fSYN35JZFz96 for ; Mon, 17 Feb 2014 13:18:11 -0500 (EST) Date: Mon, 17 Feb 2014 13:18:11 -0500 From: Daniel Staal To: freebsd-doc@FreeBSD.org Subject: Portaudit pages Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:18:13 -0000 Portaudit was a nice tool, but it's depreciated now. (And complains loudly once it's installed.) Changing the pages to show how `pkg audit` can do the same would probably be good. (It'd also be nice to have instructions on how to install it as part of the periodic script, which portaudit did on install, but isn't part of the install of pkg.) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 04:24:06 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3CA2A20; Tue, 18 Feb 2014 04:24:06 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A06661901; Tue, 18 Feb 2014 04:24:06 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id E9799D54D; Mon, 17 Feb 2014 20:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1392697440; bh=hLyACMoVE8oeGqCjqw5GZw0Jjwm/hw+lLKtkKF7kjxA=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=lVW53onshGp45a+43iiBRJSgd7L8QyC6OWYY4Bg7L1SFSvTG/5M5G88NbHqY+F2p6 VmfN3Tyl5W5wUrE0vjx20LoQUsjynxSFUTnzhdL+2yrYxkCfa0ggrpWzLypZjvPBGR E1nE4B5CROeK0FBUM5SzZaB3S3jv2qHzUuVRme1U= Message-ID: <5302E05F.1050200@delphij.net> Date: Mon, 17 Feb 2014 20:23:59 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Warren Block , d@delphij.net Subject: Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-doc@freebsd.org" , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 04:24:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (redirecting to freebsd-doc@) On 2/17/14, 7:10 PM, Warren Block wrote: > On Mon, 17 Feb 2014, Xin Li wrote: > >> (Picking a random changeset, not specific to this one). >> >> On 2/17/14, 6:26 PM, Warren Block wrote: >>> Author: wblock Date: Tue Feb 18 02:26:27 2014 New Revision: >>> 43974 URL: http://svnweb.freebsd.org/changeset/doc/43974 >>> >>> Log: Whitespace-only changes, translators please ignore. >>> Patch from Allan Jude . >> >> Can we stop doing this, or do it all in one time in less >> frequent manner? This type of changes is VERY VERY VERY painful >> for translators and give a great burden to us because it makes it >> almost impossible to use simple 'svn up' to catch up. > > I'm sorry, these multiple whitespace changes were my fault due to > a mixup with Allan Jude's original patch. Normally, it would have > been a single commit. > > I apologize for this difficulty. Well, please don't take it too personally :) > Would it help if these changes were reverted with a "reverse merge" > of r43920, r43921, r43973, r43974, and r43975, then recommitted > with the whitespace patches combined, or is it too late for that? I think using a batch of commits instead of one big commit is generally a good idea because the diff is easier to read/merge. What makes it hard to track is when the space changes are made in larger timespan as they would be harder to ignore them or need more manual intervention. > If there is any way I or other committers can make this easier for > translators, please post on the -doc mailing list or to me > invididually. One thing I would recommend is to separate the contents that do not need translation (e.g. tags, entities, etc.) and contents that needs translation. This way, these contents would serve as a positioning blocks when merging from upstream (English). > We are also trying to modernize the translation process, and > automate some of the work that translators are currently forced to > do. Anyone who would like to help with that is welcome. That would be great! How can we help, or is there some kind of TODO list? Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTAuBfAAoJEJW2GBstM+nsYu0P/iQ/F8/toBIEzuqJyJF95F8H fnL42ShF8GLc0GUL+hXGiTZmxZ8W4WZ5BAoFh/oASXJlHTtVJSkNZhky3ze+0WkP N6jKDW8NAZYNxuRhgM4OSs278vU0jHzBl3kIY/2pU3RXZWxkmABSyLCunl/W6ImX c771LCwVY9zvnCZGmP52NFkwdLeLoSUFAH0r9r3w53LjGajO1tCr8UPCGI198oNH xr8g0Hbd7lpdxRSggkKFs8AhiLy+RYrbWh8soMUqDoogDDTKH/F2BEOTKM6GUqT5 9jY+TLWR0No0qt6j6CkIMGBppX7NApc15Go9jcPE6fGBsYGuaZbY3AcIC6NdQzEi eHjkely9cYZbo3hYmPn6t51iZJ8Sds6J+1q1hbMZ2Fn9b/ANi2g+0qQeiYysyKf7 DV1bOTjnspUAbFqFSf0pcUCv9FIPPZYbmgIMcCo8tUsv9HJGc99/IOQAE9QuYxPn lmxdDNYZEdVbuU0H+jJzqzQA5a4DWdnz5uieWl428IQb1VJowb2PQcWUrypnEZrK G0gTi1pI7E6BBKi+VD8DGBTu42heK2fjdjLhSgGbl+UL+vc7HPbGKfYI1jNXGy+S AaLwf7C0Opy0fg6/hLcNlWJa87oTUWuvbz5pPNUWnu2AroIkdrPKI3MOmtyPOgZ7 CJWnypBX6WIG4Yg2A3Z6 =8rLq -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 05:19:09 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DBFB3CF; Tue, 18 Feb 2014 05:19:09 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B64E1C42; Tue, 18 Feb 2014 05:19:09 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1I5J3Fr044147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Feb 2014 22:19:03 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1I5J3RI044144; Mon, 17 Feb 2014 22:19:03 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 17 Feb 2014 22:19:03 -0700 (MST) From: Warren Block To: d@delphij.net Subject: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) In-Reply-To: <5302E05F.1050200@delphij.net> Message-ID: References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 17 Feb 2014 22:19:03 -0700 (MST) Cc: "freebsd-doc@freebsd.org" , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:19:09 -0000 On Mon, 17 Feb 2014, Xin Li wrote: > (redirecting to freebsd-doc@) Subject changed. > On 2/17/14, 7:10 PM, Warren Block wrote: >> >> I'm sorry, these multiple whitespace changes were my fault due to >> a mixup with Allan Jude's original patch. Normally, it would have >> been a single commit. >> >> I apologize for this difficulty. > > Well, please don't take it too personally :) Thanks. :) >> Would it help if these changes were reverted with a "reverse merge" >> of r43920, r43921, r43973, r43974, and r43975, then recommitted >> with the whitespace patches combined, or is it too late for that? > > I think using a batch of commits instead of one big commit is > generally a good idea because the diff is easier to read/merge. What > makes it hard to track is when the space changes are made in larger > timespan as they would be harder to ignore them or need more manual > intervention. I think I understand. Part of my difficulty is being monolingual, it's hard for me to see exactly what translators do. Benedict has explained it to me, but it sounds so difficult to track changes that it's hard to believe anyone can keep up with it. (Oh, and if those changes need to be reverted, let's do that as soon as possible.) >> If there is any way I or other committers can make this easier for >> translators, please post on the -doc mailing list or to me >> invididually. > > One thing I would recommend is to separate the contents that do not > need translation (e.g. tags, entities, etc.) and contents that needs > translation. This way, these contents would serve as a positioning > blocks when merging from upstream (English). That sounds interesting, and leads well into the next part: >> We are also trying to modernize the translation process, and >> automate some of the work that translators are currently forced to >> do. Anyone who would like to help with that is welcome. > > That would be great! How can we help, or is there some kind of TODO list? There are several things that would be helpful. We could use help from people who are experienced with using the .po/.pot/.mo tools (gettext) on other platforms. The basic process is to separate all the content from the markup automatically. Then an editor can be used to add translations, and the tool puts a translated file back together from it. This allows the translation program to remember existing translations, so translating one document helps translate others. textproc/itstool is one of the automatic separator programs. I've been somewhat stymied trying to figure out how to get the Python libxml2 implementation used by it to find FreeBSD documentation XML catalogs. Documentation on this is... let's just say sparse. The PC-BSD folks are using tools like Pootle, but not for DocBook (as far as I know). They have a web site for translation, useful as an example of what can be done: http://pootle.pcbsd.org/ Benedict (CCed) has made some progress with some of these tools. I think there are plans to add a page to the wiki, but don't know if it is present yet. From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 05:30:01 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D1CA5BB for ; Tue, 18 Feb 2014 05:30:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB8791CDA for ; Tue, 18 Feb 2014 05:30:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1I5U0bV089737 for ; Tue, 18 Feb 2014 05:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1I5U0e2089735; Tue, 18 Feb 2014 05:30:00 GMT (envelope-from gnats) Resent-Date: Tue, 18 Feb 2014 05:30:00 GMT Resent-Message-Id: <201402180530.s1I5U0e2089735@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Allan Jude Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B31E55A9 for ; Tue, 18 Feb 2014 05:27:45 +0000 (UTC) Received: from newred.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D6AE1CD0 for ; Tue, 18 Feb 2014 05:27:45 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s1I5Rj7e023443 for ; Tue, 18 Feb 2014 05:27:45 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.7/8.14.7/Submit) id s1I5RjXK023429; Tue, 18 Feb 2014 05:27:45 GMT (envelope-from nobody) Message-Id: <201402180527.s1I5RjXK023429@cgiserv.freebsd.org> Date: Tue, 18 Feb 2014 05:27:45 GMT From: Allan Jude To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: docs/186857: improve handbook ToC readability X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:30:01 -0000 >Number: 186857 >Category: docs >Synopsis: improve handbook ToC readability >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Feb 18 05:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Allan Jude >Release: 9.2-RELEASE >Organization: ScaleEngine Inc. >Environment: FreeBSD Trooper.HML3.ScaleEngine.net 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Improve the readability of the Table of Contents of the FreeBSD Handbook by applying colours to links. Until now the handbook has had no style on links, resulting in the default bright blue / purple link colours. Apply style to make the colours a little less jaring and easier to read, also makes the page not look like it is from 1994. Borrowed the colour codes from http://en.wikipedia.org/wiki/Help:Link_color since these seem to be what people will expect >How-To-Repeat: >Fix: Patch Attached Patch attached with submission follows: Index: share/misc/docbook.css =================================================================== --- share/misc/docbook.css (revision 43975) +++ share/misc/docbook.css (working copy) @@ -34,6 +34,12 @@ font-weight: bold; } +/* Copied from http://en.wikipedia.org/wiki/Help:Link_color */ +a:link { color:#0645AD; text-decoration: underline; } +a:visited { color:#663366; text-decoration: underline; } +a:hover { color:#663366; text-decoration: underline; } +a:active { color:#663366; text-decoration: underline; } + div.blockquote-title { font-weight: bold; margin-top: 1em; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 05:30:01 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D1CA5BD for ; Tue, 18 Feb 2014 05:30:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E22A1CDD for ; Tue, 18 Feb 2014 05:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1I5U1KP089801 for ; Tue, 18 Feb 2014 05:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1I5U1DF089800; Tue, 18 Feb 2014 05:30:01 GMT (envelope-from gnats) Resent-Date: Tue, 18 Feb 2014 05:30:01 GMT Resent-Message-Id: <201402180530.s1I5U1DF089800@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Allan Jude Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13D6D48B for ; Tue, 18 Feb 2014 05:24:15 +0000 (UTC) Received: from newred.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2D311CBB for ; Tue, 18 Feb 2014 05:24:14 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s1I5OEch080567 for ; Tue, 18 Feb 2014 05:24:14 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.7/8.14.7/Submit) id s1I5OE7W080559; Tue, 18 Feb 2014 05:24:14 GMT (envelope-from nobody) Message-Id: <201402180524.s1I5OE7W080559@cgiserv.freebsd.org> Date: Tue, 18 Feb 2014 05:24:14 GMT From: Allan Jude To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: docs/186858: improve handbook ToC readability X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:30:01 -0000 >Number: 186858 >Category: docs >Synopsis: improve handbook ToC readability >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Feb 18 05:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Allan Jude >Release: 9.2-RELEASE >Organization: ScaleEngine Inc. >Environment: FreeBSD Trooper.HML3.ScaleEngine.net 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Improve the readability of the Table of Contents of the FreeBSD Handbook by decreasing the amount of whitespace between items. Also increase the font size of the section titles slightly, as they are the same size as the ToC items. >How-To-Repeat: >Fix: Patch Attached Patch attached with submission follows: Index: share/misc/docbook.css =================================================================== --- share/misc/docbook.css (revision 43975) +++ share/misc/docbook.css (working copy) @@ -120,15 +126,23 @@ } dl { - margin: .8em 0; + margin: .4em 0 0 0; line-height: 1.2; } dt { font-weight: bold; - margin-top: 1em; + margin: 0.4em 0 0 0; } +div.abstract div.abstract-title, +div.toc div.toc-title, +div.list-of-figures div.toc-title, +div.list-of-tables div.toc-title, +div.list-of-examples div.toc-title { + font-size: 115%; +} + div.calloutlist dt { float: left; width: 1em; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 09:13:16 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33E08451; Tue, 18 Feb 2014 09:13:16 +0000 (UTC) Received: from mxout2.bln1.prohost.de (mxout2.bln1.prohost.de [91.233.87.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B12701D81; Tue, 18 Feb 2014 09:13:15 +0000 (UTC) Received: from fbipool-clients-45-145.fbi.h-da.de (fbipool-clients-45-145.fbi.h-da.de [141.100.45.145]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.4/8.14.4) with ESMTP id s1I9Cwb2029186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Feb 2014 10:12:58 +0100 Message-ID: <5303241B.8080906@FreeBSD.org> Date: Tue, 18 Feb 2014 10:12:59 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: d@delphij.net Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Null-Tag: 0e0ab55a245382dfeb1a76824d351b76 Cc: "freebsd-doc@freebsd.org" , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 09:13:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi guys, thanks for your interest in translation. I think that with the improvements that we can make, we can also make it easier for doc committers making changes to the doc not worry too much about translations with regards to whitespace. I could be wrong, but I think we could combine whitespace and content changes in the future. For now, my primary focus is on getting the translation process more automated and easier to catch up. >>> If there is any way I or other committers can make this easier >>> for translators, please post on the -doc mailing list or to me >>> invididually. >> >> One thing I would recommend is to separate the contents that do >> not need translation (e.g. tags, entities, etc.) and contents >> that needs translation. This way, these contents would serve as >> a positioning blocks when merging from upstream (English). > > That sounds interesting, and leads well into the next part: > >>> We are also trying to modernize the translation process, and >>> automate some of the work that translators are currently forced >>> to do. Anyone who would like to help with that is welcome. >> >> That would be great! How can we help, or is there some kind of >> TODO list? > Well, I have a couple of loose threads that we need to tie together to have a complete and mostly automated system. > There are several things that would be helpful. > > We could use help from people who are experienced with using the > .po/.pot/.mo tools (gettext) on other platforms. > > The basic process is to separate all the content from the markup > automatically. Then an editor can be used to add translations, and > the tool puts a translated file back together from it. This allows > the translation program to remember existing translations, so > translating one document helps translate others. > Yes, that is a good description. I've put a (hopefully) more thorough description on the wiki page below. > textproc/itstool is one of the automatic separator programs. I've > been somewhat stymied trying to figure out how to get the Python > libxml2 implementation used by it to find FreeBSD documentation XML > catalogs. Documentation on this is... let's just say sparse. > Another tool is textproc/po4a that Thomas Abthorpe showed me on one of the hacker lounges two years ago in Canada. He set up a test project for a translation into en_GB to see how these tools fit our toolchain. He send me the following mini-howto, which I extended a bit for a first commit to the german doc repo recently: install textproc/po4a install editors/poedit # optional install devel/gtranslator #optional install lokalize # somewhere in kde4, too lazy to look To prep a new translation, inline, same directory the following works. Substitute en_GB for the language of your choice. po4a-gettextize -f xml -m article.sgml -p article.pot # renders to pot file #, save as article_en_GB.po po4a-translate -f xml -m article.sgml -p article_en_GB.po -l article_en_GB.sgml Trying to convert to po files with existing translations, the following should work providing the sgmlised files match tag for tag po4a-gettextize -M ISO8859-1 -f xml -m ../../../en_US.ISO8859-1/articles/
/article.sgml -l article.sgml -p article_de_DE.po The biggest problem right that I came across is that after the translated strings are put back into the xml document, the formatting is screwed up as the po tools don't know our rules. So, it would we really cool if we had a tool that does this for us that we could run after the po4a-translate step. Another issue is that when I tried po4a-gettextize to extract the strings from an already existing translation the tool bailed out early because it can only match string by string. Since the translation and the english original doc have drifted too far apart and sometimes you would make two sentences for one english sentence, the tool cannot cope with it. I don't have a solution for this yet, but it would be a shame to throw away the already existing translations and not use them to feed a translation memory. > The PC-BSD folks are using tools like Pootle, but not for DocBook > (as far as I know). They have a web site for translation, useful > as an example of what can be done: http://pootle.pcbsd.org/ > > Benedict (CCed) has made some progress with some of these tools. > I think there are plans to add a page to the wiki, but don't know > if it is present yet. I put everything in the DevSummit wiki page and will start a separate one with the results from the summit to continue from there: https://wiki.freebsd.org/201405DevSummit/Translation Regards Benedict Reuschling Documentation Committer The FreeBSD Project The FreeBSD Documentation Project -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTAyQbAAoJEAQa31nbPD2LLVsH/1DzRh3y2Wm5YTfo+OzmQTz9 9XKZTTaP3kF20HqGamMPOgEJdY8Szo6sBNJyPoPtkzBWHcsUv7s2W49MGwIRkdwc yACdIPrladNXc77BpgwNsqoWGLsSElllqe2vYQNlICUrZbqgHC2a52eTtOi1QJZ5 P98M7wDtHFaxLdxKb17qBaL9/mvx5HhLXc6ZwP1GbKHvPWUtTN08H/BiGRc5cy1s yTPqP/xmQNm7l3VTURfMqyuJykG+nbxpr6FvupDSo25rDfbxi0z+wcUeR1c7hLol Vsh2p3Spx48Cc0Ccfj4vP+4Bdt6eiJ/O8jsofroZZKk1l+zBMhxbuVt3TugVgX4= =u0pT -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 09:14:56 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 291D44BB; Tue, 18 Feb 2014 09:14:56 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [IPv6:2a01:4f8:141:5ffd::25]) by mx1.freebsd.org (Postfix) with ESMTP id 970031D8A; Tue, 18 Feb 2014 09:14:55 +0000 (UTC) Received: from [IPv6:2001:470:d701::bd77:6b17:67c4:9e19] (unknown [IPv6:2001:470:d701:0:bd77:6b17:67c4:9e19]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id A871A3F489; Tue, 18 Feb 2014 10:14:53 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_8490BBE2-1C7D-46FC-8D88-9822E828386F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) From: Remko Lodder In-Reply-To: Date: Tue, 18 Feb 2014 10:14:52 +0100 Message-Id: References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> To: Warren Block X-Mailer: Apple Mail (2.1827) Cc: "freebsd-doc@freebsd.org" , Xin LI , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 09:14:56 -0000 --Apple-Mail=_8490BBE2-1C7D-46FC-8D88-9822E828386F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Feb 2014, at 06:19, Warren Block wrote: > On Mon, 17 Feb 2014, Xin Li wrote: >=20 >> (redirecting to freebsd-doc@) >=20 > Subject changed. >=20 >> On 2/17/14, 7:10 PM, Warren Block wrote: >>>=20 >>> I'm sorry, these multiple whitespace changes were my fault due to >>> a mixup with Allan Jude's original patch. Normally, it would have >>> been a single commit. >>>=20 >>> I apologize for this difficulty. >>=20 >> Well, please don't take it too personally :) >=20 > Thanks. :) >=20 >>> Would it help if these changes were reverted with a "reverse merge" >>> of r43920, r43921, r43973, r43974, and r43975, then recommitted >>> with the whitespace patches combined, or is it too late for that? >>=20 >> I think using a batch of commits instead of one big commit is >> generally a good idea because the diff is easier to read/merge. What >> makes it hard to track is when the space changes are made in larger >> timespan as they would be harder to ignore them or need more manual >> intervention. >=20 > I think I understand. Part of my difficulty is being monolingual, = it's hard for me to see exactly what translators do. Benedict has = explained it to me, but it sounds so difficult to track changes that = it's hard to believe anyone can keep up with it. >=20 > (Oh, and if those changes need to be reverted, let's do that as soon = as possible.) The main part that we do for nl_NL is that we diff the English version = from the revision that our current workset is based upon, to a defined = workset later in time. (For my project at work I set the revision to work = towards in stone to keep it manageable). that means you will get a svn diff = r1:r2 $file (like svn diff -r 40588:43328 = en_US.ISO8859-1/books/handbook/basics/chapter.xml ) That gives a lot of output that we need to parse through; style and = whitespace changes increase the amount of changes we need to read through. A space = or tab (or EOL character) is a change that we need to spot -> more of those = changes -> more work to get the content in sync again. My project at work is not able to keep up with the =91content spree=92 = that Dru is doing to make things better. Good work, but a drama for translation = teams that need to be in sync first (and with a train that moves so fast, it will = remain out of date). >=20 >>> If there is any way I or other committers can make this easier for >>> translators, please post on the -doc mailing list or to me >>> invididually. >>=20 >> One thing I would recommend is to separate the contents that do not >> need translation (e.g. tags, entities, etc.) and contents that needs >> translation. This way, these contents would serve as a positioning >> blocks when merging from upstream (English). >=20 > That sounds interesting, and leads well into the next part: Afair we do not translate those for nl_NL unless it is really needed. I think that the normal English version for those kind of things is = really what we need ;) >=20 >>> We are also trying to modernize the translation process, and >>> automate some of the work that translators are currently forced to >>> do. Anyone who would like to help with that is welcome. >>=20 >> That would be great! How can we help, or is there some kind of TODO = list? >=20 > There are several things that would be helpful. >=20 > We could use help from people who are experienced with using the = .po/.pot/.mo tools (gettext) on other platforms. >=20 > The basic process is to separate all the content from the markup = automatically. Then an editor can be used to add translations, and the = tool puts a translated file back together from it. This allows the = translation program to remember existing translations, so translating = one document helps translate others. >=20 > textproc/itstool is one of the automatic separator programs. I've = been somewhat stymied trying to figure out how to get the Python libxml2 = implementation used by it to find FreeBSD documentation XML catalogs. = Documentation on this is... let's just say sparse. >=20 > The PC-BSD folks are using tools like Pootle, but not for DocBook (as = far as I know). They have a web site for translation, useful as an = example of what can be done: http://pootle.pcbsd.org/ >=20 > Benedict (CCed) has made some progress with some of these tools. I = think there are plans to add a page to the wiki, but don't know if it is = present yet. Do note that translating strings of text might have a dramatic result; = especially in non english versions, one translation might fit the one line but the = other line wouldn=92t fit. Although ofcourse this sounds interesting there is much = more to it. (we do not have a set of predefined things we mention like $_[LANG] =3D = =93The bird flew over the house=94; which is used once or perhaps twice. We have = =91rolling=92 content like a book. Cheers Remko > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" --=20 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News --Apple-Mail=_8490BBE2-1C7D-46FC-8D88-9822E828386F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTAySMAAoJEKjD27JZ84ywxvAQAIfUuCDU9j4qiXCco6d8/XFf /HxmrOC/ks05drr/f9SGiZ9H6dsiztg1Kpt6GsmNbVbAIK5BrJ4m9/njDz4AEPyG xuNPmWSqZarAG/9/VoFIfyeK16FQGNP50kbmzPZSIm1crbvncI2wgz5HGbkQUWCl c9mSYOfKrmlYoZNkdj0PnTZSBhOLWbUAnri1LAqFEGHNCHtWhsh8nERcj0hqoO+A uWpz0hruHZ5yuJB7hB7Q/jC+mffHhuf/pqcsYaGcs8LCnPiwnJjCla+tHjlHKL5+ xuGi8RNXeRx7TgBfic2wEgBMKXM0wHqfJEyBud23/zH5wPHBPA8+Zy/Vuv/A+Jlw hFR1auJ0xKX8otf41nLNlNV7SoRdVS9b5SQfpa+HLc0NRYMWpyXQ4Ze4fWbjIy7C RtwfGlhILaclWpYDBFFmuAECqDqnmb6TO5fHJi7wlujN53tiu9eyeVL3ipzqbUTH NeSxJTz400wBufpVOAybt5D8HqAmSLV9o8ecc5t79UrzRDF2IoGZ2xEAxHGUsqsV ANsFtZo+EWUXMNpgaEoJRWbu8XJvmxDwSL67QszCKAVGN5AezmhO+7e0mTDucSw+ iOsyjqcNG2/Vw/5hn1rn65YJsSEFa56lz31AvkJSq+C2sGInL/WCylN0hcOS3cgx yevSL6NQLpmNA7HXHVIM =cFLs -----END PGP SIGNATURE----- --Apple-Mail=_8490BBE2-1C7D-46FC-8D88-9822E828386F-- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 16:17:58 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 126C3606; Tue, 18 Feb 2014 16:17:58 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98E941735; Tue, 18 Feb 2014 16:17:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1IGHoGN048004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Feb 2014 09:17:50 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1IGHoLI048001; Tue, 18 Feb 2014 09:17:50 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 18 Feb 2014 09:17:50 -0700 (MST) From: Warren Block To: Remko Lodder Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) In-Reply-To: Message-ID: References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 18 Feb 2014 09:17:50 -0700 (MST) Cc: "freebsd-doc@freebsd.org" , Xin LI , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:17:58 -0000 On Tue, 18 Feb 2014, Remko Lodder wrote: > My project at work is not able to keep up with the ?content spree? that Dru is > doing to make things better. Good work, but a drama for translation teams that > need to be in sync first (and with a train that moves so fast, it will remain > out of date). Maybe the only way to do that is translate a fixed revision/snapshot. At least with our existing system. > Do note that translating strings of text might have a dramatic result; especially > in non english versions, one translation might fit the one line but the other line > wouldn?t fit. Although ofcourse this sounds interesting there is much more to it. > (we do not have a set of predefined things we mention like $_[LANG] = ?The bird > flew over the house?; which is used once or perhaps twice. We have ?rolling? content > like a book. Translation software like Pootle or poedit generally gives the translator the choice. Content is shown in chunks, like a title or a sentence. If one or more translations of that chunk already exist (either from the current document or a different one!), the translator can choose from them, or enter a better translation of their own. This would radically change the way we do things. Translators would still need to be aware that source documents had changed, but the translation software would identify parts that were not yet translated. It would ease the job for existing translators and lower the threshold for new translators. Obviously, this is all vague and ill-defined. Actual implementations that can be tested would be much more useful. I believe the tools in textproc/po4a are from Debian and somewhat dated. textproc/itstool might do a better job separating content if we can just get it to recognize and use our XML catalogs. An easy way for translators to try it out is the next step. From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 17:32:52 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 172E94AB for ; Tue, 18 Feb 2014 17:32:52 +0000 (UTC) Received: from build-web.stream.freebsd.org (build-web.stream.freebsd.org [IPv6:2001:1900:2254:206a::16:6504]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 035B01E59 for ; Tue, 18 Feb 2014 17:32:52 +0000 (UTC) Received: from build-web.stream.freebsd.org ([127.0.1.2]) by build-web.stream.freebsd.org (8.14.7/8.14.7) with ESMTP id s1IHWpJR060590 for ; Tue, 18 Feb 2014 17:32:51 GMT (envelope-from www-data@build-web.stream.freebsd.org) Received: (from www-data@localhost) by build-web.stream.freebsd.org (8.14.8/8.14.8/Submit) id s1IHWpCD060588 for freebsd-doc@FreeBSD.org; Tue, 18 Feb 2014 17:32:51 GMT (envelope-from www-data) Date: Tue, 18 Feb 2014 17:32:51 GMT From: User Www-data Message-Id: <201402181732.s1IHWpCD060588@build-web.stream.freebsd.org> To: freebsd-doc@FreeBSD.org Subject: FreeBSD web build failed on build-web.stream.freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:32:52 -0000 ===> ../../ru_RU.KOI8-R/htdocs/news/2000 ===> ../../ru_RU.KOI8-R/htdocs/news/2001 ===> ../../ru_RU.KOI8-R/htdocs/news/2002 ===> ../../ru_RU.KOI8-R/htdocs/news/2003 ===> ../../ru_RU.KOI8-R/htdocs/news/status ===> ../../ru_RU.KOI8-R/htdocs/platforms ===> ../../ru_RU.KOI8-R/htdocs/platforms/amd64 ===> ../../ru_RU.KOI8-R/htdocs/platforms/ia64 ===> ../../ru_RU.KOI8-R/htdocs/portmgr ===> ../../ru_RU.KOI8-R/htdocs/projects ===> ../../ru_RU.KOI8-R/htdocs/projects/busdma ===> ../../ru_RU.KOI8-R/htdocs/prstats ===> ../../ru_RU.KOI8-R/htdocs/releases ===> ../../ru_RU.KOI8-R/htdocs/releases/5.3R ===> ../../ru_RU.KOI8-R/htdocs/releases/5.4R ===> ../../ru_RU.KOI8-R/htdocs/releng ===> ../../ru_RU.KOI8-R/htdocs/search ===> ../../ru_RU.KOI8-R/htdocs/security ===> ../../ru_RU.KOI8-R/htdocs/snapshots ===> ../../ru_RU.KOI8-R/htdocs/support ===> ../../ru_RU.KOI8-R/htdocs/tutorials ===> ../../zh_CN.UTF-8/htdocs ===> ../../zh_CN.UTF-8/htdocs/advocacy ===> ../../zh_CN.UTF-8/htdocs/copyright ===> ../../zh_CN.UTF-8/htdocs/news ===> ../../zh_CN.UTF-8/htdocs/platforms ===> ../../zh_CN.UTF-8/htdocs/platforms/amd64 ===> ../../zh_CN.UTF-8/htdocs/releases ===> ../../zh_CN.UTF-8/htdocs/releases/5.4R ===> ../../zh_CN.UTF-8/htdocs/releases/5.5R ===> ../../zh_CN.UTF-8/htdocs/releases/6.0R ===> ../../zh_CN.UTF-8/htdocs/releases/6.1R ===> ../../zh_CN.UTF-8/htdocs/releases/6.2R ===> ../../zh_CN.UTF-8/htdocs/releases/6.3R ===> ../../zh_CN.UTF-8/htdocs/releases/7.0R ===> ../../zh_CN.UTF-8/htdocs/releases/7.1R ===> ../../zh_CN.UTF-8/htdocs/releases/7.2R ===> ../../zh_CN.UTF-8/htdocs/security ===> ../../zh_CN.UTF-8/htdocs/layout ===> ../../zh_CN.UTF-8/htdocs/layout/css ===> ../../zh_TW.Big5/htdocs ===> ../../zh_TW.Big5/htdocs/docs ===> ../../zh_TW.Big5/htdocs/layout ===> ../../zh_TW.Big5/htdocs/layout/css 13.81 real 6.60 user 7.82 sys mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied *** [realinstall] Error code 1 Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. 0.03 real 0.02 user 0.01 sys From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 17:33:53 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE16D507 for ; Tue, 18 Feb 2014 17:33:53 +0000 (UTC) Received: from build-web.stream.freebsd.org (build-web.stream.freebsd.org [IPv6:2001:1900:2254:206a::16:6504]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA7191F66 for ; Tue, 18 Feb 2014 17:33:53 +0000 (UTC) Received: from build-web.stream.freebsd.org ([127.0.1.2]) by build-web.stream.freebsd.org (8.14.7/8.14.7) with ESMTP id s1IHXruS066618 for ; Tue, 18 Feb 2014 17:33:53 GMT (envelope-from www-data@build-web.stream.freebsd.org) Received: (from www-data@localhost) by build-web.stream.freebsd.org (8.14.8/8.14.8/Submit) id s1IHXrJW066616 for freebsd-doc@FreeBSD.org; Tue, 18 Feb 2014 17:33:53 GMT (envelope-from www-data) Date: Tue, 18 Feb 2014 17:33:53 GMT From: User Www-data Message-Id: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> To: freebsd-doc@FreeBSD.org Subject: FreeBSD web build failed on build-web.stream.freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:33:53 -0000 ===> ../../ru_RU.KOI8-R/htdocs/news/2000 ===> ../../ru_RU.KOI8-R/htdocs/news/2001 ===> ../../ru_RU.KOI8-R/htdocs/news/2002 ===> ../../ru_RU.KOI8-R/htdocs/news/2003 ===> ../../ru_RU.KOI8-R/htdocs/news/status ===> ../../ru_RU.KOI8-R/htdocs/platforms ===> ../../ru_RU.KOI8-R/htdocs/platforms/amd64 ===> ../../ru_RU.KOI8-R/htdocs/platforms/ia64 ===> ../../ru_RU.KOI8-R/htdocs/portmgr ===> ../../ru_RU.KOI8-R/htdocs/projects ===> ../../ru_RU.KOI8-R/htdocs/projects/busdma ===> ../../ru_RU.KOI8-R/htdocs/prstats ===> ../../ru_RU.KOI8-R/htdocs/releases ===> ../../ru_RU.KOI8-R/htdocs/releases/5.3R ===> ../../ru_RU.KOI8-R/htdocs/releases/5.4R ===> ../../ru_RU.KOI8-R/htdocs/releng ===> ../../ru_RU.KOI8-R/htdocs/search ===> ../../ru_RU.KOI8-R/htdocs/security ===> ../../ru_RU.KOI8-R/htdocs/snapshots ===> ../../ru_RU.KOI8-R/htdocs/support ===> ../../ru_RU.KOI8-R/htdocs/tutorials ===> ../../zh_CN.UTF-8/htdocs ===> ../../zh_CN.UTF-8/htdocs/advocacy ===> ../../zh_CN.UTF-8/htdocs/copyright ===> ../../zh_CN.UTF-8/htdocs/news ===> ../../zh_CN.UTF-8/htdocs/platforms ===> ../../zh_CN.UTF-8/htdocs/platforms/amd64 ===> ../../zh_CN.UTF-8/htdocs/releases ===> ../../zh_CN.UTF-8/htdocs/releases/5.4R ===> ../../zh_CN.UTF-8/htdocs/releases/5.5R ===> ../../zh_CN.UTF-8/htdocs/releases/6.0R ===> ../../zh_CN.UTF-8/htdocs/releases/6.1R ===> ../../zh_CN.UTF-8/htdocs/releases/6.2R ===> ../../zh_CN.UTF-8/htdocs/releases/6.3R ===> ../../zh_CN.UTF-8/htdocs/releases/7.0R ===> ../../zh_CN.UTF-8/htdocs/releases/7.1R ===> ../../zh_CN.UTF-8/htdocs/releases/7.2R ===> ../../zh_CN.UTF-8/htdocs/security ===> ../../zh_CN.UTF-8/htdocs/layout ===> ../../zh_CN.UTF-8/htdocs/layout/css ===> ../../zh_TW.Big5/htdocs ===> ../../zh_TW.Big5/htdocs/docs ===> ../../zh_TW.Big5/htdocs/layout ===> ../../zh_TW.Big5/htdocs/layout/css 13.59 real 6.06 user 8.14 sys mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied *** [realinstall] Error code 1 Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. 0.03 real 0.00 user 0.02 sys From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 17:36:58 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34875692; Tue, 18 Feb 2014 17:36:58 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 058B71FAD; Tue, 18 Feb 2014 17:36:58 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 101F11C463; Tue, 18 Feb 2014 17:36:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 101F11C463 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 18 Feb 2014 12:36:55 -0500 From: Glen Barber To: freebsd-doc@FreeBSD.org Subject: Re: FreeBSD web build failed on build-web.stream.freebsd.org Message-ID: <20140218173655.GT1667@glenbarber.us> References: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2OFxhqPNSAodNyNc" Content-Disposition: inline In-Reply-To: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:36:58 -0000 --2OFxhqPNSAodNyNc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2014 at 05:33:53PM +0000, User Www-data wrote: > [...] > > 13.59 real 6.06 user 8.14 sys > mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied > *** [realinstall] Error code 1 >=20 > Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. > 0.03 real 0.00 user 0.02 sys Whoops. This is me "fixing" things. Glen --2OFxhqPNSAodNyNc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTA5o3AAoJELls3eqvi17Qx1EP/23rz+Z975YxU7KkiqWA8h1t xpI46gFAJ6wvikbBra/w0YE6215kSbMGnwqFkzRDnxjIfxcYwrLdri/YAhN46xQX KPC2yiyVwthYUu3evAoSxgo8KENtTyiAA69vUHvRJeGUDSoQEdjnTp25HnyzTwpc vXAQSWS1y1GPua4gnw5ZHP0KAJxvHYpxaho0DOBqq5/P4td8KoyIw/e5oeY7+aX1 I5D12kP0B9tZ76NVtmdHaZxvuoqh7dC4EPXc2+jmTV3Pluq8dgkEQGP92ceegGE/ 8KBhXOmJbHL5TIJyNiSUgGCJ6SVCEN+Q/LqwTqVy9ouDzRdXns2ltwiby5Lea+SL kV7LDpSBBnk3DfrmLyFAbVSgoMwlKCsKinSrpFRqLIlQMXt+T3LXSog/Ne9C3cnt xif8GKqckjGNCywGpia3MNkOX7HybCkz3vrkl7uvQ8Pu5zlHpp+TExaZQq/CFjCY Wboy9Rp4JHEzBWm9OV2EAbzYtqgvpPEGtpiMixi+9Vml4H4ikXhSDHFH4PWa8qK0 qUMa4uzmfk4etDb55XbP/BOt7fmfn8MXKilVjzKn9MXCOlBQ+PJWENThzskjmEaL YRKqPD3L9ZFd/TimE7fys6aDorNuv9flANFuzhyfXqQCHepcB/awV+1fiC59HnS4 2kyM8WHElTWkHVdNUb8j =4dya -----END PGP SIGNATURE----- --2OFxhqPNSAodNyNc-- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 19:21:54 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17FB1137; Tue, 18 Feb 2014 19:21:54 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [78.47.69.234]) by mx1.freebsd.org (Postfix) with ESMTP id 9054E19BE; Tue, 18 Feb 2014 19:21:53 +0000 (UTC) Received: from [10.0.2.17] (a44084.upc-a.chello.nl [62.163.44.84]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id 5F8343F489; Tue, 18 Feb 2014 20:21:51 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_22F44B04-2886-464B-9974-6E491FFA4D46"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) From: Remko Lodder In-Reply-To: Date: Tue, 18 Feb 2014 20:21:49 +0100 Message-Id: <2A866B00-A040-4726-AD95-04E0F413FEBC@FreeBSD.org> References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> To: Warren Block X-Mailer: Apple Mail (2.1827) Cc: "freebsd-doc@freebsd.org" , Xin LI , Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:21:54 -0000 --Apple-Mail=_22F44B04-2886-464B-9974-6E491FFA4D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18 Feb 2014, at 17:17, Warren Block wrote: > On Tue, 18 Feb 2014, Remko Lodder wrote: >=20 >> My project at work is not able to keep up with the ?content spree? = that Dru is >> doing to make things better. Good work, but a drama for translation = teams that >> need to be in sync first (and with a train that moves so fast, it = will remain >> out of date). >=20 > Maybe the only way to do that is translate a fixed revision/snapshot. = At least with our existing system. >=20 >> Do note that translating strings of text might have a dramatic = result; especially >> in non english versions, one translation might fit the one line but = the other line >> wouldn?t fit. Although ofcourse this sounds interesting there is much = more to it. >> (we do not have a set of predefined things we mention like $_[LANG] =3D= ?The bird >> flew over the house?; which is used once or perhaps twice. We have = ?rolling? content >> like a book. >=20 > Translation software like Pootle or poedit generally gives the = translator the choice. Content is shown in chunks, like a title or a = sentence. If one or more translations of that chunk already exist = (either from the current document or a different one!), the translator = can choose from them, or enter a better translation of their own. >=20 > This would radically change the way we do things. Translators would = still need to be aware that source documents had changed, but the = translation software would identify parts that were not yet translated. = It would ease the job for existing translators and lower the threshold = for new translators. >=20 > Obviously, this is all vague and ill-defined. Actual implementations = that can be tested would be much more useful. I believe the tools in = textproc/po4a are from Debian and somewhat dated. textproc/itstool = might do a better job separating content if we can just get it to = recognize and use our XML catalogs. >=20 > An easy way for translators to try it out is the next step. Since I do not have -that- much free time at the moment, and a new = assignment might interfere with my current project, I cannot do the heavy lifting of this. I am willing to test = this though if someone has something that I can try to work with. Cheers and keep up the good work :-))) Remko > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" --=20 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News --Apple-Mail=_22F44B04-2886-464B-9974-6E491FFA4D46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTA7LNAAoJEKjD27JZ84ywt0UP/1VA4dby1jm6wZ+F8lCD6mVz bbbgLRZB/3XJlAafSf8VRYGjPgt4fYw4TgSMVMVpGUdsRQMuOxTjugKeSp+jMgzv owI5JxospgfYYygA0BWzTNJAKsgOeqiohVNqGcrIWNH9tSjbRjg8yA7bHDuVEgLb 2+pbCZ9YGmMKH3h3v52kIHqoDkN/Eyvia2dChsJTDo5DiOzNKfrt2IofbAANrTu+ HSHIr2RzzSmbIAPjMASe+c3qyeNLOHrBBuNPMBVC+BMR0MIBgntFDn6s+hI1tv8Y 1+iFbyW5ULOyxTHLuw8yGyO4zMqr4tdYqpiyi34NW3tPzLwi043c2Wi6M9iHq4N2 95glQGSMDqPblGO+W/zwQ/jjgNO+QL4UtoHaEI2OXWw90QvK3oHnXBOFulSJFUFm HPSkS4iLs/PVOC7Pox3xcQscgyDqr9MTaJAVmzEAhILTxsKVX/Jq8wS2U4OnJvyD du6z5k8HmFes9elay9jN2T+3ekHXO182WPB/8v5Oz/n3eunKxx3LJ5dUlRmfh6zY Mx6uwLL0sgWMTjX4icoDd/1OHHCBDiI5gdBXRlQYOLCBAVJzKuspKTTBjkA0VpmC B8eVJLZpuxyYCfn/zxYr+MGzURXMOjzAjZsaveza4o3I+Srdj9ECWBXTHmlWL3lv PlBfZydeVWSrZM1YKgt6 =lQ9U -----END PGP SIGNATURE----- --Apple-Mail=_22F44B04-2886-464B-9974-6E491FFA4D46-- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 19:32:59 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 763766A7; Tue, 18 Feb 2014 19:32:59 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45E701AD9; Tue, 18 Feb 2014 19:32:59 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 3CB641CE27; Tue, 18 Feb 2014 19:32:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 3CB641CE27 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 18 Feb 2014 14:32:56 -0500 From: Glen Barber To: freebsd-doc@FreeBSD.org Subject: Website now autocleans old files/pages (was: Re: FreeBSD web build failed on build-web.stream.freebsd.org) Message-ID: <20140218193256.GU1667@glenbarber.us> References: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> <20140218173655.GT1667@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AJ3oM32U01nchLSz" Content-Disposition: inline In-Reply-To: <20140218173655.GT1667@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:32:59 -0000 --AJ3oM32U01nchLSz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2014 at 12:36:55PM -0500, Glen Barber wrote: > On Tue, Feb 18, 2014 at 05:33:53PM +0000, User Www-data wrote: > > [...] > > > > 13.59 real 6.06 user 8.14 sys > > mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied > > *** [realinstall] Error code 1 > >=20 > > Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. > > 0.03 real 0.00 user 0.02 sys >=20 > Whoops. >=20 > This is me "fixing" things. >=20 So, what I was working on is making the build clean up after itself, in particular, things that are no longer part of the build. DESTDIR has changed, and is purged before every build (even the "quick" incremental builds). Once the build finishes, the files are installed to the new DESTDIR, then synced to the public web root. When a full site refresh is done (once a week, as was done before), rsync is called with '--delete', so anything removed from the DESTDIR will be purged from the public web root. Glen --AJ3oM32U01nchLSz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTA7VoAAoJELls3eqvi17Q/JoQAMt/WndBtIR1pY4Pig88ZGTs ZePTQ7Tgvq3iSpbmJyt9Hvf6UguH0+KfA50bj5Ua2VvVRE3C+6EkJZ4bFABgpco9 7RFJ854NmvbJDZjgO8LnYp3/oA6Ad+SRsjBgaeUgTiXsFJwelq73tgryKgeLQWN1 PkBphJtq0sxquRTxrYiQy4oibnBIyp0OlgkObpxrTazNyt8c+ZlB6/+pc4ReTCy5 kgKB+x28CYrYsvOaTuMNFJXfENyfmdfnkBIZGLrrBdW8JmhTIUf+V0Q2BLL+062n QSS4vDdbeZeo5dZRgxxjLZJdZj1p4ceci2Cb4/SV2JyOV01+HGu10uKXXOvY0lvg p0FXrHbuf3AGortAVfb3zzEN3HA4t8+AqNfZBzuMUm0kEcNW1PiSW4JBrCG9lnJ/ ThvsmMI3ITfO19xy/76DDWOvW3WyUUvm8wxcQhK/zVmqu/k3ewm5W96T+qL59dVJ I/L1j1S0LHnZYCCGeJ3UC4gI4Wr6zhE8DYXsd0DlLxVmRXO/qFLVlXCL8K+gUpR4 plUsuA2lvzk1TJ5a5p6wcrYjlsKwD21/6EW7tdmOFQ9arwEq7v1nQTRKPU1w8opJ Ux7EoCEoPmIOR6EJ2S7nQSoNK5SpyAdscZfN5/5ibAHIQhCp7MYBSNi2fwaOQJV4 sVBawgPRxjizbnLbDghV =RuhK -----END PGP SIGNATURE----- --AJ3oM32U01nchLSz-- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 19:41:44 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6467FE9 for ; Tue, 18 Feb 2014 19:41:44 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC1C1C03 for ; Tue, 18 Feb 2014 19:41:44 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id w5so24211673qac.3 for ; Tue, 18 Feb 2014 11:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NVFCRuo/88JE2xr6nK50F9kpLbySRBUnveLDScrHplA=; b=NZnCEbG2S6H11/Fc9jnFC4OaZVkHqdAaKH7F0i8IP/6S81wnJFLWqRr5Cbi7pVf1KB qUY4QAk2Qs/Lln/FZYX+7hb884vc3wRW3NHQo2eJOGU9WaFfIt+mKOe0dOeYL0g3D24O o44BXa4+pSAyRiTGKxPnLpCVcVKX6VRNVZO6M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NVFCRuo/88JE2xr6nK50F9kpLbySRBUnveLDScrHplA=; b=hxi32ziQFfNMejkDX/kMFrSlTNqTLSJJvjlkcYm8UiHJm0sh6tXkO8bacuHsZ9OAnx INg7uLj5+n6+u7GO1uXKmqyapeWZLpxXN9X6uH76zsiVftY+pN8a/Pez6p2BRKF6TPy6 MJoGEHMPu1IFWhpzEAMr+IZ960hC2dfaXTtJohIb7/aID/0iiasKmrFc5/p12JIto9yE 7HOj9bUMS7/zWReXRCs3vC0m5FP1RhpiU9cKZx8UT8lfUPzg/E9GYEqksHtnhPqjL0R3 Hgvn/8PSNOah2SziqYWrp4KEU8jXt2S05StnUEYjKPjkly/i3TNQ2fiMEsLAf2Al2Jgw JbTw== X-Gm-Message-State: ALoCoQnnuwEr9MzyfKucsrmBs5GIOKWF/brYnLCWSrvyMqp3XlfYPN4sCslE/Nhy0dswDtu1MYzL X-Received: by 10.140.85.179 with SMTP id n48mr12133488qgd.91.1392752503603; Tue, 18 Feb 2014 11:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.175.169 with HTTP; Tue, 18 Feb 2014 11:41:13 -0800 (PST) In-Reply-To: <20140218193256.GU1667@glenbarber.us> References: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> <20140218173655.GT1667@glenbarber.us> <20140218193256.GU1667@glenbarber.us> From: Eitan Adler Date: Tue, 18 Feb 2014 14:41:13 -0500 Message-ID: Subject: Re: Website now autocleans old files/pages (was: Re: FreeBSD web build failed on build-web.stream.freebsd.org) To: Glen Barber Content-Type: text/plain; charset=UTF-8 Cc: freebsd-doc@freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:41:45 -0000 On Tue, Feb 18, 2014 at 2:32 PM, Glen Barber wrote: > On Tue, Feb 18, 2014 at 12:36:55PM -0500, Glen Barber wrote: >> On Tue, Feb 18, 2014 at 05:33:53PM +0000, User Www-data wrote: >> > [...] >> > >> > 13.59 real 6.06 user 8.14 sys >> > mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied >> > *** [realinstall] Error code 1 >> > >> > Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. >> > 0.03 real 0.00 user 0.02 sys >> >> Whoops. >> >> This is me "fixing" things. >> > > So, what I was working on is making the build clean up after itself, in > particular, things that are no longer part of the build. > > DESTDIR has changed, and is purged before every build (even the "quick" > incremental builds). Once the build finishes, the files are installed > to the new DESTDIR, then synced to the public web root. > > When a full site refresh is done (once a week, as was done before), > rsync is called with '--delete', so anything removed from the DESTDIR > will be purged from the public web root. This is awesome. Thanks for working on it! -- Eitan Adler From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 19:50:48 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F3B7517 for ; Tue, 18 Feb 2014 19:50:48 +0000 (UTC) Received: from mxout2.bln1.prohost.de (mxout2.bln1.prohost.de [91.233.87.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B93771D16 for ; Tue, 18 Feb 2014 19:50:47 +0000 (UTC) Received: from Voyager.local (p4FC716D5.dip0.t-ipconnect.de [79.199.22.213]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.4/8.14.4) with ESMTP id s1IJogFa005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Feb 2014 20:50:42 +0100 Message-ID: <5303B993.2030505@FreeBSD.org> Date: Tue, 18 Feb 2014 20:50:43 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> <2A866B00-A040-4726-AD95-04E0F413FEBC@FreeBSD.org> In-Reply-To: <2A866B00-A040-4726-AD95-04E0F413FEBC@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Null-Tag: 22d0966490aa2e27bd507d9c7793477f X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:50:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 18.02.14 20:21, schrieb Remko Lodder: > > On 18 Feb 2014, at 17:17, Warren Block wrote: > >> On Tue, 18 Feb 2014, Remko Lodder wrote: >> >>> My project at work is not able to keep up with the ?content >>> spree? that Dru is doing to make things better. Good work, but >>> a drama for translation teams that need to be in sync first >>> (and with a train that moves so fast, it will remain out of >>> date). >> >> Maybe the only way to do that is translate a fixed >> revision/snapshot. At least with our existing system. >> >>> Do note that translating strings of text might have a dramatic >>> result; especially in non english versions, one translation >>> might fit the one line but the other line wouldn?t fit. >>> Although ofcourse this sounds interesting there is much more to >>> it. (we do not have a set of predefined things we mention like >>> $_[LANG] = ?The bird flew over the house?; which is used once >>> or perhaps twice. We have ?rolling? content like a book. >> >> Translation software like Pootle or poedit generally gives the >> translator the choice. Content is shown in chunks, like a title >> or a sentence. If one or more translations of that chunk already >> exist (either from the current document or a different one!), the >> translator can choose from them, or enter a better translation of >> their own. >> >> This would radically change the way we do things. Translators >> would still need to be aware that source documents had changed, >> but the translation software would identify parts that were not >> yet translated. It would ease the job for existing translators >> and lower the threshold for new translators. >> >> Obviously, this is all vague and ill-defined. Actual >> implementations that can be tested would be much more useful. I >> believe the tools in textproc/po4a are from Debian and somewhat >> dated. textproc/itstool might do a better job separating content >> if we can just get it to recognize and use our XML catalogs. >> >> An easy way for translators to try it out is the next step. > > Since I do not have -that- much free time at the moment, and a new > assignment might interfere with my current project, I cannot do the > heavy lifting of this. I am willing to test this though if someone > has something that I can try to work with. > You can start with the I posted earlier. That's what I used. I recommend you try it with a small article (or you cut one down to like two 's) to see results early without having to translate the whole thing. I've used poedit because it is multi-platform, but I still did an iconv run before commit (if you want to go that far). The important stuff lies in the po-file later on, which you can also feed into poedit to build up a translation memory to be used for another document. For me, this is the most important thing: reuse. I don't know how many times I've translated "Enter the following command" and similar phrases. With this new approach, these would be fed from the translation memory (of course, you can or make small changes to it like Warren mentioned) and concentrate on the new, untranslated strings. The same is true for words like MAKEFILE, names of products, people, and similar things that don't need to be translated. Sharing these in a common database across translation projects will ensure a consistent vocabulary. Putting these strings out for anyone to translate would be a good thing to get more translations than we already have. Collecting these in a database for mixing and matching them to a final translated document is the next step and would probably be done by someone familiar with the source material. But the burden of doing the actual translation work can be put into the hands of people who don't need to know how our doc toolchain works or even how the xml documents look like. That is still the work for a doc committer, but the tedious part could be put on many more shoulders. Regards Benedict -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTA7mTAAoJEAQa31nbPD2Lr6UIALg9+edKEk7AgBGY2iyZl4nl XUgosad0QvaN4OXf9dQjuR2B8KTZfc0PibyeVbjtszBWNBdLDDO5A50JgLKY6Rk2 aghijDZ8C+kR2P5FUQgGe4V1bKdI72OfQphpp/u7jMyacY0ZAgenxPBez5/RVOdA pt84xMeL19yIfEech0ZwBYVbz1Cb37FMI3AnUlhBUhkANU4IxWEP8ZkvP0XeEHLG ADhzcNn4/dzVE1y+0fC0S4S0vijq9VT4o2bH+m1U6lGOo3DUZEtLwUFyRkCgrwGa lOVbdsH4+fSScPb2KT1wjuHK0TRDdvgCPFfDzOnXL0IagsogDBhzLIJKu/lJ2+8= =+OuL -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 20:51:08 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A50A53D6; Tue, 18 Feb 2014 20:51:08 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79F2F1355; Tue, 18 Feb 2014 20:51:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1IKp8Zg093443; Tue, 18 Feb 2014 20:51:08 GMT (envelope-from wblock@freefall.freebsd.org) Received: (from wblock@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1IKp8iJ093442; Tue, 18 Feb 2014 20:51:08 GMT (envelope-from wblock) Date: Tue, 18 Feb 2014 20:51:08 GMT Message-Id: <201402182051.s1IKp8iJ093442@freefall.freebsd.org> To: wblock@FreeBSD.org, freebsd-doc@FreeBSD.org, wblock@FreeBSD.org From: wblock@FreeBSD.org Subject: Re: docs/186858: improve handbook ToC readability X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:51:08 -0000 Synopsis: improve handbook ToC readability Responsible-Changed-From-To: freebsd-doc->wblock Responsible-Changed-By: wblock Responsible-Changed-When: Tue Feb 18 20:50:49 UTC 2014 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=186858 From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 20:51:41 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33855425; Tue, 18 Feb 2014 20:51:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0655F1366; Tue, 18 Feb 2014 20:51:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1IKpe9f093580; Tue, 18 Feb 2014 20:51:40 GMT (envelope-from wblock@freefall.freebsd.org) Received: (from wblock@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1IKpeMN093579; Tue, 18 Feb 2014 20:51:40 GMT (envelope-from wblock) Date: Tue, 18 Feb 2014 20:51:40 GMT Message-Id: <201402182051.s1IKpeMN093579@freefall.freebsd.org> To: wblock@FreeBSD.org, freebsd-doc@FreeBSD.org, wblock@FreeBSD.org From: wblock@FreeBSD.org Subject: Re: docs/186857: improve handbook ToC readability X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:51:41 -0000 Synopsis: improve handbook ToC readability Responsible-Changed-From-To: freebsd-doc->wblock Responsible-Changed-By: wblock Responsible-Changed-When: Tue Feb 18 20:51:15 UTC 2014 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=186857 From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 21:17:24 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 287A5C26; Tue, 18 Feb 2014 21:17:24 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20CD51605; Tue, 18 Feb 2014 21:17:22 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1ILH4Z5071281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 06:17:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1ILH2Wq057395; Wed, 19 Feb 2014 06:17:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 19 Feb 2014 05:43:29 +0900 (JST) Message-Id: <20140219.054329.650271381379595985.hrs@allbsd.org> To: gjb@FreeBSD.org Subject: Re: Website now autocleans old files/pages From: Hiroki Sato In-Reply-To: <20140218193256.GU1667@glenbarber.us> References: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> <20140218173655.GT1667@glenbarber.us> <20140218193256.GU1667@glenbarber.us> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Feb_19_05_43_29_2014_231)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 19 Feb 2014 06:17:15 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-doc@FreeBSD.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:17:24 -0000 ----Security_Multipart(Wed_Feb_19_05_43_29_2014_231)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glen Barber wrote in <20140218193256.GU1667@glenbarber.us>: gj> On Tue, Feb 18, 2014 at 12:36:55PM -0500, Glen Barber wrote: gj> > On Tue, Feb 18, 2014 at 05:33:53PM +0000, User Www-data wrote: gj> > > [...] gj> > > gj> > > 13.59 real 6.06 user 8.14 sys gj> > > mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied gj> > > *** [realinstall] Error code 1 gj> > > gj> > > Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. gj> > > 0.03 real 0.00 user 0.02 sys gj> > gj> > Whoops. gj> > gj> > This is me "fixing" things. gj> > gj> gj> So, what I was working on is making the build clean up after itself, in gj> particular, things that are no longer part of the build. gj> gj> DESTDIR has changed, and is purged before every build (even the "quick" gj> incremental builds). Once the build finishes, the files are installed gj> to the new DESTDIR, then synced to the public web root. gj> gj> When a full site refresh is done (once a week, as was done before), gj> rsync is called with '--delete', so anything removed from the DESTDIR gj> will be purged from the public web root. Hmm, replacing www/www.freebsd.org with a symlink might be simpler than copying files in DESTDIR into PUBDIR and removing DESTDIR everytime. Create a staging directory and set DESTDIR to it, do make install as before, and make the symlink to point the DESTDIR as a newly-built document set (and removing the old directory). It does not need copying files and the contents can be switched atomically. Just my $0.02. -- Hiroki ----Security_Multipart(Wed_Feb_19_05_43_29_2014_231)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMDxfEACgkQTyzT2CeTzy25/gCfd2YmWuYq2zPMg5c81n1E1jvk pWQAn303FkCykmH3hgP9jfjTRVABrriB =8p0V -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Feb_19_05_43_29_2014_231)---- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 21:21:48 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3553BCCC; Tue, 18 Feb 2014 21:21:48 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3F811696; Tue, 18 Feb 2014 21:21:47 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id E0F731BA7D; Tue, 18 Feb 2014 21:21:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us E0F731BA7D Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 18 Feb 2014 16:21:39 -0500 From: Glen Barber To: Hiroki Sato Subject: Re: Website now autocleans old files/pages Message-ID: <20140218212139.GW1667@glenbarber.us> References: <201402181733.s1IHXrJW066616@build-web.stream.freebsd.org> <20140218173655.GT1667@glenbarber.us> <20140218193256.GU1667@glenbarber.us> <20140219.054329.650271381379595985.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MgQdU7jr+b9ajvaw" Content-Disposition: inline In-Reply-To: <20140219.054329.650271381379595985.hrs@allbsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-doc@FreeBSD.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:21:48 -0000 --MgQdU7jr+b9ajvaw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2014 at 05:43:29AM +0900, Hiroki Sato wrote: > Glen Barber wrote > in <20140218193256.GU1667@glenbarber.us>: >=20 > gj> On Tue, Feb 18, 2014 at 12:36:55PM -0500, Glen Barber wrote: > gj> > On Tue, Feb 18, 2014 at 05:33:53PM +0000, User Www-data wrote: > gj> > > [...] > gj> > > > gj> > > 13.59 real 6.06 user 8.14 sys > gj> > > mkdir: /usr/local/www/www.freebsd.org-clean: Permission denied > gj> > > *** [realinstall] Error code 1 > gj> > > > gj> > > Stop in /home/www/build/head/en_US.ISO8859-1/htdocs. > gj> > > 0.03 real 0.00 user 0.02 sys > gj> > > gj> > Whoops. > gj> > > gj> > This is me "fixing" things. > gj> > > gj> > gj> So, what I was working on is making the build clean up after itself, = in > gj> particular, things that are no longer part of the build. > gj> > gj> DESTDIR has changed, and is purged before every build (even the "quic= k" > gj> incremental builds). Once the build finishes, the files are installed > gj> to the new DESTDIR, then synced to the public web root. > gj> > gj> When a full site refresh is done (once a week, as was done before), > gj> rsync is called with '--delete', so anything removed from the DESTDIR > gj> will be purged from the public web root. >=20 > Hmm, replacing www/www.freebsd.org with a symlink might be simpler > than copying files in DESTDIR into PUBDIR and removing DESTDIR > everytime. Create a staging directory and set DESTDIR to it, do make > install as before, and make the symlink to point the DESTDIR as a > newly-built document set (and removing the old directory). It does > not need copying files and the contents can be switched atomically. >=20 I did think about this, but did not want to change the permissions on the web root (root:wheel now) to allow the unprivileged user to arbitrarily create symlinks. Glen --MgQdU7jr+b9ajvaw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTA87jAAoJELls3eqvi17QugEQAJo6tyyKSdTrqujINOWUs0Oc IjbRU+g95Hdm/5YkQfaQtobbmzgXKbGTRSd6+sX2vDnA4UAH4utLO1zvk13G2BPD aheP5mQWKaS4D1W4Y4Jdxxbq01hDKBMSAEimZiDfvWsGqj3Wg0bpvHIELZ5HMeCC x/0Bz430B/jWHsmjo7pgfnJ8S/awAcPC0xe8uUyINAuHM4Xzvutgou2j2j4G9Shr C1UZVTgRXqbvD2nnztLrbibUoZWrPjQYbJ1y8ODglWwN8jG5KTsCARr2rWPC/agw GOWDiqz8IqFCdHFfdkp82Fa/V3Py5KKxXQCnlALt7l2r1RyJqFXTsR/dva4MprsV /jPQrELdODa+Qrf3gBE/lRAGCy8N/F1Ir5NLMcmMnEFRljlVH6QlP/ZReJXHuOu9 xvV8c+O2KL1tqXYMAV/m90pS9aNoe1fNIeOVL96htq8hSwQc7YCjt8wgQ/3AEYbe jfkvyyA2icZoAKcxQO+rF20Q+Fuhte/YN+jBjQVKA43r/SK9aU1GctvmessQolJr MEsvNJXxv8FwqTcmprJOW2CQhss2yxsJY/ZjsFgwkBvHnLWflh0dbOX/uNrYgusA KIFlDoAzci7YgiPaSwkkKoAI8yOkIC+qRb5Ysncr4Xs4dIfELNJO200fVAIrOS2w Xjz4kcw9VW+iAAra0AD5 =qiFA -----END PGP SIGNATURE----- --MgQdU7jr+b9ajvaw-- From owner-freebsd-doc@FreeBSD.ORG Tue Feb 18 22:02:14 2014 Return-Path: Delivered-To: www@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F94BFE7 for ; Tue, 18 Feb 2014 22:02:14 +0000 (UTC) Received: from mail-pb0-x242.google.com (mail-pb0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3E911A34 for ; Tue, 18 Feb 2014 22:02:13 +0000 (UTC) Received: by mail-pb0-f66.google.com with SMTP id md12so8461375pbc.9 for ; Tue, 18 Feb 2014 14:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:subject:date:mime-version:content-type :thread-index; bh=07v4cOvHuZIK0iRYaOF/2Y9f+qvAzLWq1gb7Q3V/Owk=; b=aOOVw2/jcJdAOgeeTWX1h8S/jYiZ06n3df7Up3DmIfZYkOofKyqkbC8Brh0hRPEkMq 3rUTz9cJHSzR5RV2YOJtmseVDaBUjVIeHCx6w+bvu5mN3Lp6PEWeGcCQZMZuxI3FllQM bqmWaWci2RZZlmlC330c79Uf3XKhh10dK0zQ7e3D8w1dtpIGc8NhWFlg/cUekvLqMudh 1pFEZybpgD8VpY72UwHUaV4/o64wLzClZYtaNaQBtEjAYug3whQhAtLToI5pUTcYSq9B 9kHFkKB6O2t5D4MzeqvqxNr6X47QTLgzCfj/7fpXkogRBDj4o2ELNGzW8Z+n4XP6jcwJ Tztg== X-Received: by 10.68.2.99 with SMTP id 3mr35721562pbt.49.1392760933477; Tue, 18 Feb 2014 14:02:13 -0800 (PST) Received: from TBSPC ([122.177.160.134]) by mx.google.com with ESMTPSA id lh13sm150697872pab.4.2014.02.18.14.02.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Feb 2014 14:02:09 -0800 (PST) Message-ID: <5303d861.2d79420a.1f87.19ea@mx.google.com> From: "Poorvi Goel" To: Subject: Content Writing Date: Wed, 19 Feb 2014 03:24:48 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac8s9ABB3Zl8vrenSCuYr5ErTHSs5Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17514 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: contact.linckmishra@gmail.com List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:02:14 -0000 Hi, Hope you are well. I am Poorvi Goel, Business Development Manager. We are an Online Marketing firm with over 3 years experience in the domain. I was on your site and can see you are an online service provider. Content in any Online Marketing Campaign is one of the most crucial factors to make the campaign a success. However, in most cases the content is not good either in terms of user perspective or in terms of search engines. Allow me to offer you our Web Copywriting Services. We work hard to deliver a hassle free and time bound copywriting service to our clients so that they don't have to wait forever for a content piece. Do let me know if your views are in line with mine and you are facing such a situation with your current service provider. I look forward to your response. Kind Regards, Poorvi Goel Business Development Manager Delhi From owner-freebsd-doc@FreeBSD.ORG Wed Feb 19 02:30:34 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF45D936; Wed, 19 Feb 2014 02:30:34 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61E48181A; Wed, 19 Feb 2014 02:30:34 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1J2UR66053691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Feb 2014 19:30:28 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1J2UREL053688; Tue, 18 Feb 2014 19:30:27 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 18 Feb 2014 19:30:27 -0700 (MST) From: Warren Block To: Benedict Reuschling Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) In-Reply-To: <5303241B.8080906@FreeBSD.org> Message-ID: References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> <5303241B.8080906@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 18 Feb 2014 19:30:28 -0700 (MST) Cc: "freebsd-doc@freebsd.org" , d@delphij.net, Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 02:30:34 -0000 On Tue, 18 Feb 2014, Benedict Reuschling wrote: > Another tool is textproc/po4a that Thomas Abthorpe showed me on one of > the hacker lounges two years ago in Canada. He set up a test project > for a translation into en_GB to see how these tools fit our toolchain. > > He send me the following mini-howto, which I extended a bit for a > first commit to the german doc repo recently: > > > install textproc/po4a > install editors/poedit # optional > install devel/gtranslator #optional > install lokalize # somewhere in kde4, too lazy to look > > To prep a new translation, inline, same directory the following works. > Substitute en_GB for the language of your choice. > > po4a-gettextize -f xml -m article.sgml -p article.pot # renders to pot > file I can use poedit to do the translation, but I always get article.pot:7: header field 'Project-Id-Version' still has the initial default value It does appear to save the translations to article.pot, this is something to do with catalogs. Manually editing article.pot and setting "Language: \n" to "Language: en_GB\n" then complains about the "Project-Id-Version" line having a default value. > I put everything in the DevSummit wiki page and will start a separate > one with the results from the summit to continue from there: > > https://wiki.freebsd.org/201405DevSummit/Translation The instructions don't seem to be there. On another page? From owner-freebsd-doc@FreeBSD.ORG Wed Feb 19 18:40:35 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EEEFDD8; Wed, 19 Feb 2014 18:40:35 +0000 (UTC) Received: from mxout2.bln1.prohost.de (mxout2.bln1.prohost.de [91.233.87.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90C5B1606; Wed, 19 Feb 2014 18:40:34 +0000 (UTC) Received: from Voyager.local (p4FC73A16.dip0.t-ipconnect.de [79.199.58.22]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.4/8.14.4) with ESMTP id s1JIeGpj003209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Feb 2014 19:40:17 +0100 Message-ID: <5304FA92.7070308@FreeBSD.org> Date: Wed, 19 Feb 2014 19:40:18 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Warren Block Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <5302E05F.1050200@delphij.net> <5303241B.8080906@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Null-Tag: 889961cb496f0430d24866fc65d32121 Cc: "freebsd-doc@freebsd.org" , d@delphij.net, Warren Block X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:40:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 19.02.14 03:30, schrieb Warren Block: > On Tue, 18 Feb 2014, Benedict Reuschling wrote: > >> Another tool is textproc/po4a that Thomas Abthorpe showed me on >> one of the hacker lounges two years ago in Canada. He set up a >> test project for a translation into en_GB to see how these tools >> fit our toolchain. >> >> He send me the following mini-howto, which I extended a bit for >> a first commit to the german doc repo recently: >> >> install textproc/po4a install editors/poedit # >> optional install devel/gtranslator #optional install lokalize # >> somewhere in kde4, too lazy to look >> >> To prep a new translation, inline, same directory the following >> works. Substitute en_GB for the language of your choice. >> >> po4a-gettextize -f xml -m article.sgml -p article.pot # renders >> to pot file > > I can use poedit to do the translation, but I always get > article.pot:7: header field 'Project-Id-Version' still has the > initial default value > I have this in my pot file header: "Project-Id-Version: 1\n" "Language: de\n" I guess we need to fill these automatically when a new or an updated translation is created. Maybe we could fill in some values from SVN (revision comes to mind) or use some kind of auto-incrementing counter for each new translated document. These are the things we need to figure out. Another question is: do we keep those po files holding the translated strings in our doc repo alongside the translation? Or do only the translation projects keep them for themselves? > It does appear to save the translations to article.pot, this is > something to do with catalogs. Manually editing article.pot and > setting "Language: \n" to "Language: en_GB\n" then complains about > the "Project-Id-Version" line having a default value. > >> I put everything in the DevSummit wiki page and will start a >> separate one with the results from the summit to continue from >> there: >> >> https://wiki.freebsd.org/201405DevSummit/Translation > > The instructions don't seem to be there. On another page? Well, I thought about putting them there, but decided against it as I want the discussion to be open rather than present a solution beforehand. Maybe someone else knows a better tool. I will demonstrate it, but will also show the current drawbacks and what I see with my translator hat on. The process in the mini-howto will get you started for sure, but it is very open for improvement. Cheers Benedict -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTBPqSAAoJEAQa31nbPD2LjGQIALfGCjQy5elI6L7hFxlRVkop c3OfKQLh8RuemK52ShxrdAv5m4BQng1PPIh28IFWBnEWgTKxUmg0pcMXwtvfvnUG zbLLmz9CZ2IUmyGJ19CRkqN9ImJZgdbnrxfKuCtRP6Qn83xIPYBTIRqI7c8thDvq Z6hlYVOnJ4hop+4FSLh6AqMnMTC/P38W1ekZb63RD/qA9YyF9lmO3wP5CNmey0Gk OWTa7XfY4eFpnokq/KCi6ysH9vYwmrvHirF/9IW6XT9XYjWxTJVN9Gnn07rBJZx3 O2qv6yucUitXOqhaFsZIci6cDt4MNcZzpyMjzqJW0u+pHutbs20zQKvueciBGGk= =FKUq -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 01:50:01 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED6FE7B for ; Thu, 20 Feb 2014 01:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB36F1B3D for ; Thu, 20 Feb 2014 01:50:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1K1o0CK003274 for ; Thu, 20 Feb 2014 01:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1K1o0iE003273; Thu, 20 Feb 2014 01:50:00 GMT (envelope-from gnats) Resent-Date: Thu, 20 Feb 2014 01:50:00 GMT Resent-Message-Id: <201402200150.s1K1o0iE003273@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, nemysis Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDD83B83 for ; Thu, 20 Feb 2014 01:46:23 +0000 (UTC) Received: from newred.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B588C1B1D for ; Thu, 20 Feb 2014 01:46:23 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s1K1kNQf036814 for ; Thu, 20 Feb 2014 01:46:23 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.7/8.14.7/Submit) id s1K1kNvj036813; Thu, 20 Feb 2014 01:46:23 GMT (envelope-from nobody) Message-Id: <201402200146.s1K1kNvj036813@cgiserv.freebsd.org> Date: Thu, 20 Feb 2014 01:46:23 GMT From: nemysis To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: docs/186905: [PATCH] porters-handbook/makefiles/chapter.xml Stripping Binaries and Shared Libraries X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:50:01 -0000 >Number: 186905 >Category: docs >Synopsis: [PATCH] porters-handbook/makefiles/chapter.xml Stripping Binaries and Shared Libraries >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Feb 20 01:50:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: nemysis >Release: FreeBSD 10.0-RELEASE-p4 >Organization: >Environment: FreeBSD 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jan 14 20:48:07 UTC 2014 >Description: Porter's Handbook 5.15.2. Stripping Binaries and Shared Libraries Add example for lighter stripping >How-To-Repeat: >Fix: Please commit enclosed porters-handbook_makefiles_chapter.xml.diff Patch attached with submission follows: Index: en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml =================================================================== --- en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml (revision 43995) +++ en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml (working copy) @@ -4138,6 +4138,14 @@ post-install target. For example: + First try to use USES macros + + + MAKE_ENV= INSTALL_STRIP_FLAG=${STRIP} + + When this doesn't work, use in + post-install target. + post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 07:07:31 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C1B3C4D for ; Thu, 20 Feb 2014 07:07:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 20D921A6B for ; Thu, 20 Feb 2014 07:07:29 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 022945DC21 for ; Thu, 20 Feb 2014 07:07:20 +0000 (UTC) Message-ID: <5305A9A4.1010603@allanjude.com> Date: Thu, 20 Feb 2014 02:07:16 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Subject: ZFS handbook project patch X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jXBqfIoI7A7s1SsEHTcJEC2its8v0F2Mg" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jXBqfIoI7A7s1SsEHTcJEC2its8v0F2Mg Content-Type: multipart/mixed; boundary="------------090505060909090403030007" This is a multi-part message in MIME format. --------------090505060909090403030007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached is another patch to the project branch for the ZFS section of the handbook adds the missing documentation on the 'zpool status', 'zpool scrub' and 'zpool clear' commands, and fills in the compression section (both the zfs set compression part, and the beefed up section of the terminology page). It also adds a 'zpool status' example to the 'zpool upgrade' section, so users know what a pool that needs to be upgraded will look like, and adds a reminder to make sure they update the bootcode (one of the popular problems people seem to run into, despite the fact the 'zpool upgrade' reminds you. It also fixes a paragraph that someone else wrote, that Warren had pointed out made no sense. Also adds some missing tags, and replace all of the tags that are actually commands with Feedback welcome --=20 Allan Jude --------------090505060909090403030007 Content-Type: text/plain; charset=windows-1252; name="zfs.compression.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs.compression.diff" Index: zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml (revi= sion 44001) +++ zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml (work= ing copy) @@ -134,7 +134,7 @@ =20 Then start the service: =20 - &prompt.root; service zfs start + &prompt.root; service zfs start =20 The examples in this section assume three SCSI disks with the device names @@ -152,12 +152,12 @@ pool using a single disk device, use zpool: =20 - &prompt.root; zpool create example= /dev/da0 + &prompt.root; zpool create example /dev/da0 =20 To view the new pool, review the output of df: =20 - &prompt.root; df + &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235230 1628718 13% / devfs 1 1 0 100% /dev @@ -169,10 +169,10 @@ accessible as a file system. Files may be created on it and users can browse it, as seen in the following example: =20 - &prompt.root; cd /example -&prompt.root; ls -&prompt.root; touch testfile -&prompt.root; ls -al + &prompt.root; cd /example +&prompt.root; ls +&prompt.root; touch testfile +&prompt.root; ls -al total 4 drwxr-xr-x 2 root wheel 3 Aug 29 23:15 . drwxr-xr-x 21 root wheel 512 Aug 29 23:12 .. @@ -182,8 +182,8 @@ ZFS features. To create a dataset on this pool with compression enabled: =20 - &prompt.root; zfs create example/compressed -&prompt.root; zfs set compression=3Dgzip example/compressed + &prompt.root; zfs create example/compressed +&prompt.root; zfs set compression=3Dgzip example/compressed =20 The example/compressed dataset is now a ZFS compressed file system. Try copying @@ -192,14 +192,14 @@ =20 Compression can be disabled with: =20 - &prompt.root; zfs set compression=3Doff example= /compressed + &prompt.root; zfs set compression=3Doff example/c= ompressed =20 To unmount a file system, use zfs umount and then verify by using df: =20 - &prompt.root; zfs umount example/compressed -&prompt.root; df + &prompt.root; zfs umount example/compressed +&prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235232 1628716 13% / devfs 1 1 0 100% /dev @@ -210,8 +210,8 @@ use zfs mount and verify with df: =20 - &prompt.root; zfs mount example/compressed -&prompt.root; df + &prompt.root; zfs mount example/compressed +&prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev @@ -222,7 +222,7 @@ The pool and file system may also be observed by viewing the output from mount: =20 - &prompt.root; mount + &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) @@ -237,13 +237,13 @@ is created. Important files will be stored here, the file system is set to keep two copies of each data block: =20 - &prompt.root; zfs create example/data -&prompt.root; zfs set copies=3D2 example/data + &prompt.root; zfs create example/data +&prompt.root; zfs set copies=3D2 example/data =20 It is now possible to see the data and space utilization by issuing df: =20 - &prompt.root; df + &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev @@ -264,9 +264,9 @@ To destroy the file systems and then destroy the pool as they are no longer needed: =20 - &prompt.root; zfs destroy example/compressed -&prompt.root; zfs destroy example/data -&prompt.root; zpool destroy example + &prompt.root; zfs destroy example/compressed +&prompt.root; zfs destroy example/data +&prompt.root; zpool destroy example =20 @@ -283,7 +283,7 @@ command, specifying the disks to add to the pool: =20 - &prompt.root; zpool create storage raidz da0 da= 1 da2 + &prompt.root; zpool create storage raidz da0 da1 = da2 =20 &sun; recommends that the number of devices used in a @@ -301,22 +301,22 @@ command makes a new file system in the pool called home: =20 - &prompt.root; zfs create storage/home + &prompt.root; zfs create storage/home =20 Now compression and keeping extra copies of directories and files can be enabled with these commands: =20 - &prompt.root; zfs set copies=3D2 storage/home -&prompt.root; zfs set compression=3Dgzip storage/home + &prompt.root; zfs set copies=3D2 storage/home +&prompt.root; zfs set compression=3Dgzip storage/home= =20 To make this the new home directory for users, copy the user data to this directory, and create the appropriate symbolic links: =20 - &prompt.root; cp -rp /home/* /storage/home -&prompt.root; rm -rf /home /usr/home -&prompt.root; ln -s /storage/home /home -&prompt.root; ln -s /storage/home /usr/home + &prompt.root; cp -rp /home/* /storage/home +&prompt.root; rm -rf /home /usr/home +&prompt.root; ln -s /storage/home /home +&prompt.root; ln -s /storage/home /usr/home =20 Users now have their data stored on the freshly created /storage/home. @@ -325,7 +325,7 @@ Try creating a snapshot which can be rolled back later: =20 - &prompt.root; zfs snapshot storage/home@08-30-0= 8 + &prompt.root; zfs snapshot storage/home@08-30-08<= /command> =20 Note that the snapshot option will only capture a real file system, not a home directory or a file. The @@ -333,7 +333,7 @@ file system name or the volume name. When a user's home directory is accidentally deleted, restore it with: =20 - &prompt.root; zfs rollback storage/home@08-30-0= 8 + &prompt.root; zfs rollback storage/home@08-30-08<= /command> =20 To list all available snapshots, run ls in the file system's @@ -341,7 +341,7 @@ directory. For example, to see the previously taken snapshot: =20 - &prompt.root; ls /storage/home/.zfs/snapshot + &prompt.root; ls /storage/home/.zfs/snapshot =20 It is possible to write a script to perform regular snapshots on user data. However, over time, snapshots can @@ -348,7 +348,7 @@ consume a great deal of disk space. The previous snapshot can be removed using the following command: =20 - &prompt.root; zfs destroy storage/home@08-30-08= + &prompt.root; zfs destroy storage/home@08-30-08 =20 After testing, /storage/home can be @@ -355,19 +355,19 @@ made the real /home using this command: =20 - &prompt.root; zfs set mountpoint=3D/home storag= e/home + &prompt.root; zfs set mountpoint=3D/home storage/= home =20 Run df and mount to confirm that the system now treats the file system as the real /home: =20 - &prompt.root; mount + &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) storage on /storage (zfs, local) storage/home on /home (zfs, local) -&prompt.root; df +&prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235240 1628708 13% / devfs 1 1 0 100% /dev @@ -380,7 +380,7 @@ created can be generated as part of the nightly &man.periodic.8; runs: =20 - &prompt.root; echo 'daily_status_zfs_enable=3D"= YES"' >> /etc/periodic.conf + &prompt.root; echo 'daily_status_zfs_enable=3D"YE= S"' >> /etc/periodic.conf =20 @@ -391,7 +391,7 @@ RAID-Z devices may be viewed with this command: =20 - &prompt.root; zpool status -x + &prompt.root; zpool status -x =20 If all pools are Online and everything @@ -425,19 +425,19 @@ This indicates that the device was previously taken offline by the administrator with this command: =20 - &prompt.root; zpool offline storage da1 + &prompt.root; zpool offline storage da1= =20 Now the system can be powered down to replace da1. When the system is back online, the failed disk can replaced in the pool: =20 - &prompt.root; zpool replace storage da1 + &prompt.root; zpool replace storage da1= =20 From here, the status may be checked again, this time without so that all pools are shown: =20 - &prompt.root; zpool status storage + &prompt.root; zpool status storage pool: storage state: ONLINE scrub: resilver completed with 0 errors on Sat Aug 30 19:44:11 2008 @@ -463,7 +463,7 @@ upon creation of file systems and may be disabled using the following command: =20 - &prompt.root; zfs set checksum=3Doff storage/ho= me + &prompt.root; zfs set checksum=3Doff storage/home= =20 Doing so is not recommended! @@ -478,16 +478,16 @@ scrubbing. Verify the data integrity of the storage pool, with this command: =20 - &prompt.root; zpool scrub storage + &prompt.root; zpool scrub storage =20 The duration of a scrub depends on the amount of data stored. Large amounts of data can take a considerable amount of time to verify. It is also very I/O - intensive, so much so that only one scrub> may be run at any + intensive, so much so that only one scrub may be run at any given time. After the scrub has completed, the status is updated and may be viewed with a status request: =20 - &prompt.root; zpool status storage + &prompt.root; zpool status storage pool: storage state: ONLINE scrub: scrub completed with 0 errors on Sat Jan 26 19:57:37 2013 @@ -502,9 +502,10 @@ =20 errors: No known data errors =20 - The completion time is displayed and helps to ensure data - integrity over a long period of time. - + The completion date of the last scrub operation is + displayed to help track when another scrub is required. + Routine pool scrubs help protect data from silent corruption + and ensure the integrity of the pool. =20 Refer to &man.zfs.8; and &man.zpool.8; for other ZFS options. @@ -581,6 +582,53 @@ redundancy. =20 + + Checking the Status of a Pool + + It is important to monitor the status of the + ZFS pool. If a drive goes offline, a + read or write error is detected, or a checksum fails to match, + the corresponding counters in the + display will be incremented. The + output shows the configuration and status of each device in + the pool, in addition to the status of the pool as the whole. + Also displayed are any actions that may need to be taken, and + details about when the last + + operation was completed. + + &prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub repaired 0 in 2h25m with 0 errors on Sat Sep 14 04:25:50 2= 013 +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + + + Clearing Errors + + If an error is detected with a device in a pool, the + corresponding read, write, or checksum counter will be + incremented. Once the issue is resolved, or to track the + rate of errors, zpool clear mypool will + reset the counters. This step can be important for automated + scripts that monitor the health of the pool and alert the + administrator when there is an error, further errors may not + be reported if the old errors are not cleared. + + Replacing a Functioning Device =20 @@ -622,8 +670,40 @@ restored from backups. =20 + + Scrubbing a Pool + + It is strongly recommended that a + Scrub operation be + performed regularly. Ideally atleast once each quarter. The + operating is very I/O intensive and + will reduce performance while it is in progress, so it much + be scheduled to avoid high demand periods. + + &prompt.root; zpool scrub mypool +&prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub in progress since Wed Feb 19 20:52:54 2014 + 116G scanned out of 8.60T at 649M/s, 3h48m to go + 0 repaired, 1.32% done +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + - ZFS Self-Healing + <acronym>ZFS</acronym> Self-Healing =20 ZFS utilizes the checkums stored with each data block to provide a feature called self-healing. @@ -651,8 +731,8 @@ two disks /dev/ada0 and /dev/ada1 is created. =20 - &prompt.root; zpool create healer<= /replaceable> mirror /dev/ada0 /d= ev/ada1 -&prompt.root; zpool status healer<= /userinput> + &prompt.root; zpool create healer mirror /dev/ada0 /dev= /ada1 +&prompt.root; zpool status healer pool: healer state: ONLINE scan: none requested @@ -665,7 +745,7 @@ ada1 ONLINE 0 0 0 =20 errors: No known data errors -&prompt.root; zpool list +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT healer 960M 92.5K 960M 0% 1.00x ONLINE - =20 @@ -674,12 +754,12 @@ A checksum of the pool is then created to compare it against the pool later on. =20 - &prompt.root; cp /some/important/data /healer -&prompt.root; zfs list + &prompt.root; cp /some/important/data /healer +&prompt.root; zfs list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT healer 960M 67.7M 892M 7% 1.00x ONLINE - -&prompt.root; sha1 /healer > checksum.txt -&prompt.root; cat checksum.txt +&prompt.root; sha1 /healer > checksum.txt +&prompt.root; cat checksum.txt SHA1 (/healer) =3D 2753eff56d77d9a536ece6694bf0a82740344d1f =20 Next, data corruption is simulated by writing random data @@ -700,12 +780,12 @@ of the pool are created before running the command! =20 - &prompt.root; zpool export healer<= /replaceable> -&prompt.root; dd if=3D/dev/random of=3D/dev/ada1 bs=3D1m coun= t=3D200 + &prompt.root; zpool export healer +&prompt.root; dd if=3D/dev/random of=3D/dev/ada1 bs=3D1m count=3D= 200 200+0 records in 200+0 records out 209715200 bytes transferred in 62.992162 secs (3329227 bytes/sec) -&prompt.root; zpool import healer +&prompt.root; zpool import healer =20 The ZFS pool status shows that one device has experienced an error. It is important to know that @@ -717,7 +797,7 @@ easily as the CKSUM column contains a value greater than zero. =20 - &prompt.root; zpool status healer<= /replaceable> + &prompt.root; zpool status healer pool: healer state: ONLINE status: One or more devices has experienced an unrecoverable error. A= n @@ -742,8 +822,8 @@ with the original one should reveal whether the pool is consistent again. =20 - &prompt.root; sha1 /healer >> checksum.txt -&prompt.root; cat checksum.txt + &prompt.root; sha1 /healer >> checksum.txt +&prompt.root; cat checksum.txt SHA1 (/healer) =3D 2753eff56d77d9a536ece6694bf0a82740344d1f SHA1 (/healer) =3D 2753eff56d77d9a536ece6694bf0a82740344d1f =20 @@ -762,8 +842,8 @@ required to remove the falsely written data from ada1. =20 - &prompt.root; zpool scrub healer -&prompt.root; zpool status healer<= /userinput> + &prompt.root; zpool scrub healer +&prompt.root; zpool status healer pool: healer state: ONLINE status: One or more devices has experienced an unrecoverable error. An @@ -792,7 +872,7 @@ operation is complete, the pool status has changed to the following: =20 - &prompt.root; zpool status healer<= /replaceable> + &prompt.root; zpool status healer pool: healer state: ONLINE status: One or more devices has experienced an unrecoverable error. An @@ -817,8 +897,8 @@ from the pool status by running zpool clear. =20 - &prompt.root; zpool clear healer -&prompt.root; zpool status healer<= /userinput> + &prompt.root; zpool clear healer +&prompt.root; zpool status healer pool: healer state: ONLINE scan: scrub repaired 66.5M in 0h2m with 0 errors on Mon Dec 10 12:26:2= 5 2012 @@ -890,17 +970,38 @@ need to be imported on an older system before upgrading. The upgrade process is unreversible and cannot be undone. =20 + &prompt.root; zpool status + pool: mypool + state: ONLINE +status: The pool is formatted using a legacy on-disk format. The pool c= an + still be used, but some features are unavailable. +action: Upgrade the pool using 'zpool upgrade'. Once this is done, the + pool will no longer be accessible on software that does not supp= ort feat + flags. + scan: none requested +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + mirror-0 ONLINE 0 0 0 + ada0 ONLINE 0 0 0 + ada1 ONLINE 0 0 0 + +errors: No known data errors + The newer features of ZFS will not be available until zpool upgrade has completed. can be used to see what new features will be provided by upgrading, as well as which features are already supported by the existing version. - =20 - - Checking the Status of a Pool - - + + If the system boots from the zpool, the boot code must + also be updated to support the new zpool version. Run + gpart bootcode on the partition that + contains the boot code. See &man.gpart.8; for more + information. + =20 @@ -917,7 +1018,7 @@ review this history is aptly named zpool history: =20 - &prompt.root; zpool history + &prompt.root; zpool history History for 'tank': 2013-02-26.23:02:35 zpool create tank mirror /dev/ada0 /dev/ada1 2013-02-27.18:50:58 zfs set atime=3Doff tank @@ -939,7 +1040,7 @@ displays user initiated events as well as internally logged ZFS events. =20 - &prompt.root; zpool history -i + &prompt.root; zpool history -i History for 'tank': 2013-02-26.23:02:35 [internal pool create txg:5] pool spa 28; zfs spa 28= ; zpl 5;uts 9.1-RELEASE 901000 amd64 2013-02-27.18:50:53 [internal property set txg:50] atime=3D0 dataset =3D= 21 @@ -954,7 +1055,7 @@ including information like the name of the user who issued the command and the hostname on which the change was made. =20 - &prompt.root; zpool history -l + &prompt.root; zpool history -l History for 'tank': 2013-02-26.23:02:35 zpool create tank mirror /dev/ada0 /dev/ada1 [user 0= (root) on :global] 2013-02-27.18:50:58 zfs set atime=3Doff tank [user 0 (root) on myzfsbox:= global] @@ -992,7 +1093,7 @@ to limit monitoring to just that pool. A basic example: =20 - &prompt.root; zpool iostat + &prompt.root; zpool iostat capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- @@ -1019,7 +1120,7 @@ pool. This example shows a mirrored pool consisting of two devices: =20 - &prompt.root; zpool iostat -v + &prompt.root; zpool iostat -v capacity operations bandwidth pool alloc free read write read write ----------------------- ----- ----- ----- ----- ----- ----- @@ -1122,16 +1223,16 @@ compression property on a 250 MB volume allows creation of a compressed FAT filesystem. =20 - &prompt.root; zfs create -V 250m -o compression= =3Don tank/fat32 -&prompt.root; zfs list tank + &prompt.root; zfs create -V 250m -o compression=3D= on tank/fat32 +&prompt.root; zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 258M 670M 31K /tank -&prompt.root; newfs_msdos -F32 /dev/zvol/tank/fat32 -&prompt.root; mount -t msdosfs /dev/zvol/tank/fat32 /mnt -&prompt.root; df -h /mnt | grep fat32 +&prompt.root; newfs_msdos -F32 /dev/zvol/tank/fat32 +&prompt.root; mount -t msdosfs /dev/zvol/tank/fat32 /mnt +&prompt.root; df -h /mnt | grep fat32 Filesystem Size Used Avail Capacity Mounted on /dev/zvol/tank/fat32 249M 24k 249M 0% /mnt -&prompt.root; mount | grep fat32 +&prompt.root; mount | grep fat32 /dev/zvol/tank/fat32 on /mnt (msdosfs, local) =20 Destroying a volume is much the same as destroying a @@ -1182,8 +1283,8 @@ (:) is used to create a custom namespace for the property. =20 - &prompt.root; zfs set custom:costcenter=3D1234 tank -&prompt.root; zfs get custom:costcenter tank + &prompt.root; zfs set custom:costcenter=3D1234 tank +&prompt.root; zfs get custom:costcenter tank NAME PROPERTY VALUE SOURCE tank custom:costcenter 1234 local =20 @@ -1193,11 +1294,11 @@ datasets, it will be removed completely (although the changes are still recorded in the pool's history). =20 - &prompt.root; zfs inherit -r custo= m:costcenter tank -&prompt.root; zfs get custom:costcenter tank + &prompt.root; zfs inherit -r custom<= /replaceable>:costcenter tank +&prompt.root; zfs get custom:costcenter tank NAME PROPERTY VALUE SOURCE tank custom:costcenter - - -&prompt.root; zfs get all tank | g= rep custom:costcenter +&prompt.root; zfs get all tank | gre= p custom:costcenter= &prompt.root; =20 @@ -1255,7 +1356,7 @@ =20 - ZFS Replication + <acronym>ZFS</acronym> Replication =20 Keeping data on a single pool in one location exposes it to risks like theft, natural and human disasters. Keeping @@ -1265,12 +1366,13 @@ the data to standard output. Using this technique, it is possible to not only store the data on another pool connected to the local system, but also to send it over a network to - another system that runs ZFS. To achieve this replication, - ZFS uses filesystem snapshots (see the - section on ZFS snapshots) to send - them from one location to another. The commands for this - operation are zfs send and + another system that runs ZFS . To achieve + this replication, ZFS uses filesystem + snapshots (see the section on + ZFS + snapshots) to send them from one location to another. + The commands for this operation are + zfs send and zfs receive, respectively. =20 The following examples will demonstrate the functionality @@ -1357,7 +1459,7 @@ mypool 984M 43.7M 940M 4% 1.00x ONLINE - =20 - ZFS Incremental Backups + <acronym>ZFS</acronym> Incremental Backups =20 Another feature of zfs send is that it can determine the difference between two snapshots to @@ -1365,12 +1467,12 @@ saving disk space and time for the transfer to another pool. For example: =20 - &prompt.root; zfs snapshot mypool@backup2 -&prompt.root; zfs list -t snapshot + &prompt.root; zfs snapshot mypool@backup2 +&prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT mypool@backup1 5.72M - 43.6M - mypool@backup2 0 - 44.1M - -&prompt.root; zpool list +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 61.7M 898M 6% 1.00x ONLINE - mypool 960M 50.2M 910M 5% 1.00x ONLINE - @@ -1377,20 +1479,20 @@ =20 A second snapshot called backup2 was created. This second - snapshot contains only the changes on the ZFS filesystem - between now and the last snapshot, - backup1. Using the + snapshot contains only the changes on the + ZFS filesystem between now and the last + snapshot, backup1. Using the -i flag to zfs send and providing both snapshots, an incremental snapshot can be transferred, containing only the data that has changed. =20 - &prompt.root; zfs send -i mypool@backup1 mypool@backup2 > /backup/incremental= -&prompt.root; zpool list + &prompt.root; zfs send -i mypool@backup1 mypool@backup2 > /backup/incremental +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 80.8M 879M 8% 1.00x ONLINE - mypool 960M 50.2M 910M 5% 1.00x ONLINE - -&prompt.root; ls -lh /backup +&prompt.root; ls -lh /backup total 82247 drwxr-xr-x 1 root wheel 61M Dec 3 11:36 backup1 drwxr-xr-x 1 root wheel 18M Dec 3 11:36 incremental= @@ -1407,7 +1509,7 @@ =20 - Receiving ZFS Data Streams + Receiving <acronym>ZFS</acronym> Data Streams =20 Up until now, only the data streams in binary form were sent to other pools. To get to the actual data contained in @@ -1421,8 +1523,8 @@ pool to another. This way, the data can be used directly on the receiving pool after the transfer is complete. =20 - &prompt.root; zfs send mypool@backup1 | zfs receive backup= /backup1 -&prompt.root; ls -lh /backup + &prompt.root; zfs send mypool@backup1 | zfs receive backup/b= ackup1 +&prompt.root; ls -lh /backup total 431 drwxr-xr-x 4219 root wheel 4.1k Dec 3 11:34 backup1= =20 @@ -1429,11 +1531,11 @@ The directory backup1 does contain all the data, which were part of the snapshot of the same name. Since this originally was a complete filesystem - snapshot, the listing of all ZFS filesystems for this pool - is also updated and shows the + snapshot, the listing of all ZFS + filesystems for this pool is also updated and shows the backup1 entry. =20 - &prompt.root; zfs list + &prompt.root; zfs list NAME USED AVAIL REFER MOUNTPOINT backup 43.7M 884M 32K /backup backup/backup1 43.5M 884M 43.5M /backup/backup1 @@ -1465,16 +1567,16 @@ encryption of the data on the pool itself. To make sure the network connection between both systems is securely encrypted, SSH can be used. - Since ZFS only requires the stream to be redirected from - standard output, it is relatively easy to pipe it through - SSH. + Since ZFS only requires the stream to be + redirected from standard output, it is relatively easy to + pipe it through SSH. =20 A few settings and security precautions have to be made - before this can be done. Since this chapter is about ZFS - and not about configuring SSH, it only lists the things - required to perform the encrypted zfs - send operation. The following settings should - be made: + before this can be done. Since this chapter is about + ZFS and not about configuring SSH, it + only lists the things required to perform the encrypted + zfs send operation. The following + settings should be made: =20 @@ -1500,8 +1602,8 @@ the receiving system, the encrypted stream can be sent using the following commands: =20 - &prompt.root; zfs snapshot -r mypool/ho= me@monday -&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool<= /screen> + &prompt.root; zfs snapshot -r mypool/home= @monday +&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool =20 The first command creates a recursive snapshot (option -r) called @@ -1549,13 +1651,13 @@ storage/home/bob, use the following: =20 - &prompt.root; zfs set quota=3D10G storage/home/= bob + &prompt.root; zfs set quota=3D10G storage/home/bo= b =20 To enforce a reference quota of 10 GB for storage/home/bob, use the following: =20 - &prompt.root; zfs set refquota=3D10G storage/ho= me/bob + &prompt.root; zfs set refquota=3D10G storage/home= /bob =20 The general format is userquota@user=3Dsize<= /replaceable>, @@ -1589,11 +1691,11 @@ For example, to enforce a user quota of 50 GB for the user named joe: =20 - &prompt.root; zfs set userquota@joe=3D50G + &prompt.root; zfs set userquota@joe=3D50G =20 To remove any quota: =20 - &prompt.root; zfs set userquota@joe=3Dnone + &prompt.root; zfs set userquota@joe=3Dnone =20 User quota properties are not displayed by @@ -1611,13 +1713,13 @@ firstgroup to 50 GB, use: =20 - &prompt.root; zfs set groupquota@firstgroup=3D5= 0G + &prompt.root; zfs set groupquota@firstgroup=3D50G= =20 To remove the quota for the group firstgroup, or to make sure that one is not set, instead use: =20 - &prompt.root; zfs set groupquota@firstgroup=3Dn= one + &prompt.root; zfs set groupquota@firstgroup=3Dnon= e =20 As with the user quota property, non-root users can @@ -1638,7 +1740,7 @@ root can list the quota for storage/home/bob using: =20 - &prompt.root; zfs get quota storage/home/bob + &prompt.root; zfs get quota storage/home/bob =20 @@ -1657,11 +1759,11 @@ so to set a reservation of 10 GB on storage/home/bob, use: =20 - &prompt.root; zfs set reservation=3D10G storage= /home/bob + &prompt.root; zfs set reservation=3D10G storage/h= ome/bob =20 To clear any reservation: =20 - &prompt.root; zfs set reservation=3Dnone storag= e/home/bob + &prompt.root; zfs set reservation=3Dnone storage/= home/bob =20 The same principle can be applied to the refreservation property for setting a @@ -1672,16 +1774,10 @@ This command shows any reservations or refreservations that exist on storage/home/bob: =20 - &prompt.root; zfs get reservation storage/home/= bob -&prompt.root; zfs get refreservation storage/home/bob + &prompt.root; zfs get reservation storage/home/bo= b +&prompt.root; zfs get refreservation storage/home/bob= =20 - - Compression - - - - Deduplication =20 @@ -1700,7 +1796,7 @@ To activate deduplication, set the dedup property on the target pool: =20 - &prompt.root; zfs set dedup=3Don p= ool + &prompt.root; zfs set dedup=3Don poo= l =20 Only new data being written to the pool will be deduplicated. Data that has already been written to the pool @@ -1708,7 +1804,7 @@ such, a pool with a freshly activated deduplication property will look something like this example: =20 - &prompt.root; zpool list + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 2.84G 2.19M 2.83G 0% 1.00x ONLINE - =20 @@ -1719,7 +1815,7 @@ copied three times into different directories on the deduplicated pool created above. =20 - &prompt.root; zpool list + &prompt.root; zpool list for d in dir1 dir2 dir3; do for> mkdir $d && cp -R /usr/ports $d & for> done @@ -1726,7 +1822,7 @@ =20 Redundant data is detected and deduplicated: =20 - &prompt.root; zpool list + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 2.84G 20.9M 2.82G 0% 3.00x ONLINE - =20 @@ -1742,7 +1838,7 @@ ZFS can show potential space savings by simulating deduplication on an existing pool: =20 - &prompt.root; zdb -S pool + &prompt.root; zdb -S pool Simulated DDT histogram: =20 bucket allocated referenced @@ -1778,8 +1874,80 @@ due to the much lower memory requirements. =20 + + Compression + + ZFS provides transparent compression. + Compressing data at the block level as it is written not only + saves storage space, but can also result in higher disk + throughput than would otherwise be possible. If data is + compressed by 25%, then the compressed data can be written to + the disk at the same rate as the uncompressed version, + resulting in an effective write speed of 125% of what would + normally be possible. Compression can also be a great + alternative to + Deduplication + because it does not require additional memory to store a + DDT. + + ZFS offers a number of different + compression algorithms to choose from, each with different + trade-offs. With the introduction of LZ4 + compression in ZFS v5000, it is possible + to enable compression for the entire pool without the large + performance trade-off of other algorithms. The biggest + advantage to LZ4 is the + early abort feature. If + LZ4 does not achieve atleast 12.5% + compression in the first part of the data, the block is + written uncompressed to avoid wasting CPU cycles trying to + compress data that is either already compressed or + uncompressible. For details about the different compression + algorithms available in ZFS, see the + Compression entry + in the terminology section. + + The administrator can monitor the effectiveness of + ZFS compression using a number of dataset + properties. + + &prompt.root; zfs get used,compressratio,compress= ion,logicalused mypool/compressed_dataset +NAME PROPERTY VALUE SOURCE +mypool/compressed_dataset used 449G - +mypool/compressed_dataset compressratio 1.11x - +mypool/compressed_dataset compression lz4 local +mypool/compressed_dataset logicalused 496G - + + The dataset is currently using 449 GB of storage + space (the used property). If this dataset was not compressed + it would have taken 496 GB of space (the logicallyused + property). This results in the 1.11:1 compression + ratio. + + Compression can have an unexpected side effect when + combined with + User Quotas. + ZFS user quotas restrict how much space + a user can consume on a dataset, however the measurements are + based on how much data is stored, after compression. So if a + user has a quota of 10 GB, and writes 10 GB of + compressible data, they will still be able to store additional + data. If they later update a file, say a database, with more + or less compressible data, the amount of space available to + them will change. This can result in the odd situation where + a user did not increase the actual amount of data (the + logicalused property), but the change in + compression means they have now reached their quota. + + Compression can have a similar unexpected interaction with + backups. Quotas are often used to limit how much data can be + stored to ensure there is sufficient backup space available. + However since quotas do not consider compression, more data + may be written than will fit in uncompressed backups. + + - ZFS and Jails + <acronym>ZFS</acronym> and Jails =20 zfs jail and the corresponding jailed property are used to delegate a @@ -1843,22 +2011,22 @@ =20 - ZFS Advanced Topics + <acronym>ZFS</acronym> Advanced Topics =20 - ZFS Tuning + <acronym>ZFS</acronym> Tuning =20 =20 - Booting Root on ZFS + Booting Root on <acronym>ZFS</acronym> =20 =20 - ZFS Boot Environments + <acronym>ZFS</acronym> Boot Environments =20 @@ -1870,7 +2038,7 @@ =20 - ZFS on i386 + <acronym>ZFS</acronym> on i386 =20 Some of the features provided by ZFS are memory intensive, and may require tuning for maximum @@ -1942,38 +2110,46 @@ FreeBSD - Wiki - ZFS + Wiki - ZFS =20 FreeBSD - Wiki - ZFS Tuning + Wiki - ZFS Tuning =20 Illumos - Wiki - ZFS + Wiki - ZFS =20 Oracle - Solaris ZFS Administration Guide + Solaris ZFS Administration + Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Ev= il_Tuning_Guide">ZFS Evil Tuning Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Be= st_Practices_Guide">ZFS Best Practices Guide + + + Cal= omel + Blog - ZFS Raidz Performance, Capacity + and Integrity + =20 @@ -2449,10 +2625,68 @@ and write throughput, as only the smaller compressed version of the file needs to be read or written. =20 - - LZ4 compression is only - available after &os; 9.2. - + + + LZ4 - + was added in ZFS pool version + 5000 (feature flags), and is now the recommended + compression algorithm. LZ4 + compresses approximately 50% faster than + LZJB when operating on + compressible data, and is over three times faster + when operating on uncompressible data. + LZ4 also decompresses + approximately 80% faster than + LZJB. On modern CPUs, + LZ4 can often compress at over + 500 MB/s, and decompress at over + 1.5 GB/s (per single CPU core). + + + LZ4 compression is + only available after &os; 9.2. + + + + + LZJB - + is the default compression algorithm in + ZFS. Created by Jeff Bonwick + (one of the original creators of + ZFS). LZJB + offers good compression with less + CPU overhead compared to + GZIP. In the future, the + default compression algorithm will likely change + to LZ4. + + + + GZIP - + is a popular stream compression algorithm and is + available in ZFS. One of the + main advantages of using GZIP + is its configurable level of compression. When + setting the compress property, + the administrator can choose which level of + compression to use, ranging from + gzip1, the lowest level of + compression, and gzip9, the + higher level of compression. This gives the + administrator control over how much + CPU time to trade for saved + disk space. + + + + ZLE - + (zero length encoding) is a special compression + algorithm that only compresses continuous runs of + zeros. This compression algorithm is only useful + if your dataset contains large areas where only + the zero byte is written. + + =20 @@ -2511,7 +2745,9 @@ at least once each quarter. Checksums of each block are tested as they are read in normal use, but a scrub operation makes sure even infrequently used blocks are - checked for silent corruption. + checked for silent corruption, improving the security of + your data, especially in archival storage + situations. =20 --------------090505060909090403030007-- --jXBqfIoI7A7s1SsEHTcJEC2its8v0F2Mg 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.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBamnAAoJEJrBFpNRJZKf13wQAKCxDZGBn6Qnz13NJiiAjtx5 dzKr0sOyED0/gmQ0yCVdXxNcSeLQ8jqJm3NrmApwzPM9TAtW2mim1cVx1YzKLu0q 2NYYdgHkiKoMqyyAxpna3XC3I07W1VrQcp7xsh9pCYW/qp09HeAg0+0f+zedkfA/ W4xUo+tuQfrF7v+uhQtnQ5xRULES0/0aQL1ctqse/KUxZzvVVSB0DhAoIWhO2O6J wsqxkLLEyF3MIFRb5Bi86FnqbM6TteibvrXBeEAvO9e6Yk5Q/hHPFRuEWCN+589g 2y2t6s7EqvdH2/DGGrohyEv0v4LCdX1XFSUAkrGVguuuwdv888rU4IpkkVt0HFOd kgvQXBgFcqX1E+shblS2qtiQ09jAwlT+sjd7fjGwmKO/uLdZZ/cJPLnE5O65DZuZ fgmNcWFcMdnim7vNU3UfZlRP+zHUW+7NjgAti2PYb7u8wEHS/Bd9efnwruFAF/zB zIckWF7t9DAg9T1gCeLokgb7ojRckbHanerU3VQg3b6tPDJrA9cjE7GG8wxZzRsE Bd5dnMw4ipC39A+qhSSNUVD5N5tK1gIg3BqLwf8V7CUv6rBlBwLTosVuvcrKqYN/ 67NZn6+c7dnSEgBgpDBAt4c+4r2mzeonInQcTV9l6PveWINSIRLEcDoV2CBy0Z7h SgG/Cyq51oY0ZsErGxCM =nls0 -----END PGP SIGNATURE----- --jXBqfIoI7A7s1SsEHTcJEC2its8v0F2Mg-- From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 07:34:44 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA557214 for ; Thu, 20 Feb 2014 07:34:44 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 588DF1CCF for ; Thu, 20 Feb 2014 07:34:44 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1K7YGCM002772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 16:34:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1K7YFK6018109; Thu, 20 Feb 2014 16:34:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 20 Feb 2014 16:20:55 +0900 (JST) Message-Id: <20140220.162055.109321178462259649.hrs@allbsd.org> To: freebsd@allanjude.com Subject: Re: ZFS handbook project patch From: Hiroki Sato In-Reply-To: <5305A9A4.1010603@allanjude.com> References: <5305A9A4.1010603@allanjude.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Feb_20_16_20_55_2014_799)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Thu, 20 Feb 2014 16:34:28 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-doc@FreeBSD.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:34:44 -0000 ----Security_Multipart(Thu_Feb_20_16_20_55_2014_799)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Allan Jude wrote in <5305A9A4.1010603@allanjude.com>: fr> It also fixes a paragraph that someone else wrote, that Warren had fr> pointed out made no sense. fr> fr> Also adds some missing tags, and replace all of the fr> tags that are actually commands with - &prompt.root; service zfs start + &prompt.root; service zfs start is correct here. is for the name of an executable program or command, not a command line. -- Hiroki ----Security_Multipart(Thu_Feb_20_16_20_55_2014_799)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMFrNcACgkQTyzT2CeTzy2vmgCePn3WSgYTRrTfKcUgrb40R4Lq WqwAnjG5jqOQmebAEZZWQhHFRmFgR8w+ =0bgT -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Feb_20_16_20_55_2014_799)---- From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 12:55:37 2014 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D73A4E4 for ; Thu, 20 Feb 2014 12:55:37 +0000 (UTC) Received: from nm39-vm8.bullet.mail.ir2.yahoo.com (nm39-vm8.bullet.mail.ir2.yahoo.com [212.82.97.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C94F91CC2 for ; Thu, 20 Feb 2014 12:55:36 +0000 (UTC) Received: from [212.82.98.60] by nm39.bullet.mail.ir2.yahoo.com with NNFMP; 20 Feb 2014 12:53:46 -0000 Received: from [46.228.39.91] by tm13.bullet.mail.ir2.yahoo.com with NNFMP; 20 Feb 2014 12:53:46 -0000 Received: from [127.0.0.1] by smtp128.mail.ir2.yahoo.com with NNFMP; 20 Feb 2014 12:53:46 -0000 X-Yahoo-Newman-Id: 568314.32653.bm@smtp128.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-5 X-YMail-OSG: DI8Q5x0VM1mIYTWrPBPOJG9Q22GejBFuq.6zDuH3TgZHV6l e.stBo2ofGeOENZoTVv5Qn1eVQGPvt1_yYIrrnkyMwIKyYf7hYcY3tiGeMky eTnxMj.jWprXzXIJULbNA0aRwcLppPDGjBOSa9Ty.kbCoYOWr0t0aNrrIEXz oF_UYS5htAd_sPHlGPYJHx7qQbCBSzVz3S6c1KVhyFZ2BJFV2UKmGQVykJrR iHVbe4VHYjsf20v4X8Vy9Ec7K4wyyY9nxOO0cmKFatesyzW6Kgh8XNIa0oa. .Rm0HM5aIANivVZYclDw3vkIctz8JjkRtdkbDAQg1lumNLfRA_LIGK04NbDW _60iRCtkHt9CekhMDzOp8VhRiGm6ZiyttQq3DOTtxFT7G6tQCuI9Ot7BNKmP HmWURiVU1WU9UCFMT5jCOoE8lLgf6QeOfj88ReRdRYrWF0MwSocI.SGKWVNW 9P7UJjCwVnD06tcxoBp3zdREMXKFAcMVwURnIfUCyBjAy2D9GNYA8DJZS_V8 FUGhkeHZGK7rUR9dj.i1XKcZtf6UoKQtGQzqTbmti.Ejh.VVdvO.pP6fFGoJ GpViUAAS507QDWDcdnppQO_6488hpcr0G X-Yahoo-SMTP: XbH8ZOiswBApAQREgYqXwoCt5XsgP_42E97VPsD9y6a1l9ZW4MXPhaBIO8mA X-Rocket-Received: from [192.168.0.102] (dienhart_jarred@178.122.249.168 with plain [188.125.69.59]) by smtp128.mail.ir2.yahoo.com with SMTP; 20 Feb 2014 12:53:46 +0000 UTC Message-Id: From: Sarah F To: doc@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Beverly Date: Thu, 20 Feb 2014 08:54:13 -0400 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 12:55:37 -0000 OzzyRebdowt, do you live near Beverly ? From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 13:05:59 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89AA8A4C; Thu, 20 Feb 2014 13:05:59 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56DC51D9F; Thu, 20 Feb 2014 13:05:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1KD5wd0032787; Thu, 20 Feb 2014 13:05:59 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1KD5qoW032786; Thu, 20 Feb 2014 14:05:52 +0100 (CET) (envelope-from brueffer) Date: Thu, 20 Feb 2014 14:05:52 +0100 (CET) Message-Id: <201402201305.s1KD5qoW032786@freefall.freebsd.org> To: Trond.Endrestol@ximalas.info, brueffer@FreeBSD.org, freebsd-doc@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: docs/184029: Description of /usr/tests is missing in hier(7) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:05:59 -0000 Synopsis: Description of /usr/tests is missing in hier(7) State-Changed-From-To: open->closed State-Changed-By: brueffer State-Changed-When: Thu Feb 20 14:05:10 CET 2014 State-Changed-Why: This was fixed in r257100 three months ago. Thanks for the report! http://www.freebsd.org/cgi/query-pr.cgi?pr=184029 From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 14:57:55 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFA8985D; Thu, 20 Feb 2014 14:57:55 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D1761A1B; Thu, 20 Feb 2014 14:57:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1KEvnvw069259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Feb 2014 07:57:50 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1KEvlqX069256; Thu, 20 Feb 2014 07:57:47 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 20 Feb 2014 07:57:47 -0700 (MST) From: Warren Block To: Hiroki Sato Subject: Re: ZFS handbook project patch In-Reply-To: <20140220.162055.109321178462259649.hrs@allbsd.org> Message-ID: References: <5305A9A4.1010603@allanjude.com> <20140220.162055.109321178462259649.hrs@allbsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 20 Feb 2014 07:57:50 -0700 (MST) Cc: freebsd-doc@FreeBSD.org, freebsd@allanjude.com X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:57:55 -0000 On Thu, 20 Feb 2014, Hiroki Sato wrote: > Allan Jude wrote > in <5305A9A4.1010603@allanjude.com>: > > fr> It also fixes a paragraph that someone else wrote, that Warren had > fr> pointed out made no sense. > fr> > fr> Also adds some missing tags, and replace all of the > fr> tags that are actually commands with > > - &prompt.root; service zfs start > + &prompt.root; service zfs start > > is correct here. is for the name of an > executable program or command, not a command line. Yes. Although is sometimes used for short inline commands that are a bit more than a simple command name: Files beginning with the letter "A" can be listed with ls A*. More detailed searches can be done with find: &prompt.user; find /usr/ports -name Makefile There are some examples in the FDP Primer: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#idp66516784 (Although they also show , which I don't recall seeing used anywhere else in our docs and am pretty sure I've never used myself.) From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 16:37:35 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFB9E78E for ; Thu, 20 Feb 2014 16:37:35 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7F73814CC for ; Thu, 20 Feb 2014 16:37:34 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 190EE5E470 for ; Thu, 20 Feb 2014 16:37:32 +0000 (UTC) Message-ID: <53062F44.1050906@allanjude.com> Date: Thu, 20 Feb 2014 11:37:24 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-doc@freebsd.org Subject: Re: ZFS handbook project patch References: <5305A9A4.1010603@allanjude.com> <20140220.162055.109321178462259649.hrs@allbsd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pIIQraK2r1kfXU3fjH1R16guxfJscdBKC" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:37:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pIIQraK2r1kfXU3fjH1R16guxfJscdBKC Content-Type: multipart/mixed; boundary="------------030306020802040407040001" This is a multi-part message in MIME format. --------------030306020802040407040001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-02-20 09:57, Warren Block wrote: > On Thu, 20 Feb 2014, Hiroki Sato wrote: >=20 >> Allan Jude wrote >> in <5305A9A4.1010603@allanjude.com>: >> >> fr> It also fixes a paragraph that someone else wrote, that Warren had= >> fr> pointed out made no sense. >> fr> >> fr> Also adds some missing tags, and replace all of the >> fr> tags that are actually commands with >> >> - &prompt.root; service zfs >> start >> + &prompt.root; service zfs start >> >> is correct here. is for the name of an >> executable program or command, not a command line. >=20 > Yes. Although is sometimes used for short inline commands > that are a bit more than a simple command name: >=20 > Files beginning with the letter "A" can be listed with > ls A*. More detailed searches can be done with > find: >=20 > &prompt.user; find /usr/ports -name > Makefile >=20 > There are some examples in the FDP Primer: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#i= dp66516784 >=20 >=20 > (Although they also show , which I don't recall seeing used > anywhere else in our docs and am pretty sure I've never used myself.) > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" would appear to be for an interactive program, and I figured that is what was for, when you type something into an interactive prompt. I've quickly switch those back to I used simple logic, if talking about a command in a paragraph, use , when doing it in a use , as in a paragraph it is usually never more than a subcommand like zfs send Also, I just noticed that a bunch of the stuff from my previous zfs patch didn't get in (I sent 2, a whitespace and a content patch, and only the whitespace one got in), so I've included the updated zfs send stuff as well (how to do replication without root) IIRC, this means the stuff I wrote for the CARP chapter last week is wrong with regards to instead of --=20 Allan Jude --------------030306020802040407040001 Content-Type: text/plain; charset=windows-1252; name="zfs.compression_status_scrub_send.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs.compression_status_scrub_send.diff" Index: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapt= er.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.= xml (revision 44001) +++ projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.= xml (working copy) @@ -483,7 +483,7 @@ The duration of a scrub depends on the amount of data stored. Large amounts of data can take a considerable amount of time to verify. It is also very I/O - intensive, so much so that only one scrub> may be run at any + intensive, so much so that only one scrub may be run at any given time. After the scrub has completed, the status is updated and may be viewed with a status request: =20 @@ -502,9 +502,10 @@ =20 errors: No known data errors =20 - The completion time is displayed and helps to ensure data - integrity over a long period of time. - + The completion date of the last scrub operation is + displayed to help track when another scrub is required. + Routine pool scrubs help protect data from silent corruption + and ensure the integrity of the pool. =20 Refer to &man.zfs.8; and &man.zpool.8; for other ZFS options. @@ -581,6 +582,53 @@ redundancy. =20 + + Checking the Status of a Pool + + It is important to monitor the status of the + ZFS pool. If a drive goes offline, a + read or write error is detected, or a checksum fails to match, + the corresponding counters in the + display will be incremented. The + output shows the configuration and status of each device in + the pool, in addition to the status of the pool as the whole. + Also displayed are any actions that may need to be taken, and + details about when the last + + operation was completed. + + &prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub repaired 0 in 2h25m with 0 errors on Sat Sep 14 04:25:50 2= 013 +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + + + Clearing Errors + + If an error is detected with a device in a pool, the + corresponding read, write, or checksum counter will be + incremented. Once the issue is resolved, or to track the + rate of errors, zpool clear mypool will + reset the counters. This step can be important for automated + scripts that monitor the health of the pool and alert the + administrator when there is an error, further errors may not + be reported if the old errors are not cleared. + + Replacing a Functioning Device =20 @@ -622,8 +670,40 @@ restored from backups. =20 + + Scrubbing a Pool + + It is strongly recommended that a + Scrub operation be + performed regularly. Ideally atleast once each quarter. The + operating is very I/O intensive and + will reduce performance while it is in progress, so it much + be scheduled to avoid high demand periods. + + &prompt.root; zpool scrub mypool +&prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub in progress since Wed Feb 19 20:52:54 2014 + 116G scanned out of 8.60T at 649M/s, 3h48m to go + 0 repaired, 1.32% done +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + - ZFS Self-Healing + <acronym>ZFS</acronym> Self-Healing =20 ZFS utilizes the checkums stored with each data block to provide a feature called self-healing. @@ -890,17 +970,38 @@ need to be imported on an older system before upgrading. The upgrade process is unreversible and cannot be undone. =20 + &prompt.root; zpool status + pool: mypool + state: ONLINE +status: The pool is formatted using a legacy on-disk format. The pool c= an + still be used, but some features are unavailable. +action: Upgrade the pool using 'zpool upgrade'. Once this is done, the + pool will no longer be accessible on software that does not supp= ort feat + flags. + scan: none requested +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + mirror-0 ONLINE 0 0 0 + ada0 ONLINE 0 0 0 + ada1 ONLINE 0 0 0 + +errors: No known data errors + The newer features of ZFS will not be available until zpool upgrade has completed. can be used to see what new features will be provided by upgrading, as well as which features are already supported by the existing version. - =20 - - Checking the Status of a Pool - - + + If the system boots from the zpool, the boot code must + also be updated to support the new zpool version. Run + gpart bootcode on the partition that + contains the boot code. See &man.gpart.8; for more + information. + =20 @@ -1255,7 +1356,7 @@ =20 - ZFS Replication + <acronym>ZFS</acronym> Replication =20 Keeping data on a single pool in one location exposes it to risks like theft, natural and human disasters. Keeping @@ -1265,12 +1366,13 @@ the data to standard output. Using this technique, it is possible to not only store the data on another pool connected to the local system, but also to send it over a network to - another system that runs ZFS. To achieve this replication, - ZFS uses filesystem snapshots (see the - section on ZFS snapshots) to send - them from one location to another. The commands for this - operation are zfs send and + another system that runs ZFS . To achieve + this replication, ZFS uses filesystem + snapshots (see the section on + ZFS + snapshots) to send them from one location to another. + The commands for this operation are + zfs send and zfs receive, respectively. =20 The following examples will demonstrate the functionality @@ -1277,7 +1379,7 @@ of ZFS replication using these two pools: =20 - &prompt.root; zpool list + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 77K 896M 0% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - @@ -1297,8 +1399,8 @@ ZFS only replicates snapshots, changes since the most recent snapshot will not be replicated. =20 - &prompt.root; zfs snapshot mypool@backup1 -&prompt.root; zfs list -t snapshot + &prompt.root; zfs snapshot mypool<= /replaceable>@backup1 +&prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT mypool@backup1 0 - 43.6M - =20 @@ -1305,11 +1407,11 @@ Now that a snapshot exists, zfs send can be used to create a stream representing the contents of the snapshot, which can be stored as a file, or received by - another pool. The stream will be written to standard - output, which will need to be redirected to a file or pipe - otherwise ZFS will produce an error: + another pool. The stream will be written to standard output, + which will need to be redirected to a file or pipe otherwise + ZFS will produce an error: =20 - &prompt.root; zfs send mypool@backup1 + &prompt.root; zfs send mypool@backup1 Error: Stream can not be written to a terminal. You must redirect standard output. =20 @@ -1320,8 +1422,8 @@ data contained in the snapshot, not only the changes in that snapshot. =20 - &prompt.root; zfs send mypool@backup1 > /backup/backup1= -&prompt.root; zpool list + &prompt.root; zfs send mypool@backup1 > /backup/backu= p1 +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 63.7M 896M 6% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - @@ -1334,10 +1436,10 @@ =20 Instead of storing the backups as archive files, ZFS can receive them as a live file system, - allowing the backed up data to be accessed directly. - To get to the actual data contained in those streams, the - reverse operation of zfs send must be used - to transform the streams back into files and directories. The + allowing the backed up data to be accessed directly. To get + to the actual data contained in those streams, the reverse + operation of zfs send must be used to + transform the streams back into files and directories. The command is zfs receive. The example below combines zfs send and zfs receive using a pipe to copy the data @@ -1345,31 +1447,30 @@ directly on the receiving pool after the transfer is complete. A dataset can only be replicated to an empty dataset. =20 - &prompt.root; zfs snapshot mypool@replica1 -&prompt.root; zfs send -v mypool@replica1 | zfs receive backup/mypool= + &prompt.root; zfs snapshot mypool<= /replaceable>@replica1 +&prompt.root; zfs send -v mypool@<= replaceable>replica1 | zfs receive backup/mypo= ol send from @ to mypool@replica1 estimated size is 50.1M total estimated size is 50.1M TIME SENT SNAPSHOT =20 -&prompt.root; zpool list +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 63.7M 896M 6% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - =20 - ZFS Incremental Backups + <acronym>ZFS</acronym> Incremental Backups =20 - Another feature of zfs send is that - it can determine the difference between two snapshots to - only send what has changed between the two. This results in - saving disk space and time for the transfer to another pool. - For example: + zfs send can also determine the + difference between two snapshots and only send the changes + between the two. This results in saving disk space and + transfer time. For example: =20 - &prompt.root; zfs snapshot mypool@backup2 + &prompt.root; zfs snapshot mypool@replica2 &prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT -mypool@backup1 5.72M - 43.6M - -mypool@backup2 0 - 44.1M - +mypool@replica1 5.72M - 43.6M - +mypool@replica2 0 - 44.1M - &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 61.7M 898M 6% 1.00x ONLINE - @@ -1376,77 +1477,59 @@ mypool 960M 50.2M 910M 5% 1.00x ONLINE - =20 A second snapshot called - backup2 was created. This second - snapshot contains only the changes on the ZFS filesystem - between now and the last snapshot, - backup1. Using the - -i flag to zfs send - and providing both snapshots, an incremental snapshot can be - transferred, containing only the data that has - changed. + replica2 was created. This + second snapshot contains only the changes on the + ZFS filesystem between now and the + previous snapshot, replica1. + Using with zfs send + and indicating the pair of snapshots, an incremental replica + stream can be generated, containing only the data that has + changed. This can only succeed if the initial snapshot + already exists on the receiving side. =20 - &prompt.root; zfs send -i mypool@backup1 mypool@backup2 > /backup/incremental= + &prompt.root; zfs send -v -i mypool@replica1 mypool@replica2 | zfs receive /b= ackup/mypool +send from @replica1 to mypool@replica2 estimated size is 5.02M +total estimated size is 5.02M +TIME SENT SNAPSHOT + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 80.8M 879M 8% 1.00x ONLINE - mypool 960M 50.2M 910M 5% 1.00x ONLINE - -&prompt.root; ls -lh /backup -total 82247 -drwxr-xr-x 1 root wheel 61M Dec 3 11:36 backup1 -drwxr-xr-x 1 root wheel 18M Dec 3 11:36 incremental= =20 - The incremental stream was successfully transferred and - the file on disk is smaller than any of the two snapshots - backup1 or - backup2. This shows that it only - contains the differences, which is much faster to transfer - and saves disk space by not copying the complete pool each - time. This is useful when having to rely on slow networks - or when costs per transferred byte have to be - considered. - +&prompt.root; zfs list +NAME USED AVAIL REFER MOUNTPOINT +backup 55.4M 240G 152K /backup +backup/mypool 55.3M 240G 55.2M /backup/mypool +mypool 55.6M 11.6G 55.0M /mypool =20 - - Receiving ZFS Data Streams +&prompt.root; zfs list -t snapshot +NAME USED AVAIL REFER MOUNTPO= INT +backup/mypool@replica1 104K - 50.2M - +backup/mypool@replica2 0 - 55.2M - +mypool@replica1 29.9K - 50.0M - +mypool@replica2 0 - 55.0M - =20 - Up until now, only the data streams in binary form were - sent to other pools. To get to the actual data contained in - those streams, the reverse operation of zfs - send has to be used to transform the streams - back into files and directories. The command is called - zfs receive and has also a short version: - zfs recv. The example below combines - zfs send and zfs - receive using a pipe to copy the data from one - pool to another. This way, the data can be used directly on - the receiving pool after the transfer is complete. + The incremental stream was successfully transferred and + only the data that has changed was replicated, rather than + the entirety of replica1 and + replica2 with both contain mostly + the same data. The transmitted data only contains the + differences, which took much less time to transfer and saves + disk space by not copying the complete pool each time. This + is useful when having to rely on slow networks or when costs + per transferred byte have to be considered. =20 - &prompt.root; zfs send mypool@backup1 | zfs receive backup= /backup1 -&prompt.root; ls -lh /backup -total 431 -drwxr-xr-x 4219 root wheel 4.1k Dec 3 11:34 backup1= - - The directory backup1 does - contain all the data, which were part of the snapshot of the - same name. Since this originally was a complete filesystem - snapshot, the listing of all ZFS filesystems for this pool - is also updated and shows the - backup1 entry. - - &prompt.root; zfs list -NAME USED AVAIL REFER MOUNTPOINT -backup 43.7M 884M 32K /backup -backup/backup1 43.5M 884M 43.5M /backup/backup1 -mypool 50.0M 878M 44.1M /mypool - - A new filesystem, backup1 is - available and has the same size as the snapshot it was - created from. It is up to the user to decide whether the - streams should be transformed back into filesystems directly - to have a cold-standby for emergencies or to just keep the - streams and transform them later when required. Sending and - receiving can be automated so that regular backups are - created on a second pool for backup purposes. + A new filesystem, + backup/mypool is + available and has all of the files and data from the pool + mypool. If + is specified, the properties of the dataset will be copied, + including compression settings, quotas and mount points. If + is specified all child datasets of the + indicated dataset will be copied, along with all of their + properties. Sending and receiving can be automated so that + regular backups are created on the second pool. =20 @@ -1454,27 +1537,26 @@ =20 Although sending streams to another system over the network is a good way to keep a remote backup, it does come - with a drawback. All the data sent over the network link is - not encrypted, allowing anyone to intercept and transform - the streams back into data without the knowledge of the - sending user. This is an unacceptable situation, especially - when sending the streams over the internet to a remote host - with multiple hops in between where such malicious data - collection can occur. Fortunately, there is a solution - available to the problem that does not require the - encryption of the data on the pool itself. To make sure the - network connection between both systems is securely + with a drawback. Data sent over the network link is not + encrypted, allowing anyone to intercept and transform the + streams back into data without the knowledge of the sending + user. This is undesirable, especially when sending the + streams over the internet to a remote host. To make sure + the network connection between both systems is securely encrypted, SSH can be used. - Since ZFS only requires the stream to be redirected from - standard output, it is relatively easy to pipe it through - SSH. + Since ZFS only requires the stream to be + redirected from standard output, it is relatively easy to + pipe it through SSH. If you wish + the contents of your ZFS file system to + remain encrypted on the remote system, consider using PEFS. =20 A few settings and security precautions have to be made - before this can be done. Since this chapter is about ZFS - and not about configuring SSH, it only lists the things - required to perform the encrypted zfs - send operation. The following settings should - be made: + before this can be done. Since this chapter is about + ZFS and not about configuring SSH, it + only lists the things required to perform the + zfs send operation. The following + configuration is required: =20 @@ -1483,50 +1565,74 @@ =20 - The root - user needs to be able to log into the receiving system - because only that user can send streams from the pool. - SSH should be configured so - that root can - only execute zfs recv and nothing - else to prevent users that might have hijacked this - account from doing any harm on the system. + Normally, the privledges of the + root user are + required to send and receive the ZFS + stream. This requires logging in to the receiving + system as + root, which is + disabled by default for security reasons. Rather than + enabling root login, it is possible to use the ZFS Delegation system + to allow a non-root user on each system to perform the + respective send and receieve operations. + + + On the sending system: + &prompt.root; zfs allow -u someuser send,snapshot = mypool + + + + In order for the pool to mounted, the unprivledged + user must own the directory, and regular users must be + allowed to mount file systems. On the receiving + system: + + &prompt.root; sysctl vfs.usermount=3D1 +vfs.usermount: 0 -> 1 +&prompt.root; echo vfs.usermount=3D1 >> /etc/sysctl.conf +&prompt.root; zfs create recvpool/backup +&prompt.root; zfs allow -u someuser create,mount,receive recvpo= ol/backup +&prompt.root; chown someuser /recvpool/backup + =20 - After these security measures have been put into place - and root can - connect via passwordless SSH to - the receiving system, the encrypted stream can be sent using - the following commands: + After the above procedure and the setup of + SSH keys, the unprivledged user + on the sending machine can connect via passwordless + SSH to the receiving system, and + the pool can be replicated using the following + commands: =20 - &prompt.root; zfs snapshot -r mypool/ho= me@monday -&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool<= /screen> + &prompt.user; zfs snapshot -r mypool/home= @monday +&prompt.user; zfs send -R mypool/home@monday | ssh someuser@backuphos= t zfs recv -dvu recvpool/backup<= /command> =20 The first command creates a recursive snapshot (option - -r) called - monday of the filesystem named + ) called + monday of the filesystem dataset home that resides on the pool mypool. The second command uses - the -R option to zfs - send, which makes sure that all datasets and - filesystems along with their children are included in the - transmission of the data stream. This also includes + to zfs send, which + makes sure that the dataset and all child datasets are + included in the transmitted data stream. This also includes snaphots, clones and settings on individual filesystems as - well. The output is piped directly to SSH that uses a short - name for the receiving host called - backuphost. A fully qualified - domain name or IP address can also be used here. The SSH - command to execute is zfs recv to a pool - called backuppool. Using the - -d option with zfs - recv will remove the original name of the pool - on the receiving side and just takes the name of the - snapshot instead. The -u option makes - sure that the filesystem is not mounted on the receiving - side. More information about the transfer—like the - time that has passed—is displayed when the - -v option is provided. + well. The output is piped to the waiting + zfs receive on the remote host + backuphost via + SSH. A fully qualified domain + name or IP address should be used here. The receiving + machine will write the data to + backup dataset on the + recvpool pool. Using + with zfs recv + will remove the original name of the pool on the receiving + side and just takes the name of the snapshot instead. + causes the filesystem(s) to not be + mounted on the receiving side. Details about the transfer + in progress, including time elapsed and a count of how much + data has been sent are displayed if + is specified. =20 @@ -1676,12 +1782,6 @@ &prompt.root; zfs get refreservation storage/home/bob =20 - - Compression - - - - Deduplication =20 @@ -1778,8 +1878,80 @@ due to the much lower memory requirements. =20 + + Compression + + ZFS provides transparent compression. + Compressing data at the block level as it is written not only + saves storage space, but can also result in higher disk + throughput than would otherwise be possible. If data is + compressed by 25%, then the compressed data can be written to + the disk at the same rate as the uncompressed version, + resulting in an effective write speed of 125% of what would + normally be possible. Compression can also be a great + alternative to + Deduplication + because it does not require additional memory to store a + DDT. + + ZFS offers a number of different + compression algorithms to choose from, each with different + trade-offs. With the introduction of LZ4 + compression in ZFS v5000, it is possible + to enable compression for the entire pool without the large + performance trade-off of other algorithms. The biggest + advantage to LZ4 is the + early abort feature. If + LZ4 does not achieve atleast 12.5% + compression in the first part of the data, the block is + written uncompressed to avoid wasting CPU cycles trying to + compress data that is either already compressed or + uncompressible. For details about the different compression + algorithms available in ZFS, see the + Compression entry + in the terminology section. + + The administrator can monitor the effectiveness of + ZFS compression using a number of dataset + properties. + + &prompt.root; zfs get used,compressratio,compre= ssion,logicalused mypool/compressed_dataset +NAME PROPERTY VALUE SOURCE +mypool/compressed_dataset used 449G - +mypool/compressed_dataset compressratio 1.11x - +mypool/compressed_dataset compression lz4 local +mypool/compressed_dataset logicalused 496G - + + The dataset is currently using 449 GB of storage + space (the used property). If this dataset was not compressed + it would have taken 496 GB of space (the logicallyused + property). This results in the 1.11:1 compression + ratio. + + Compression can have an unexpected side effect when + combined with + User Quotas. + ZFS user quotas restrict how much space + a user can consume on a dataset, however the measurements are + based on how much data is stored, after compression. So if a + user has a quota of 10 GB, and writes 10 GB of + compressible data, they will still be able to store additional + data. If they later update a file, say a database, with more + or less compressible data, the amount of space available to + them will change. This can result in the odd situation where + a user did not increase the actual amount of data (the + logicalused property), but the change in + compression means they have now reached their quota. + + Compression can have a similar unexpected interaction with + backups. Quotas are often used to limit how much data can be + stored to ensure there is sufficient backup space available. + However since quotas do not consider compression, more data + may be written than will fit in uncompressed backups. + + - ZFS and Jails + <acronym>ZFS</acronym> and Jails =20 zfs jail and the corresponding jailed property are used to delegate a @@ -1843,22 +2015,22 @@ =20 - ZFS Advanced Topics + <acronym>ZFS</acronym> Advanced Topics =20 - ZFS Tuning + <acronym>ZFS</acronym> Tuning =20 =20 - Booting Root on ZFS + Booting Root on <acronym>ZFS</acronym> =20 =20 - ZFS Boot Environments + <acronym>ZFS</acronym> Boot Environments =20 @@ -1870,7 +2042,7 @@ =20 - ZFS on i386 + <acronym>ZFS</acronym> on i386 =20 Some of the features provided by ZFS are memory intensive, and may require tuning for maximum @@ -1942,38 +2114,46 @@ FreeBSD - Wiki - ZFS + Wiki - ZFS =20 FreeBSD - Wiki - ZFS Tuning + Wiki - ZFS Tuning =20 Illumos - Wiki - ZFS + Wiki - ZFS =20 Oracle - Solaris ZFS Administration Guide + Solaris ZFS Administration + Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Ev= il_Tuning_Guide">ZFS Evil Tuning Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Be= st_Practices_Guide">ZFS Best Practices Guide + + + Cal= omel + Blog - ZFS Raidz Performance, Capacity + and Integrity + =20 @@ -2449,10 +2629,68 @@ and write throughput, as only the smaller compressed version of the file needs to be read or written. =20 - - LZ4 compression is only - available after &os; 9.2. - + + + LZ4 - + was added in ZFS pool version + 5000 (feature flags), and is now the recommended + compression algorithm. LZ4 + compresses approximately 50% faster than + LZJB when operating on + compressible data, and is over three times faster + when operating on uncompressible data. + LZ4 also decompresses + approximately 80% faster than + LZJB. On modern CPUs, + LZ4 can often compress at over + 500 MB/s, and decompress at over + 1.5 GB/s (per single CPU core). + + + LZ4 compression is + only available after &os; 9.2. + + + + + LZJB - + is the default compression algorithm in + ZFS. Created by Jeff Bonwick + (one of the original creators of + ZFS). LZJB + offers good compression with less + CPU overhead compared to + GZIP. In the future, the + default compression algorithm will likely change + to LZ4. + + + + GZIP - + is a popular stream compression algorithm and is + available in ZFS. One of the + main advantages of using GZIP + is its configurable level of compression. When + setting the compress property, + the administrator can choose which level of + compression to use, ranging from + gzip1, the lowest level of + compression, and gzip9, the + higher level of compression. This gives the + administrator control over how much + CPU time to trade for saved + disk space. + + + + ZLE - + (zero length encoding) is a special compression + algorithm that only compresses continuous runs of + zeros. This compression algorithm is only useful + if your dataset contains large areas where only + the zero byte is written. + + =20 @@ -2511,7 +2749,9 @@ at least once each quarter. Checksums of each block are tested as they are read in normal use, but a scrub operation makes sure even infrequently used blocks are - checked for silent corruption. + checked for silent corruption, improving the security of + your data, especially in archival storage + situations. =20 --------------030306020802040407040001-- --pIIQraK2r1kfXU3fjH1R16guxfJscdBKC 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.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBi9NAAoJEJrBFpNRJZKfHgUQAIklidr69ghc6XBXU1lI3M9m 9ywUmTaCTsy9TCNA2ncGOBjv4BGSXeiXqTIW8kHMY3iPqQYuGch0UbaA/kmAbkiM WYznhKTqRiGNY3GIjHG/HHWghoaRgRfBBPwQZTU1pQ4o/oJfWNb6EsSdAHkWjpCI hWWKAgkGJdkc6jFlKWwhkwgADaT74jPoIxLRO6pNWYklx8FiGex+Niz3HM75lcMb r/SGBaJ4/hcQ98kTjKRDw86UfOl85tX2d4Rib1JeRDRlo81CJtUgk3IamROLsQ48 BPSDxGPAL6BEH58Y4wt47mdFFJc0oZ04u0A8xuyTNtBO8L5i3Hmuouqx6lC+vcPJ 4ck/cNJJAKoiCLw6qh0YFfE52Yp90NprfByuS75fk4nfGJwbm6LmPClyvr5CSVle pxDNy+td01XCzNlFAtVEFbkvnJKk8qhQw6MqF7ZeMMdv+YXx/INgbLFmlPePMKsp Tx6TBxILcORw8R9YrkRwbKYJIFssvIX07ZHpD7iXZhWgYy7K4xepvBrAjZgaPwvs yUDl2TTgdGHeKr1MqkfAJVEOFJd2VEVaAntmKhYm0u/Fg8GuzLlx70cquR32wnbm g0OKrsr9n8RG1L/9UpwhRIDHgzm9db+Tz7ylSBLFR7+MPGciuTZhaYfeTveMZcpL nzVtZcnbqnMyBOrzE4lr =Vay9 -----END PGP SIGNATURE----- --pIIQraK2r1kfXU3fjH1R16guxfJscdBKC-- From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 19:08:33 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AA25863 for ; Thu, 20 Feb 2014 19:08:33 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26D02139C for ; Thu, 20 Feb 2014 19:08:33 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1KJ8TPc071448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Feb 2014 12:08:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1KJ8P1X071445; Thu, 20 Feb 2014 12:08:29 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 20 Feb 2014 12:08:25 -0700 (MST) From: Warren Block To: Allan Jude Subject: Re: ZFS handbook project patch In-Reply-To: <53062F44.1050906@allanjude.com> Message-ID: References: <5305A9A4.1010603@allanjude.com> <20140220.162055.109321178462259649.hrs@allbsd.org> <53062F44.1050906@allanjude.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 20 Feb 2014 12:08:29 -0700 (MST) Cc: freebsd-doc@freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:08:33 -0000 On Thu, 20 Feb 2014, Allan Jude wrote: > > I've quickly switch those back to > > I used simple logic, if talking about a command in a paragraph, use > , when doing it in a use , as in a > paragraph it is usually never more than a subcommand like zfs > send That's correct, IMO. Semantically, command tags could be used inside userinput, but that really does not seem to gain much, and would suggest filenames and other content in sections would become even more complicated. > Also, I just noticed that a bunch of the stuff from my previous zfs > patch didn't get in (I sent 2, a whitespace and a content patch, and > only the whitespace one got in), so I've included the updated zfs send > stuff as well (how to do replication without root) bcr responded about that, and was waiting for feedback (I think). > IIRC, this means the stuff I wrote for the CARP chapter last week is > wrong with regards to instead of ...yes. Fixed. From owner-freebsd-doc@FreeBSD.ORG Thu Feb 20 20:58:59 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF6BECF2 for ; Thu, 20 Feb 2014 20:58:59 +0000 (UTC) Received: from mxout2.bln1.prohost.de (mxout2.bln1.prohost.de [91.233.87.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47DB51F6D for ; Thu, 20 Feb 2014 20:58:59 +0000 (UTC) Received: from Voyager.local (p4FC7258B.dip0.t-ipconnect.de [79.199.37.139]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.4/8.14.4) with ESMTP id s1KKwmJg008666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 21:58:49 +0100 Message-ID: <53066C8B.6040009@FreeBSD.org> Date: Thu, 20 Feb 2014 21:58:51 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Subject: Re: ZFS handbook project patch References: <5305A9A4.1010603@allanjude.com> <20140220.162055.109321178462259649.hrs@allbsd.org> <53062F44.1050906@allanjude.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Null-Tag: 5978b5542c1932ed759d76c147fa0313 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:58:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 20.02.14 20:08, schrieb Warren Block: > On Thu, 20 Feb 2014, Allan Jude wrote: >> >> I've quickly switch those back to >> >> I used simple logic, if talking about a command in a paragraph, >> use , when doing it in a use , as in >> a paragraph it is usually never more than a subcommand like >> zfs send > > That's correct, IMO. Semantically, command tags could be used > inside userinput, but that really does not seem to gain much, and > would suggest filenames and other content in sections > would become even more complicated. > >> Also, I just noticed that a bunch of the stuff from my previous >> zfs patch didn't get in (I sent 2, a whitespace and a content >> patch, and only the whitespace one got in), so I've included the >> updated zfs send stuff as well (how to do replication without >> root) > > bcr responded about that, and was waiting for feedback (I think). > Indeed. But no worries. Now that it is one patch, we can review it together. Good work, Allan! The chapter is beginning to look better and better. Regards Benedict -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTBmyLAAoJEAQa31nbPD2LjaQH/0yaD9HtNIIvbx6GeOQ8Rstd p3097q5u0rPSs3bLso5NKE5GXeCOJ5CMWd3ogQRtz8a693c4ImN7IKxz62ZIRhIk /P3k7/nj1ghrT4e2fDsojSG3LM/D/rN2oQeVL9KijBC8uiGuPLo5GJpIefe/RKpT 6jwH1DLyYD9XmO2HofdCavp3RbnwJBJgfSuEEEbhWUvvcoaFgKLIodK8Aq7egAvI vWrOBRoahW44B0EAcDUo3PW2A24ghYQO2xm9YIfLL3P0GlOreU+GTzHkivchw44k fVj6ZReYL64j4e0wAwyFomXCs/mRsaW/mM+PJKCFBT3QlxD2E+VPQXfoa1c+3Io= =gmZ/ -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Fri Feb 21 01:19:41 2014 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D26F0131 for ; Fri, 21 Feb 2014 01:19:41 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1BA18F1 for ; Fri, 21 Feb 2014 01:19:40 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3CB795EE6A for ; Fri, 21 Feb 2014 01:19:37 +0000 (UTC) Message-ID: <5306A9A4.1070608@allanjude.com> Date: Thu, 20 Feb 2014 20:19:32 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-doc@freebsd.org Subject: Re: ZFS handbook project patch References: <5305A9A4.1010603@allanjude.com> <20140220.162055.109321178462259649.hrs@allbsd.org> <53062F44.1050906@allanjude.com> <53066C8B.6040009@FreeBSD.org> In-Reply-To: <53066C8B.6040009@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n4AeXQW6tu8qeNcDkUWhAQlEc5oOCK54n" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 01:19:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n4AeXQW6tu8qeNcDkUWhAQlEc5oOCK54n Content-Type: multipart/mixed; boundary="------------090902080304030802060700" This is a multi-part message in MIME format. --------------090902080304030802060700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-02-20 15:58, Benedict Reuschling wrote: > Am 20.02.14 20:08, schrieb Warren Block: >> On Thu, 20 Feb 2014, Allan Jude wrote: >>> >>> I've quickly switch those back to >>> >>> I used simple logic, if talking about a command in a paragraph, >>> use , when doing it in a use , as in >>> a paragraph it is usually never more than a subcommand like >>> zfs send >=20 >> That's correct, IMO. Semantically, command tags could be used >> inside userinput, but that really does not seem to gain much, and >> would suggest filenames and other content in sections >> would become even more complicated. >=20 >>> Also, I just noticed that a bunch of the stuff from my previous >>> zfs patch didn't get in (I sent 2, a whitespace and a content >>> patch, and only the whitespace one got in), so I've included the >>> updated zfs send stuff as well (how to do replication without >>> root) >=20 >> bcr responded about that, and was waiting for feedback (I think). >=20 >=20 > Indeed. But no worries. Now that it is one patch, we can review it > together. >=20 > Good work, Allan! The chapter is beginning to look better and better. >=20 > Regards >=20 > Benedict > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" >=20 Minor update to the patch to fix a spelling mistake pointed out by bcr@ --=20 Allan Jude --------------090902080304030802060700 Content-Type: text/plain; charset=windows-1252; name="zfs.compression_status_scrub_send_v2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs.compression_status_scrub_send_v2.diff" Index: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapt= er.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.= xml (revision 44001) +++ projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.= xml (working copy) @@ -483,7 +483,7 @@ The duration of a scrub depends on the amount of data stored. Large amounts of data can take a considerable amount of time to verify. It is also very I/O - intensive, so much so that only one scrub> may be run at any + intensive, so much so that only one scrub may be run at any given time. After the scrub has completed, the status is updated and may be viewed with a status request: =20 @@ -502,9 +502,10 @@ =20 errors: No known data errors =20 - The completion time is displayed and helps to ensure data - integrity over a long period of time. - + The completion date of the last scrub operation is + displayed to help track when another scrub is required. + Routine pool scrubs help protect data from silent corruption + and ensure the integrity of the pool. =20 Refer to &man.zfs.8; and &man.zpool.8; for other ZFS options. @@ -581,6 +582,53 @@ redundancy. =20 + + Checking the Status of a Pool + + It is important to monitor the status of the + ZFS pool. If a drive goes offline, a + read or write error is detected, or a checksum fails to match, + the corresponding counters in the + display will be incremented. The + output shows the configuration and status of each device in + the pool, in addition to the status of the pool as the whole. + Also displayed are any actions that may need to be taken, and + details about when the last + + operation was completed. + + &prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub repaired 0 in 2h25m with 0 errors on Sat Sep 14 04:25:50 2= 013 +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + + + Clearing Errors + + If an error is detected with a device in a pool, the + corresponding read, write, or checksum counter will be + incremented. Once the issue is resolved, or to track the + rate of errors, zpool clear mypool will + reset the counters. This step can be important for automated + scripts that monitor the health of the pool and alert the + administrator when there is an error, further errors may not + be reported if the old errors are not cleared. + + Replacing a Functioning Device =20 @@ -622,8 +670,40 @@ restored from backups. =20 + + Scrubbing a Pool + + It is strongly recommended that a + Scrub operation be + performed regularly. Ideally atleast once each quarter. The + operating is very I/O intensive and + will reduce performance while it is in progress, so it much + be scheduled to avoid high demand periods. + + &prompt.root; zpool scrub mypool +&prompt.root; zpool status + pool: mypool + state: ONLINE + scan: scrub in progress since Wed Feb 19 20:52:54 2014 + 116G scanned out of 8.60T at 649M/s, 3h48m to go + 0 repaired, 1.32% done +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + raidz2-0 ONLINE 0 0 0 + ada0p3 ONLINE 0 0 0 + ada1p3 ONLINE 0 0 0 + ada2p3 ONLINE 0 0 0 + ada3p3 ONLINE 0 0 0 + ada4p3 ONLINE 0 0 0 + ada5p3 ONLINE 0 0 0 + +errors: No known data errors + + - ZFS Self-Healing + <acronym>ZFS</acronym> Self-Healing =20 ZFS utilizes the checkums stored with each data block to provide a feature called self-healing. @@ -890,17 +970,38 @@ need to be imported on an older system before upgrading. The upgrade process is unreversible and cannot be undone. =20 + &prompt.root; zpool status + pool: mypool + state: ONLINE +status: The pool is formatted using a legacy on-disk format. The pool c= an + still be used, but some features are unavailable. +action: Upgrade the pool using 'zpool upgrade'. Once this is done, the + pool will no longer be accessible on software that does not supp= ort feat + flags. + scan: none requested +config: + + NAME STATE READ WRITE CKSUM + mypool ONLINE 0 0 0 + mirror-0 ONLINE 0 0 0 + ada0 ONLINE 0 0 0 + ada1 ONLINE 0 0 0 + +errors: No known data errors + The newer features of ZFS will not be available until zpool upgrade has completed. can be used to see what new features will be provided by upgrading, as well as which features are already supported by the existing version. - =20 - - Checking the Status of a Pool - - + + If the system boots from the zpool, the boot code must + also be updated to support the new zpool version. Run + gpart bootcode on the partition that + contains the boot code. See &man.gpart.8; for more + information. + =20 @@ -1255,7 +1356,7 @@ =20 - ZFS Replication + <acronym>ZFS</acronym> Replication =20 Keeping data on a single pool in one location exposes it to risks like theft, natural and human disasters. Keeping @@ -1265,12 +1366,13 @@ the data to standard output. Using this technique, it is possible to not only store the data on another pool connected to the local system, but also to send it over a network to - another system that runs ZFS. To achieve this replication, - ZFS uses filesystem snapshots (see the - section on ZFS snapshots) to send - them from one location to another. The commands for this - operation are zfs send and + another system that runs ZFS . To achieve + this replication, ZFS uses filesystem + snapshots (see the section on + ZFS + snapshots) to send them from one location to another. + The commands for this operation are + zfs send and zfs receive, respectively. =20 The following examples will demonstrate the functionality @@ -1277,7 +1379,7 @@ of ZFS replication using these two pools: =20 - &prompt.root; zpool list + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 77K 896M 0% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - @@ -1297,8 +1399,8 @@ ZFS only replicates snapshots, changes since the most recent snapshot will not be replicated. =20 - &prompt.root; zfs snapshot mypool@backup1 -&prompt.root; zfs list -t snapshot + &prompt.root; zfs snapshot mypool<= /replaceable>@backup1 +&prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT mypool@backup1 0 - 43.6M - =20 @@ -1305,11 +1407,11 @@ Now that a snapshot exists, zfs send can be used to create a stream representing the contents of the snapshot, which can be stored as a file, or received by - another pool. The stream will be written to standard - output, which will need to be redirected to a file or pipe - otherwise ZFS will produce an error: + another pool. The stream will be written to standard output, + which will need to be redirected to a file or pipe otherwise + ZFS will produce an error: =20 - &prompt.root; zfs send mypool@backup1 + &prompt.root; zfs send mypool@backup1 Error: Stream can not be written to a terminal. You must redirect standard output. =20 @@ -1320,8 +1422,8 @@ data contained in the snapshot, not only the changes in that snapshot. =20 - &prompt.root; zfs send mypool@backup1 > /backup/backup1= -&prompt.root; zpool list + &prompt.root; zfs send mypool@backup1 > /backup/backu= p1 +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 63.7M 896M 6% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - @@ -1334,10 +1436,10 @@ =20 Instead of storing the backups as archive files, ZFS can receive them as a live file system, - allowing the backed up data to be accessed directly. - To get to the actual data contained in those streams, the - reverse operation of zfs send must be used - to transform the streams back into files and directories. The + allowing the backed up data to be accessed directly. To get + to the actual data contained in those streams, the reverse + operation of zfs send must be used to + transform the streams back into files and directories. The command is zfs receive. The example below combines zfs send and zfs receive using a pipe to copy the data @@ -1345,31 +1447,30 @@ directly on the receiving pool after the transfer is complete. A dataset can only be replicated to an empty dataset. =20 - &prompt.root; zfs snapshot mypool@replica1 -&prompt.root; zfs send -v mypool@replica1 | zfs receive backup/mypool= + &prompt.root; zfs snapshot mypool<= /replaceable>@replica1 +&prompt.root; zfs send -v mypool@<= replaceable>replica1 | zfs receive backup/mypo= ol send from @ to mypool@replica1 estimated size is 50.1M total estimated size is 50.1M TIME SENT SNAPSHOT =20 -&prompt.root; zpool list +&prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 63.7M 896M 6% 1.00x ONLINE - mypool 984M 43.7M 940M 4% 1.00x ONLINE - =20 - ZFS Incremental Backups + <acronym>ZFS</acronym> Incremental Backups =20 - Another feature of zfs send is that - it can determine the difference between two snapshots to - only send what has changed between the two. This results in - saving disk space and time for the transfer to another pool. - For example: + zfs send can also determine the + difference between two snapshots and only send the changes + between the two. This results in saving disk space and + transfer time. For example: =20 - &prompt.root; zfs snapshot mypool@backup2 + &prompt.root; zfs snapshot mypool@replica2 &prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT -mypool@backup1 5.72M - 43.6M - -mypool@backup2 0 - 44.1M - +mypool@replica1 5.72M - 43.6M - +mypool@replica2 0 - 44.1M - &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 61.7M 898M 6% 1.00x ONLINE - @@ -1376,77 +1477,59 @@ mypool 960M 50.2M 910M 5% 1.00x ONLINE - =20 A second snapshot called - backup2 was created. This second - snapshot contains only the changes on the ZFS filesystem - between now and the last snapshot, - backup1. Using the - -i flag to zfs send - and providing both snapshots, an incremental snapshot can be - transferred, containing only the data that has - changed. + replica2 was created. This + second snapshot contains only the changes on the + ZFS filesystem between now and the + previous snapshot, replica1. + Using with zfs send + and indicating the pair of snapshots, an incremental replica + stream can be generated, containing only the data that has + changed. This can only succeed if the initial snapshot + already exists on the receiving side. =20 - &prompt.root; zfs send -i mypool@backup1 mypool@backup2 > /backup/incremental= + &prompt.root; zfs send -v -i mypool@replica1 mypool@replica2 | zfs receive /b= ackup/mypool +send from @replica1 to mypool@replica2 estimated size is 5.02M +total estimated size is 5.02M +TIME SENT SNAPSHOT + &prompt.root; zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 960M 80.8M 879M 8% 1.00x ONLINE - mypool 960M 50.2M 910M 5% 1.00x ONLINE - -&prompt.root; ls -lh /backup -total 82247 -drwxr-xr-x 1 root wheel 61M Dec 3 11:36 backup1 -drwxr-xr-x 1 root wheel 18M Dec 3 11:36 incremental= =20 - The incremental stream was successfully transferred and - the file on disk is smaller than any of the two snapshots - backup1 or - backup2. This shows that it only - contains the differences, which is much faster to transfer - and saves disk space by not copying the complete pool each - time. This is useful when having to rely on slow networks - or when costs per transferred byte have to be - considered. - +&prompt.root; zfs list +NAME USED AVAIL REFER MOUNTPOINT +backup 55.4M 240G 152K /backup +backup/mypool 55.3M 240G 55.2M /backup/mypool +mypool 55.6M 11.6G 55.0M /mypool =20 - - Receiving ZFS Data Streams +&prompt.root; zfs list -t snapshot +NAME USED AVAIL REFER MOUNTPO= INT +backup/mypool@replica1 104K - 50.2M - +backup/mypool@replica2 0 - 55.2M - +mypool@replica1 29.9K - 50.0M - +mypool@replica2 0 - 55.0M - =20 - Up until now, only the data streams in binary form were - sent to other pools. To get to the actual data contained in - those streams, the reverse operation of zfs - send has to be used to transform the streams - back into files and directories. The command is called - zfs receive and has also a short version: - zfs recv. The example below combines - zfs send and zfs - receive using a pipe to copy the data from one - pool to another. This way, the data can be used directly on - the receiving pool after the transfer is complete. + The incremental stream was successfully transferred and + only the data that has changed was replicated, rather than + the entirety of replica1 and + replica2 with both contain mostly + the same data. The transmitted data only contains the + differences, which took much less time to transfer and saves + disk space by not copying the complete pool each time. This + is useful when having to rely on slow networks or when costs + per transferred byte have to be considered. =20 - &prompt.root; zfs send mypool@backup1 | zfs receive backup= /backup1 -&prompt.root; ls -lh /backup -total 431 -drwxr-xr-x 4219 root wheel 4.1k Dec 3 11:34 backup1= - - The directory backup1 does - contain all the data, which were part of the snapshot of the - same name. Since this originally was a complete filesystem - snapshot, the listing of all ZFS filesystems for this pool - is also updated and shows the - backup1 entry. - - &prompt.root; zfs list -NAME USED AVAIL REFER MOUNTPOINT -backup 43.7M 884M 32K /backup -backup/backup1 43.5M 884M 43.5M /backup/backup1 -mypool 50.0M 878M 44.1M /mypool - - A new filesystem, backup1 is - available and has the same size as the snapshot it was - created from. It is up to the user to decide whether the - streams should be transformed back into filesystems directly - to have a cold-standby for emergencies or to just keep the - streams and transform them later when required. Sending and - receiving can be automated so that regular backups are - created on a second pool for backup purposes. + A new filesystem, + backup/mypool is + available and has all of the files and data from the pool + mypool. If + is specified, the properties of the dataset will be copied, + including compression settings, quotas and mount points. If + is specified all child datasets of the + indicated dataset will be copied, along with all of their + properties. Sending and receiving can be automated so that + regular backups are created on the second pool. =20 @@ -1454,27 +1537,26 @@ =20 Although sending streams to another system over the network is a good way to keep a remote backup, it does come - with a drawback. All the data sent over the network link is - not encrypted, allowing anyone to intercept and transform - the streams back into data without the knowledge of the - sending user. This is an unacceptable situation, especially - when sending the streams over the internet to a remote host - with multiple hops in between where such malicious data - collection can occur. Fortunately, there is a solution - available to the problem that does not require the - encryption of the data on the pool itself. To make sure the - network connection between both systems is securely + with a drawback. Data sent over the network link is not + encrypted, allowing anyone to intercept and transform the + streams back into data without the knowledge of the sending + user. This is undesirable, especially when sending the + streams over the internet to a remote host. To make sure + the network connection between both systems is securely encrypted, SSH can be used. - Since ZFS only requires the stream to be redirected from - standard output, it is relatively easy to pipe it through - SSH. + Since ZFS only requires the stream to be + redirected from standard output, it is relatively easy to + pipe it through SSH. If you wish + the contents of your ZFS file system to + remain encrypted on the remote system, consider using PEFS. =20 A few settings and security precautions have to be made - before this can be done. Since this chapter is about ZFS - and not about configuring SSH, it only lists the things - required to perform the encrypted zfs - send operation. The following settings should - be made: + before this can be done. Since this chapter is about + ZFS and not about configuring SSH, it + only lists the things required to perform the + zfs send operation. The following + configuration is required: =20 @@ -1483,50 +1565,74 @@ =20 - The root - user needs to be able to log into the receiving system - because only that user can send streams from the pool. - SSH should be configured so - that root can - only execute zfs recv and nothing - else to prevent users that might have hijacked this - account from doing any harm on the system. + Normally, the privileges of the + root user are + required to send and receive the ZFS + stream. This requires logging in to the receiving + system as + root, which is + disabled by default for security reasons. Rather than + enabling root login, it is possible to use the ZFS Delegation system + to allow a non-root user on each system to perform the + respective send and receieve operations. + + + On the sending system: + &prompt.root; zfs allow -u someuser send,snapshot = mypool + + + + In order for the pool to mounted, the unprivileged + user must own the directory, and regular users must be + allowed to mount file systems. On the receiving + system: + + &prompt.root; sysctl vfs.usermount=3D1 +vfs.usermount: 0 -> 1 +&prompt.root; echo vfs.usermount=3D1 >> /etc/sysctl.conf +&prompt.root; zfs create recvpool/backup +&prompt.root; zfs allow -u someuser create,mount,receive recvpo= ol/backup +&prompt.root; chown someuser /recvpool/backup + =20 - After these security measures have been put into place - and root can - connect via passwordless SSH to - the receiving system, the encrypted stream can be sent using - the following commands: + After the above procedure and the setup of + SSH keys, the unprivileged user + on the sending machine can connect via passwordless + SSH to the receiving system, and + the pool can be replicated using the following + commands: =20 - &prompt.root; zfs snapshot -r mypool/ho= me@monday -&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool<= /screen> + &prompt.user; zfs snapshot -r mypool/home= @monday +&prompt.user; zfs send -R mypool/home@monday | ssh someuser@backuphos= t zfs recv -dvu recvpool/backup<= /command> =20 The first command creates a recursive snapshot (option - -r) called - monday of the filesystem named + ) called + monday of the filesystem dataset home that resides on the pool mypool. The second command uses - the -R option to zfs - send, which makes sure that all datasets and - filesystems along with their children are included in the - transmission of the data stream. This also includes + to zfs send, which + makes sure that the dataset and all child datasets are + included in the transmitted data stream. This also includes snaphots, clones and settings on individual filesystems as - well. The output is piped directly to SSH that uses a short - name for the receiving host called - backuphost. A fully qualified - domain name or IP address can also be used here. The SSH - command to execute is zfs recv to a pool - called backuppool. Using the - -d option with zfs - recv will remove the original name of the pool - on the receiving side and just takes the name of the - snapshot instead. The -u option makes - sure that the filesystem is not mounted on the receiving - side. More information about the transfer—like the - time that has passed—is displayed when the - -v option is provided. + well. The output is piped to the waiting + zfs receive on the remote host + backuphost via + SSH. A fully qualified domain + name or IP address should be used here. The receiving + machine will write the data to + backup dataset on the + recvpool pool. Using + with zfs recv + will remove the original name of the pool on the receiving + side and just takes the name of the snapshot instead. + causes the filesystem(s) to not be + mounted on the receiving side. Details about the transfer + in progress, including time elapsed and a count of how much + data has been sent are displayed if + is specified. =20 @@ -1676,12 +1782,6 @@ &prompt.root; zfs get refreservation storage/home/bob =20 - - Compression - - - - Deduplication =20 @@ -1778,8 +1878,80 @@ due to the much lower memory requirements. =20 + + Compression + + ZFS provides transparent compression. + Compressing data at the block level as it is written not only + saves storage space, but can also result in higher disk + throughput than would otherwise be possible. If data is + compressed by 25%, then the compressed data can be written to + the disk at the same rate as the uncompressed version, + resulting in an effective write speed of 125% of what would + normally be possible. Compression can also be a great + alternative to + Deduplication + because it does not require additional memory to store a + DDT. + + ZFS offers a number of different + compression algorithms to choose from, each with different + trade-offs. With the introduction of LZ4 + compression in ZFS v5000, it is possible + to enable compression for the entire pool without the large + performance trade-off of other algorithms. The biggest + advantage to LZ4 is the + early abort feature. If + LZ4 does not achieve atleast 12.5% + compression in the first part of the data, the block is + written uncompressed to avoid wasting CPU cycles trying to + compress data that is either already compressed or + uncompressible. For details about the different compression + algorithms available in ZFS, see the + Compression entry + in the terminology section. + + The administrator can monitor the effectiveness of + ZFS compression using a number of dataset + properties. + + &prompt.root; zfs get used,compressratio,compre= ssion,logicalused mypool/compressed_dataset +NAME PROPERTY VALUE SOURCE +mypool/compressed_dataset used 449G - +mypool/compressed_dataset compressratio 1.11x - +mypool/compressed_dataset compression lz4 local +mypool/compressed_dataset logicalused 496G - + + The dataset is currently using 449 GB of storage + space (the used property). If this dataset was not compressed + it would have taken 496 GB of space (the logicallyused + property). This results in the 1.11:1 compression + ratio. + + Compression can have an unexpected side effect when + combined with + User Quotas. + ZFS user quotas restrict how much space + a user can consume on a dataset, however the measurements are + based on how much data is stored, after compression. So if a + user has a quota of 10 GB, and writes 10 GB of + compressible data, they will still be able to store additional + data. If they later update a file, say a database, with more + or less compressible data, the amount of space available to + them will change. This can result in the odd situation where + a user did not increase the actual amount of data (the + logicalused property), but the change in + compression means they have now reached their quota. + + Compression can have a similar unexpected interaction with + backups. Quotas are often used to limit how much data can be + stored to ensure there is sufficient backup space available. + However since quotas do not consider compression, more data + may be written than will fit in uncompressed backups. + + - ZFS and Jails + <acronym>ZFS</acronym> and Jails =20 zfs jail and the corresponding jailed property are used to delegate a @@ -1843,22 +2015,22 @@ =20 - ZFS Advanced Topics + <acronym>ZFS</acronym> Advanced Topics =20 - ZFS Tuning + <acronym>ZFS</acronym> Tuning =20 =20 - Booting Root on ZFS + Booting Root on <acronym>ZFS</acronym> =20 =20 - ZFS Boot Environments + <acronym>ZFS</acronym> Boot Environments =20 @@ -1870,7 +2042,7 @@ =20 - ZFS on i386 + <acronym>ZFS</acronym> on i386 =20 Some of the features provided by ZFS are memory intensive, and may require tuning for maximum @@ -1942,38 +2114,46 @@ FreeBSD - Wiki - ZFS + Wiki - ZFS =20 FreeBSD - Wiki - ZFS Tuning + Wiki - ZFS Tuning =20 Illumos - Wiki - ZFS + Wiki - ZFS =20 Oracle - Solaris ZFS Administration Guide + Solaris ZFS Administration + Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Ev= il_Tuning_Guide">ZFS Evil Tuning Guide =20 ZFS + xlink:href=3D"http://www.solarisinternals.com/wiki/index.php/ZFS_Be= st_Practices_Guide">ZFS Best Practices Guide + + + Cal= omel + Blog - ZFS Raidz Performance, Capacity + and Integrity + =20 @@ -2449,10 +2629,68 @@ and write throughput, as only the smaller compressed version of the file needs to be read or written. =20 - - LZ4 compression is only - available after &os; 9.2. - + + + LZ4 - + was added in ZFS pool version + 5000 (feature flags), and is now the recommended + compression algorithm. LZ4 + compresses approximately 50% faster than + LZJB when operating on + compressible data, and is over three times faster + when operating on uncompressible data. + LZ4 also decompresses + approximately 80% faster than + LZJB. On modern CPUs, + LZ4 can often compress at over + 500 MB/s, and decompress at over + 1.5 GB/s (per single CPU core). + + + LZ4 compression is + only available after &os; 9.2. + + + + + LZJB - + is the default compression algorithm in + ZFS. Created by Jeff Bonwick + (one of the original creators of + ZFS). LZJB + offers good compression with less + CPU overhead compared to + GZIP. In the future, the + default compression algorithm will likely change + to LZ4. + + + + GZIP - + is a popular stream compression algorithm and is + available in ZFS. One of the + main advantages of using GZIP + is its configurable level of compression. When + setting the compress property, + the administrator can choose which level of + compression to use, ranging from + gzip1, the lowest level of + compression, and gzip9, the + higher level of compression. This gives the + administrator control over how much + CPU time to trade for saved + disk space. + + + + ZLE - + (zero length encoding) is a special compression + algorithm that only compresses continuous runs of + zeros. This compression algorithm is only useful + if your dataset contains large areas where only + the zero byte is written. + + =20 @@ -2511,7 +2749,9 @@ at least once each quarter. Checksums of each block are tested as they are read in normal use, but a scrub operation makes sure even infrequently used blocks are - checked for silent corruption. + checked for silent corruption, improving the security of + your data, especially in archival storage + situations. =20 --------------090902080304030802060700-- --n4AeXQW6tu8qeNcDkUWhAQlEc5oOCK54n 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.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBqmpAAoJEJrBFpNRJZKfZ7kP/i9a86txJ6Et9I5UuOiiu3Vl ePPAmEz+y355QSDKCe+tsDr9gECtz5ZCjzKhnhOF7mfGTOWiOgS3/wIIWSD8wY5i jJSGzKXNwA4qXSdB4v87IgITN17shOn2+n6GnhMlZgtwL10jKAdmo8fXBJx5JtLE 9WS//WiKGfcQRBk5h1+caUSyrYG0uQEHDCm6f4jBo5CZ8Jfn4cmyDCi7oWL7qfyR nGsdjjPqIRL28rxI3cw87K1quUZr/QfaY2Nz0MSB50V4QEL7yRKlZRS3wwE3Nk/a s5D9I5glsu6BMAyMUxUhw1zvDIpIHwqEDf1TZtZIqCg7jvINPBJCPfFWzwuSJwTd v8gWX9vVuz4rb/ayrVqkdjSBwZ7ShX2KOOt+WlzWX1X6XVArpggeE9EF4wRvTp16 0KxSHptYAgyQb9i2hALajUeHuZdQz62rck9a+krva7n5wLyJ4ssFrHBV84YwMWv3 haY1kjph9XLGA7mUJgVUPPFAg67q1pRl3GtDudX7+H4C8ck6PnO3wxry+67S/sCw y4xht9fF/cpEw+bjeu6aydqqtEerICB8hhrsqKI+htuXLaXuuEqjjSLYFIfVkWfC I8PEH2Y65A9iTpo6R2d6zTHJ1988gUH41XjzlIbpKRhfQQ40U4Dq8bSqgx9fniwB 3iuus3JX7YZWeXMa9pfW =rYkv -----END PGP SIGNATURE----- --n4AeXQW6tu8qeNcDkUWhAQlEc5oOCK54n-- From owner-freebsd-doc@FreeBSD.ORG Fri Feb 21 13:54:52 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98835360; Fri, 21 Feb 2014 13:54:52 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B50B10CF; Fri, 21 Feb 2014 13:54:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1LDsqNC036091; Fri, 21 Feb 2014 13:54:52 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1LDspxb036090; Fri, 21 Feb 2014 14:54:51 +0100 (CET) (envelope-from brueffer) Date: Fri, 21 Feb 2014 14:54:51 +0100 (CET) Message-Id: <201402211354.s1LDspxb036090@freefall.freebsd.org> To: tmueller@sysgo.com, brueffer@FreeBSD.org, freebsd-doc@FreeBSD.org, brueffer@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: docs/121173: [patch] mq_getattr(2): mq_flags mistakenly described as holding messages currently on the queue X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:54:52 -0000 Synopsis: [patch] mq_getattr(2): mq_flags mistakenly described as holding messages currently on the queue State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Fri Feb 21 14:53:54 CET 2014 State-Changed-Why: Fix committed, thanks! Sorry it took so long to get such an obvious thing corrected. Responsible-Changed-From-To: freebsd-doc->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Fri Feb 21 14:53:54 CET 2014 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=121173 From owner-freebsd-doc@FreeBSD.ORG Sat Feb 22 02:11:19 2014 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F14EA69 for ; Sat, 22 Feb 2014 02:11:19 +0000 (UTC) Received: from mayerbrown.com (dpc6744226115.direcpc.com [67.44.226.115]) by mx1.freebsd.org (Postfix) with SMTP id D541C16EF for ; Sat, 22 Feb 2014 02:10:52 +0000 (UTC) Message-ID: <002d01cf2f7351cfb0066701a8c0@test> From: "Eviction Notice" To: Subject: Urgent eviction notification Item No 9103 Date: Fri, 21 Feb 2014 20:10:55 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: XimianEvolution1.4.6 X-MimeOLE: Produced By XimianEvolution1.4.6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 02:11:19 -0000 Eviction notice, We hereby give you a notice that due to multiple violations your tenancy of the premises you occupy will be terminated on March 02, 2014. Detailed description of the violations and adjudication are attached herewith. Unless you vacate the property until March 25, 2014, the Court will provide an order to evict you and require you to pay all the costs incurred in bringing this action. Court bailiff, FOLEY Valentine