Any news on the HAST Project?

[Gary Jennejohn]

On Thu, 4 Feb 2010 22:05:22 +0100
Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:

> On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote:
> > 
> > On 28.01.2010, at 14:26, Hywel Mallett wrote:
> > 
> > > About the same time a status update was posted on the FreeBSD Foundation blog at http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html
> > 
> > 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 and distributing mass storage. I look forward to testing it first on a few vboxes and shortly thereafter on real machines. 
> > 
> > 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). 
> 
> 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 flexibility in creating primary/secondary volumes (zvols). Just imagining a scenario 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).
> 

I can testify to the benefits of SU+J.  I had two crashes on Wednesday
and SU+J recovered my file systems in seconds.  With fsck it would have
taken about 30 minutes.

---
Gary Jennejohn