fs/btrfs/send.c
Source file repositories/reference/linux-study-clean/fs/btrfs/send.c
File Facts
- System
- Linux kernel
- Corpus path
fs/btrfs/send.c- Extension
.c- Size
- 222174 bytes
- Lines
- 8299
- Domain
- Core OS
- Bucket
- VFS And Filesystem Core
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/bsearch.hlinux/falloc.hlinux/fs.hlinux/file.hlinux/sort.hlinux/mount.hlinux/xattr.hlinux/posix_acl_xattr.hlinux/radix-tree.hlinux/vmalloc.hlinux/string.hlinux/compat.hlinux/crc32c.hlinux/fsverity.hlinux/cleanup.hsend.hctree.hbackref.hlocking.hdisk-io.hbtrfs_inode.htransaction.hcompression.hprint-tree.haccessors.hdir-item.hfile-item.hioctl.hverity.hlru_cache.h
Detected Declarations
struct __fs_pathstruct fs_pathstruct __fs_pathstruct clone_rootstruct backref_cache_entrystruct send_ctxstruct pending_dir_movestruct waiting_dir_movestruct orphan_dir_infostruct name_cache_entrystruct btrfs_inode_infostruct backref_ctxstruct recorded_refstruct find_xattr_ctxenum btrfs_compare_tree_resultenum inode_statefunction inconsistent_snapshot_errorfunction proto_cmd_okfunction need_send_holefunction fs_path_resetfunction init_pathfunction fs_path_freefunction fs_path_lenfunction fs_path_ensure_buffunction fs_path_prepare_for_addfunction fs_path_addfunction fs_path_add_pathfunction fs_path_add_from_extent_bufferfunction fs_path_copyfunction fs_path_unreversefunction is_current_inode_pathfunction write_buffunction tlv_putfunction tlv_put_stringfunction tlv_put_uuidfunction tlv_put_btrfs_timespecfunction send_headerfunction begin_cmdfunction send_cmdfunction send_renamefunction send_linkfunction send_unlinkfunction send_rmdirfunction get_inode_infofunction get_inode_genfunction iterate_inode_reffunction iterate_dir_itemfunction __copy_first_ref
Annotated Snippet
struct __fs_path {
char *start;
char *end;
char *buf;
unsigned short buf_len:15;
unsigned short reversed:1;
};
static_assert(sizeof(struct __fs_path) < 256);
struct fs_path {
struct __fs_path;
/*
* Average path length does not exceed 200 bytes, we'll have
* better packing in the slab and higher chance to satisfy
* an allocation later during send.
*/
char inline_buf[256 - sizeof(struct __fs_path)];
};
#define FS_PATH_INLINE_SIZE \
sizeof_field(struct fs_path, inline_buf)
static void fs_path_free(struct fs_path *p);
DEFINE_FREE(fs_path_free, struct fs_path *, fs_path_free(_T))
/* reused for each extent */
struct clone_root {
struct btrfs_root *root;
u64 ino;
u64 offset;
u64 num_bytes;
bool found_ref;
};
#define SEND_MAX_NAME_CACHE_SIZE 256
/*
* Limit the root_ids array of struct backref_cache_entry to 17 elements.
* This makes the size of a cache entry to be exactly 192 bytes on x86_64, which
* can be satisfied from the kmalloc-192 slab, without wasting any space.
* The most common case is to have a single root for cloning, which corresponds
* to the send root. Having the user specify more than 16 clone roots is not
* common, and in such rare cases we simply don't use caching if the number of
* cloning roots that lead down to a leaf is more than 17.
*/
#define SEND_MAX_BACKREF_CACHE_ROOTS 17
/*
* Max number of entries in the cache.
* With SEND_MAX_BACKREF_CACHE_ROOTS as 17, the size in bytes, excluding
* maple tree's internal nodes, is 24K.
*/
#define SEND_MAX_BACKREF_CACHE_SIZE 128
/*
* A backref cache entry maps a leaf to a list of IDs of roots from which the
* leaf is accessible and we can use for clone operations.
* With SEND_MAX_BACKREF_CACHE_ROOTS as 12, each cache entry is 128 bytes (on
* x86_64).
*/
struct backref_cache_entry {
struct btrfs_lru_cache_entry entry;
u64 root_ids[SEND_MAX_BACKREF_CACHE_ROOTS];
/* Number of valid elements in the root_ids array. */
int num_roots;
};
/* See the comment at lru_cache.h about struct btrfs_lru_cache_entry. */
static_assert(offsetof(struct backref_cache_entry, entry) == 0);
/*
* Max number of entries in the cache that stores directories that were already
* created. The cache uses raw struct btrfs_lru_cache_entry entries, so it uses
* at most 4096 bytes - sizeof(struct btrfs_lru_cache_entry) is 48 bytes, but
* the kmalloc-64 slab is used, so we get 4096 bytes (64 bytes * 64).
*/
#define SEND_MAX_DIR_CREATED_CACHE_SIZE 64
/*
* Max number of entries in the cache that stores directories that were already
* created. The cache uses raw struct btrfs_lru_cache_entry entries, so it uses
* at most 4096 bytes - sizeof(struct btrfs_lru_cache_entry) is 48 bytes, but
* the kmalloc-64 slab is used, so we get 4096 bytes (64 bytes * 64).
*/
#define SEND_MAX_DIR_UTIMES_CACHE_SIZE 64
struct send_ctx {
struct file *send_filp;
loff_t send_off;
char *send_buf;
u32 send_size;
Annotation
- Immediate include surface: `linux/bsearch.h`, `linux/falloc.h`, `linux/fs.h`, `linux/file.h`, `linux/sort.h`, `linux/mount.h`, `linux/xattr.h`, `linux/posix_acl_xattr.h`.
- Detected declarations: `struct __fs_path`, `struct fs_path`, `struct __fs_path`, `struct clone_root`, `struct backref_cache_entry`, `struct send_ctx`, `struct pending_dir_move`, `struct waiting_dir_move`, `struct orphan_dir_info`, `struct name_cache_entry`.
- Atlas domain: Core OS / VFS And Filesystem Core.
- Implementation status: source implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.