struct bio: la unidad de E/S de bloques

Si el block layer es una fábrica que reescribe la E/S, la struct bio es la pieza que entra por la cinta. Es la descripción completa y autosuficiente de una transferencia: a qué sector del dispositivo, en qué dirección, y desde qué páginas de memoria física. No copia datos ni los toca; solo los señala. Esa indirección —una bio es un mapa, no una carga— es lo que permite al kernel fusionarla, trocearla, encolarla y completarla sin mover un solo byte hasta el último instante. Entender sus campos es entender el vocabulario en el que se dice absolutamente toda la E/S de bloques del sistema.

Anatomía de una bio

Una bio reúne cuatro clases de información: a dónde va en el dispositivo, qué operación es, de qué memoria sale o entra, y a quién avisar al terminar. En el Linux de 2026 su forma esencial es esta:

struct bio {
	struct bio          *bi_next;      /* enlace en la request que la agrupa */
	struct block_device *bi_bdev;      /* el dispositivo destino */
	blk_opf_t            bi_opf;        /* operacion (bits bajos) + banderas (altos) */
	unsigned short       bi_flags;
	blk_status_t         bi_status;     /* resultado, al completarse */
	struct bvec_iter     bi_iter;       /* sector + cuanto queda por transferir */
	bio_end_io_t        *bi_end_io;     /* callback de completado */
	void                *bi_private;    /* dato opaco del emisor */
	unsigned short       bi_vcnt;       /* cuantos bio_vec hay poblados */
	unsigned short       bi_max_vecs;   /* capacidad del arreglo */
	struct bio_vec      *bi_io_vec;     /* el arreglo de segmentos */
	atomic_t             __bi_cnt;      /* cuenta de referencias */
	struct bio_vec       bi_inline_vecs[]; /* vecs pequenos, en linea */
};

Dos campos merecen detenerse. bi_opf empaqueta en un solo blk_opf_t la operación en los bits bajos —REQ_OP_READ, REQ_OP_WRITE, REQ_OP_FLUSH, REQ_OP_DISCARD— y las banderas de modificador en los altos —REQ_SYNC, REQ_FUA, REQ_META—. Se lee con los accesores bio_op(bio) y bio_data_dir(bio), nunca comparando a mano. Y bi_end_io es el pilar de la asincronía: la bio no se espera, se entrega; cuando el hardware termina, el block layer invoca ese callback, que es donde el emisor recoge el resultado en bi_status.

bi_iter y bio_vec: dónde en el disco, dónde en la RAM

La transferencia tiene dos extremos. El del dispositivo lo fija bi_iter, un iterador que además avanza a medida que la bio se consume:

struct bvec_iter {
	sector_t     bi_sector;     /* sector inicial, en unidades de 512 B */
	unsigned int bi_size;       /* bytes que quedan por transferir */
	unsigned int bi_idx;        /* indice del bio_vec actual */
	unsigned int bi_bvec_done;  /* bytes ya hechos dentro del vec actual */
};

El extremo de la memoria lo describe el arreglo bi_io_vec, cuyos elementos son bio_vec: cada uno señala una página física con su desplazamiento y longitud. Una transferencia no tiene por qué salir de memoria contigua; puede reunir trozos dispersos, y por eso es un vector de segmentos, no un puntero único.

struct bio_vec {
	struct page *bv_page;    /* la pagina fisica */
	unsigned int bv_len;     /* cuantos bytes desde el offset */
	unsigned int bv_offset;  /* offset dentro de la pagina */
};

Construir y recorrer una bio

Crear una bio en un driver o un filesystem sigue un patrón fijo: asignar, apuntar al sector, añadir páginas, fijar el callback y entregar. La firma moderna de bio_alloc recibe ya el dispositivo y la operación en el momento de asignar:

struct bio *bio = bio_alloc(bdev, 1, REQ_OP_READ, GFP_KERNEL);
if (!bio)
	return -ENOMEM;

bio->bi_iter.bi_sector = sector;             /* a que sector del disco */
bio_add_page(bio, page, PAGE_SIZE, 0);       /* de que pagina de RAM */
bio->bi_end_io = mi_endio;                   /* a quien avisar al terminar */
bio->bi_private = ctx;                        /* mi contexto para recuperarlo */
submit_bio(bio);                              /* lo entrego: no bloquea */

bio_add_page respeta los límites del dispositivo (max_segments, max_hw_sectors) y devuelve cuántos bytes admitió; si no cabe todo, se encadena otra bio. Del lado del que consume —el driver, o el propio block layer al fusionar— el recorrido es simétrico:

struct bio_vec bv;
struct bvec_iter iter;

bio_for_each_segment(bv, bio, iter) {
	void *buf = bvec_kmap_local(&bv);        /* mapea el segmento */
	/* ... tocar bv.bv_len bytes del dispositivo hacia/desde buf ... */
	kunmap_local(buf);
}

Encadenar: cuando una bio no basta

Una bio tiene un tope de tamaño impuesto por el hardware y por su número de segmentos. Cuando una operación lógica excede ese tope —leer 8 MiB de golpe—, no se agranda la bio: se encadenan varias con bio_chain, formando un árbol de padre e hijas donde la del padre solo se completa cuando todas las hijas lo han hecho. El contador atómico __bi_remaining sostiene esa espera sin bloqueo.

struct bio *hija = bio_alloc(bdev, nr, REQ_OP_READ, GFP_KERNEL);
bio_chain(hija, padre);   /* el completado de hija cuenta hacia el de padre */
submit_bio(hija);
/* padre->bi_end_io no correra hasta que todas sus hijas terminen */

El propio block layer usa este mecanismo al trocear (bio_split) una bio demasiado grande para el dispositivo: parte un trozo que sí cabe, lo encadena al original, y repite. El emisor pidió una transferencia; el hardware ve varias; y el callback original solo se dispara cuando el conjunto está completo. Toda esa contabilidad ocurre sin que ni el filesystem de arriba ni el driver de abajo tengan que enterarse.

flowchart LR
BIO[struct bio] --> ITER[bi_iter sector y tamano residual]
BIO --> OPF[bi_opf operacion y banderas]
BIO --> VEC[bi_io_vec arreglo de segmentos]
VEC --> BV0[bio_vec 0]
VEC --> BV1[bio_vec 1]
BV0 --> P0[pagina fisica mas offset mas len]
BV1 --> P1[pagina fisica mas offset mas len]
BIO --> END[bi_end_io callback de completado]
BIO --> NEXT[bi_next hacia la request o la cadena]
style BIO fill:#89b4fa,color:#11111b
style VEC fill:#f9e2af,color:#11111b
style END fill:#a6e3a1,color:#11111b