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