sys/vfs/hammer2: Remove unused (add used) header includes

kernel: Remove <sys/n{amei,lookup}.h> from all files that don't need it.

hammer2 - More involved refactoring of chain_repparent, cleanup

* Remove unused locking flags (remove the NOLOCK and NOUNLOCK
features).

* Add HAMMER2_RESOLVE_NONBLOCK to hammer2_chain_lock() for

hammer2 - More involved refactoring of chain_repparent, cleanup

* Remove unused locking flags (remove the NOLOCK and NOUNLOCK
features).

* Add HAMMER2_RESOLVE_NONBLOCK to hammer2_chain_lock() for use
only by hammer2_chain_getparent() and hammer2_chain_repparent().

* Refactor hammer2_chain_getparent() and hammer2_chain_repparent().
Add a hot-path that uses HAMMER2_RESOLVE_NONBLOCK. If this fails
we now do a much more involved tracking operation via 'reptrack'
to deal with races against indirect block deletions.

* Cleanup the copyright messages.

* Fix an issue where a sync could be held-up indefinitely by
ongoing overlapping modifying operations.

* Install a proper initial inode count when creating a snapshot.

* Fix a deadlock in checkdirempty(). A chain lock was winding
up being ordered incorrectly.

show more ...

hammer2 - Refactor flush mechanics

* Greatly simplify and reduce special cases in the flush code

* Remove the multi-layer rbtree and replace with two discrete rbtree's
(rbtree and dbtree) represe

hammer2 - Refactor flush mechanics

* Greatly simplify and reduce special cases in the flush code

* Remove the multi-layer rbtree and replace with two discrete rbtree's
(rbtree and dbtree) representing the live state and one linked list (dbq)
representing set-aside deleted chains that are not part of the live state.

* Cleanup some debugging junk, add more debugging junk.

* Separate flushing state flags and TIDs into their own fields instead of
trying to use the live state flags and bref TIDs.

* Simplify transaction TID tracking.

show more ...

hammer2 - Major restructuring, part 1/several

* This breaks a lot of things. The next few commits will get it all
working again.

* Significantly rework the data structures. Instead of embedding

hammer2 - Major restructuring, part 1/several

* This breaks a lot of things. The next few commits will get it all
working again.

* Significantly rework the data structures. Instead of embedding the
RBTREE for a chain's children in the chain, the chain instead points
to a secondary structure containing the RBTREE.

Chains can no longer be moved within the in-memory topology. That is,
if a file is renamed or a block is resized or a block is moved into or
out of an indirect block, the in-memory chain representing that block
is NOT moved. Instead, the in-memory chain is marked deleted and a
copy is created at the new location. Both the old and the new chain
reference the same secondary structure and thus share the same RBTREE,
and reference the same media storage.

In addition, chain->duplink points from the deleted chain to its relocated
copy and maintains a reference on the target until the deleted chain is
deallocated. It is possible for the linked list to span more than one
element.

This link will soon be used to retarget inode->chain pointers (which can
wind up pointing to stale data) and also eventually effect chain->parent
traversals (real parent becomes chain->parent->[duplink*]). A rethink
might be needed down the line.

* This will allow the flush code to run 100% asynchronous from the
frontend and still be able to flush to a synchronization point no
matter how complex a set of changes have occured to the filesystem
concurrent to the flush (but after its synchronization point).

* The change also stabilizes chain->parent, which simplifies quite a bit
of code.

* Simplify nearly all the hammer2_chain_*() API functions, and other
functions.

* Add a hammer2_trans (transaction) structure to keep track of modifying
transactions. This will be flushed out later and used to detect flush
synchronization points. It currently contains the transaction id.

* Start adding API infrastructure and start reworking the flush and other
tree-modifying code to work under the new abstraction.

show more ...

hammer2 - dmsg blockdev work (cleanup)

* Cleanup

hammer2 - Messaging layer separation work part 3

* Move more hammer2 vfs message code into kern_dmsg.c, renaming and
implementing callbacks as needed.

* Move hammer2_icrc.c (the iscsi crc support

hammer2 - Messaging layer separation work part 3

* Move more hammer2 vfs message code into kern_dmsg.c, renaming and
implementing callbacks as needed.

* Move hammer2_icrc.c (the iscsi crc support) to libkern/icrc32.c

show more ...

hammer2 - Messaging layer separation work part 1

This work is to separate the network messaging format and various
lower layers out from hammer2 and into their own 'dmsg*' files.

* Factor low level

hammer2 - Messaging layer separation work part 1

This work is to separate the network messaging format and various
lower layers out from hammer2 and into their own 'dmsg*' files.

* Factor low level messaging structures into sys/dmsg.h

* Rename HAMMER2 -> DMSG.

show more ...

hammer2 - Message routing work

* Further API simplification

* Start adding router infrastructure to the kernel VFS

* Looks like we will need a 'source' and 'target' field in
the message header a

hammer2 - Message routing work

* Further API simplification

* Start adding router infrastructure to the kernel VFS

* Looks like we will need a 'source' and 'target' field in
the message header after all (replaces the single 'spanid' field),
in order to track the reply VC as a message is relayed.

show more ...

hammer2 - userland API / span work

* Fix a stall bug in the streaming write code

* Add some pretty-printing support for debug output. Also remove
a ton of debug messages.

* Add a remote shell '

hammer2 - userland API / span work

* Fix a stall bug in the streaming write code

* Add some pretty-printing support for debug output. Also remove
a ton of debug messages.

* Add a remote shell 'tree' command to dump the spanning tree.

* Cleanup some of the state handling and error codes.

show more ...

hammer2 - Flesh out span code, API cleanups

* Cleanup the transactional APIs and add a few functions to help with
simple (error code only) message replies.

* Better message protocol layering for

hammer2 - Flesh out span code, API cleanups

* Cleanup the transactional APIs and add a few functions to help with
simple (error code only) message replies.

* Better message protocol layering for both the kernel and userland code.

* Kernel now opens a LNK_CONN transaction which will enable the SPAN
protocol on the link and also serve to install a PFS filter (which is
not yet implemented).

Upon success the kernel then initiates the SPAN.

Basically for the kernel:

send LNK_CONN
wait for streaming reply (transaction remains open on both sides)
send LNK_SPAN

TODO: Receive/track LNK_SPANs, each representing a virtual circuit.

TODO: Track LNK_SPANs that match our PFS.

TODO: Issue higher level protocol transaction messages over these
circuits based on VNOPS, caching, mirroring, etc.
(transactional failures can occur when the LNK_SPAN state
changes, forcing a retry, etc).

* Userland now accepts the LNK_CONN and uses the open transaction to
install tracking structures for those connections participating in
the SPAN protocol.

* Userland now installs tracking structures for received SPAN messages.

* Start fleshing out the userland side of the SPAN relay/transmit code.
This will involve yet more structures to track which SPANs are being
relayed over each connection, so changes can be propagated (not yet
implemented).

For userland the TODO is very large so no point iterating it here.

* Kernel now accepts DBG_SHELL replies (basically debug output messages)
and will kprintf() them. DBG_SHELL commands not yet accepted by the
kernel.

show more ...

hammer2 - Implement and test first SPAN message transaction.

* The hammer2 VFS now sends a dummy SPAN message to the hammer2 service
daemon. SPANs are used to register capabilities (primarily PFS

hammer2 - Implement and test first SPAN message transaction.

* The hammer2 VFS now sends a dummy SPAN message to the hammer2 service
daemon. SPANs are used to register capabilities (primarily PFS services
and PFS consumers). SPAN messages are left as open transactions for the
duration of the link and/or when the graph changes (mainly a spanning
tree mechanic that will be coded as a function of the hammer2 service
daemon in userland.

* Basic open transaction and simple reply message tested. Use a dummy
message for testing.

* hammer2_msg_write() detects CREATE, allocates state, and assigns a
msgid. state allocation moved out of hammer2_state_msgtx() and
into hammer2_msg_write() so we can calculate the proper CRCs.

* Fixed a couple of expected bugs. The userland code was swapping
msg_hdr.source and msg_hdr.target in the reply, but I adjusted the
message spec to NOT do that (meaning any message routing has to select
{source} or {target} based on whether the REPLY bit is set or not.

* Memory seems to get cleaned up properly, so far.

show more ...