initial block allocation pushed

Zach Brown <[email protected]> Wed, 11 Mar 2026 12:11:36 -0700
Newsgroups dev.linux.lists.rpdfs-devel
Message-ID <[email protected]>
I just landed the initial implementation of block allocation.  The
quickest operational summary is:

 - devd now requires -n <total> and -p <pos> for its place amongst devds
 - hard disk and net format break, don't mix new/old and reformat devs
 - mount can now talk to multiple devds with -o devd_addr=addr:port

Allocation is now derived from block metadata in the devds.  It should
now be possible to mount and write without the goofy internal free block
number hack in each mount resetting and clobbering previous allocations.

While it seems to work well enough, I'm sure there's bugs and weird
corners.  As ever, keep an eye out.

The gory details are always in the commits and I'll share some quick
commentary:

Zach Brown (18):
      Add lk _le bitop variants
      Simplify compatible_modes
      Comment updates
      Track client cache modes in an rbtree
      Add devd free-map
      Add alloc_ctr to block details and over the wire
      Add free_stripe request message
      Have devd track free blocks per detail block
      Remove the summary_tree
      Have devd track cached blocks per stripe
      Add bstore_get_free_details()
      Add cache_mode_grant_bulk_uncached()
      Add free_stripe_request processing
      Add devd options for free stripe init
      Clamp devd storage blocks to details count
      Handle requests for lower mode than granted
      Have devd map its fs bnrs to contig lbas
      Show more details in format device output

Over in devd, it's all about handling the new _FREE_STRIPE_REQUEST
message.  In the block store we change the summary blocks so that their
entries can track the number of free blocks in stripes.  The cache-mode
engine is reworked so it's easier to grant a contiguous region of
uncached blocks to a client.  With those together we can quickly grant
write mode to regions of free blocks to clients in response to their
free stripe requests.

Zach Brown (9):
      rpdfs: Add ht rcu hash table entry helper
      rpdfs: share while_read_seqretry macro
      rpdfs: Add rpdfs_map_alloc_stripe_geom
      rpdfs: Add free stripe request and grant messages
      rpdfs: Add block alloc core
      rpdfs: Add block allocation to the block cache
      rpdfs: Add block allocation to transactions
      rpdfs: update alloc callers to txn from balloc
      rpdfs: Add a devd_addr mount option

In the kernel client the changes establish the pipeline of requests for
free blocks, the arrival of free stripes, and the combination of the
incoming free stripes into free regions.  Transaction callers have the
block cache send requests and assemble regions, the block cache combines
the incoming stripes into contigious regions, and finally hands the
regions off to the block alloc core which works with transactions to
perform allocations.

Happy hacking!

- z