: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
          generated.

        * 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).

                                        -Matt
                                        Matthew Dillon 
                                        <[email protected]>

Reply via email to