vdo_get_page(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay so bestie, welcome to vdo_get_page(9) β€” the whole point is: initialize a page completion and get a block map page. That's the mission. That's the vibe. ✨

πŸ¦‹ SYNOPSIS πŸ¦‹

void vdo_get_page (struct vdo_page_completion *page_completion , struct
block_map_zone *zone , physical_block_number_t pbn , bool writable ,
void *parent , vdo_action_fn callback , vdo_action_fn error_handler ,
bool requeue );

No cap, that's the signature exactly. Keep it pristine. πŸ’…

🌸 ARGUMENTS 🌸

  • page_completion β€” the vdo_page_completion you're initializing. It's giving "blank form, please fill me in." πŸŽ€
  • zone β€” the block_map_zone of the page you want. Like, which zone is your page living in?
  • pbn β€” the absolute physical block of the page you want. Yes, the actual pbn, bestie. πŸ”₯
  • writable β€” whether the page can be modified. Yes or no, that's the whole question.
  • parent β€” the object to notify when the fetch is complete. It gets the little "hey, it's done" ping. 🫢
  • callback β€” the notification callback. The thing that does the notifying.
  • error_handler β€” the handler for fetch errors. Because sometimes the fetch says "not today." 😭
  • requeue β€” whether we must requeue when notifying the parent. Important little boolean, don't sleep on it.

πŸ”₯ DESCRIPTION πŸ”₯

Okay so here's the tea: this call may cause another page to be discarded β€” and yes, that can potentially write a dirty page 😭 β€” and then the page nominated by the completion gets loaded from disk. So it's a little chaotic, but it's doing the job.

When the callback is invoked, the page will be resident in the cache and marked busy. All callers must call vdo_release_page_completion when they're done with the page to clear the busy mark. That's a must, bestie. Not a maybe. Not a vibe. 🫢

Don't skip the release call β€” the busy mark is meant to be cleared with vdo_release_page_completion. That's literally the instruction. πŸ’…

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./drivers/md/dm-vdo/block-map.c, Block map eras(9), and the whole block-map bestie squad: initialize_info(9), allocate_cache_components(9), assert_on_cache_thread(9), get_page_state_name(9), update_counter(9), set_info_state(9), find_free_page(9), find_page(9), select_lru_page(9), complete_with_page(9), complete_waiter_with_error(9), complete_waiter_with_page(9), distribute_page_over_waitq(9), set_persistent_error(9), validate_completed_page(9), handle_load_error(9), page_is_loaded(9), handle_rebuild_read_error(9), launch_page_load(9), schedule_page_save(9), launch_page_save(9), completion_needs_page(9), allocate_free_page(9), discard_a_page(9), discard_page_if_needed(9), write_has_finished(9), handle_page_write_error(9), page_is_written_out(9), write_pages(9), vdo_release_page_completion(9), vdo_request_page_write(9), vdo_get_cached_page(9), vdo_invalidate_page_cache(9), get_tree_page_by_index(9), in_cyclic_range(9), is_not_older(9), add_to_dirty_lists(9), vdo_find_block_map_slot(9), make_forest(9), replace_forest(9), finish_cursor(9), continue_traversal(9), finish_traversal_load(9), traverse(9), launch_cursor(9), compute_boundary(9), vdo_traverse_forest(9), initialize_block_map_zone(9), clear_mapped_location(9), set_mapped_location(9).


so yeah: this page's source/version is ./drivers/md/dm-vdo, dated October 2026, and it's serving vdo_get_page(9) energy. periodt. πŸ’–βœ¨

πŸ“¦ where this page comes from