When hammer2 will be ready for use?

Matthew Dillon dillon at apollo.backplane.com
Mon Nov 11 12:17:16 PST 2013

:Dillon? Is there a date for hammer be ready for use?

    Not for a while.  Work is progressing but there are still a bunch of
    steps that have to be completed before it will be usable even as a
    single-media filesystem.

    I had hoped to have a single-media Hammer2 working by the end of this
    year but it isn't going to happen.  There will be too many interruptions
    from the holidays through January.  I think single-media had better be
    operational by the summer release, and multi-media clustering at some
    point after that.

    Recent progress:

	* Block allocator stabilized.  Allocates but can't free yet.

	* Keys in the block table(s) are now sorted (a necessary precursor
	  to implementing basic clustering functions because lookup/scan
	  cursors can now be represented simply with a single key value).

	* Internal structures reworked to support a clustering abstraction
	  later on (basically things like associating inodes with PFSs instead
	  of with HMPs.. with the meta-mount (hammer2_pfsmount structure)
	  internal to Hammer2 instead of with the device mount (hammer2_mount)
	  structure.  i.e. because future clustering work will obviously
	  be working with one set of inodes represented across multiple
	  device mounts.

	* Concurrent flush + front-end-modifying-operations now stable.
	  This was a really difficult one.

	* Block compression GSOC project was completed and is stable.  This
	  involved a lot of reworking of the write-IO infrastructure.

	* Snapshoting basically works.

	* Boot support (for testing only atm).

    Upcoming work:

	* The block freeing code.  At the very least a bulk scan is needed
	  to implement freeing blocks.

	* Crash stability.  Right now the allocation table on-media is not
	  properly synchronized with the flush.  This needs to be adjusted
	  such that H2 can do an incremental scan on mount to fixup
	  allocations on mount as part of its crash recovery mechanism.

	* We actually have to start checking and acting upon the CRCs being

	* Remaining known hardlink issues need to be addressed.

	* Core 'copies' mechanism needs to be implemented to support multiple
	  copies on the same media.

	* Core clustering mechanism needs to be implemented to support
	  mirroring and basic multi-master operation from a single host
	  (multi-host requires additional network protocols and won't
	  be as easy).

					Matthew Dillon 
					<dillon at backplane.com>

More information about the Users mailing list