From owner-freebsd-doc@FreeBSD.ORG Sun Feb 27 13:08:29 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8DBE106566B; Sun, 27 Feb 2011 13:08:29 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id 22C528FC12; Sun, 27 Feb 2011 13:08:28 +0000 (UTC) Received: from [78.35.67.51] (helo=r500.local) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PtgBK-0002Pf-Aj; Sun, 27 Feb 2011 13:57:05 +0100 Date: Sun, 27 Feb 2011 13:56:47 +0100 From: Fabian Keil To: freebsd-doc@freebsd.org Message-ID: <20110227135647.4437d198@r500.local> In-Reply-To: <20110227103645.GA53342@freefall.freebsd.org> References: <20110227103645.GA53342@freefall.freebsd.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/lReSWOG.c=OxhCd_mFceZ_K"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Subject: Re: RFC: New Handbook section - HAST X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 13:08:29 -0000 --Sig_/lReSWOG.c=OxhCd_mFceZ_K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Daniel Gerzo wrote: > Index: disks/chapter.sgml > =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 > RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgm= l,v > retrieving revision 1.302 > diff -u -r1.302 chapter.sgml > --- disks/chapter.sgml 30 Dec 2010 00:41:40 -0000 1.302 > +++ disks/chapter.sgml 27 Feb 2011 10:23:42 -0000 > @@ -3996,6 +3996,667 @@ > + > + Synopsis > + > + High-availability is one of the main requirements in serious > + business applications and highly available storage is a key > + component in such environments. HAST makes > + it together with other features of &os; which provide for > + high-availability, such as CARP, possible > + to build a highly available storage cluster resistant > + from the hardware failures. I'd suggest to rephrase this sentence to something like: | HAST, together with other &os; high-availability | features like CARP, makes it possible | to build a highly available storage cluster resistant to | hardware failures. > + Highly Available STorage, HAST in short, = was > + developed by &a.pjd; as a framework, which allows to > + transparently store the same data across several physically > + separated machines connected through the TCP/IP network. Maybe simply: | ... connected by TCP/IP. > + > + > + What HAST is, how it works and what > + features it provides. | ... which features ... > + > + Have a good understanding of the &os; networking > + (). The meaning of this sentence isn't entirely clear to me. Is there maybe a word missing at the end? > + The HAST project was sponsored by The > + &os; Foundation with the support from + > + > + File system agnostic, thus enabling a possibility to > + use any file system supported by &os;. s@enabling a possibility@allowing@ > + HAST operates synchronously on a block > + level, which makes it transparent for file systems and > + applications. HAST provides a regular GEOM > + providers in /dev/hast/ Either "provides a regular ... provider" or "provides regular ... providers= ". Should GEOM maybe link somewhere? > + directory for use by other tools and applications, thus there is This implies a differences between tools and applications that, at least to me, isn't obvious in this context. > + no difference between using HAST-provided > + device and raw disk, partition, etc. Maybe add some "a"s or make that "devices and raw disk, partitions,". > + Each write, delete or flush operation is send to local > + disk and to remote disk over TCP/IP connection. Each read > + operation is served from local disk, unless local disk is not I think there are a few "the"'s missing in the above paragraph. > + HAST tries to provide fast failure > + recovery. For this reason, it is very important to reduce > + synchronization time after node's outage. To provide fast | ... after a node's ... > + synchronization, HAST manages on-disk bitmap > + of dirty extents, from which only those are being synchronized > + during the regular synchronization (with an exception of the > + initial sync). I suggest: | HAST manages an on-disk bitmap | of dirty extents and only synchronizes those during | a regular synchronization (with the exception ... This still seems to imply that there is an irregular synchronization, too. Is that the initial synchronization? Maybe the sentence should simply stop after "those". I assume in case of the initial synchronization all extents are treated as dirty? > + There are many ways to handle synchronization. > + HAST implements several replication modes > + to handle different synchronization methods: I'm not sure the first sentence adds anything here. > + > + > + memsync: report write operation > + as completed when local write completes and when remote | ... the local write operation is finished | and when the remote ... (also in the next paragraphs) > + node acknowledges data arrival, but before actually > + storing the data. The data on remote node will be stored | ... on the remote node > + directly after sending acknowledgement. This mode is | ... sending the ... > + intended to reduce latency, but still provides a very good I think the "a" could be removed here. > + HAST requires > + GEOM_GATE support in order to function. > + The GENERIC kernel does > + not include GEOM_GATE > + by default, however the geom_gate.ko > + loadable module is available in the default &os; installation. > + For stripped-down systems, make sure to have this module | ... sure this module is ... > + available. Alternatively, it is possible to build > + GEOM_GATE support into the kernel > + statically, by adding the following line to the custom kernel I'd probably move the "statically" before "build". I haven't read the rest of the diff yet. Note that I'm not a native English speaker either. Thanks for working on this, Daniel. Fabian --Sig_/lReSWOG.c=OxhCd_mFceZ_K Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1qShQACgkQBYqIVf93VJ3mXgCgw1RGZhFd86nHGalf2/7znvFZ nVIAn2bgelDtIKqIgzxuiDPlL3JtJXZS =KyC+ -----END PGP SIGNATURE----- --Sig_/lReSWOG.c=OxhCd_mFceZ_K--