Date: Thu, 4 Feb 2010 22:05:22 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Lorenzo Perone <lopez.on.the.lists@yellowspace.net> Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? Message-ID: <20100204210522.GB1733@garage.freebsd.pl> In-Reply-To: <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote: >=20 > On 28.01.2010, at 14:26, Hywel Mallett wrote: >=20 > > About the same time a status update was posted on the FreeBSD Foundatio= n blog at http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-proj= ect.html >=20 > Thanx, also to pjd's answer. That gives some nice insight already. Great = work! HAST could in fact change radically the way of using block devices an= d distributing mass storage. I look forward to testing it first on a few vb= oxes and shortly thereafter on real machines.=20 >=20 > Really curious on how several things are implemented, e.g. performance / = latency / fail / sync issues (what happens for example when a big huge file= is written locally on a very fast primary, and there is not enough ram to = buffer it before sending it to a secondary.. etc, scenarios like that).=20 Every write request is handled synchronously by HAST. It is reported as completed only when it is stored on local and on remote node. > And how well it will do with ZFS too: although ZFS has its 'own' HAST via= send/recv (and besides might get its own implementation for some sort of '= streaming' send/recv..) it is also true that it'd allow for some great flex= ibility in creating primary/secondary volumes (zvols). Just imagining a sce= nario with sparse zvols and HAST disting them around.. ok ok I stop here :-) ZFS send/recv is something else. It can't work synchronously, where HAST works always that way. This means that when your primary node dies you won't lose even a single bit of data. Although be aware that file systems like UFS can be in inconsistent state after primary failure, so secondary node after switching to primary role has to check file system with fsck(8) before mounting it. This also makes ZFS great choice for running on HAST as 'zpool import' is very fast as oppose to fsck (at least until Jeff finish his SU+J project). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktrNpEACgkQForvXbEpPzQQEQCfdakqsJSq50R58VVjxZzSuTmf q94AoNijgS01r0mu9DlZZg1DbUdBCavb =DtXb -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100204210522.GB1733>