Date: Fri, 5 Feb 2010 20:51:15 +0100 From: Lorenzo Perone <lopez.on.the.lists@yellowspace.net> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? Message-ID: <25CA86F9-4B63-44FE-8A03-855DC1D4DF60@yellowspace.net> In-Reply-To: <20100204210522.GB1733@garage.freebsd.pl> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> <20100204210522.GB1733@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04.02.2010, at 22:05, Pawel Jakub Dawidek wrote: > Every write request is handled synchronously by HAST. It is reported as > completed only when it is stored on local and on remote node. That's great for state - yet it also means that it won't be suitable for some scenarios - such as secondaries connected over slow links or with noticeably slower media. While I sort of imagine some of the tricky, messy implications of an aynchronous implementation, I was hoping for it somehow. That doesn't make HAST less magic - it just shifts its use to different scenarios than some I originally imagined, were it was something more similar to what dfly's is doing with hammer mirror-stream - but at a filesystem-agnostic level (wonder if that's even possible in theory).. > 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). This sounds like great marriage. Could latency be further enhanced by HASTing the pool geoms and using an 'unHASTed' device as ZIL device, in theory (as soon as that's possible)? Thanx a lot! Regards, Lorenzo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25CA86F9-4B63-44FE-8A03-855DC1D4DF60>