Linux kernel MD Source code Interpretation 12 raid Read-write

As we all know, for a Linux block device, there is a corresponding request queue. The request registered on this request queue is the request entry for the block device. For raid, the allocation of struct Mddev is already set, and there is code in the function Md_alloc:

4846 blk_queue_make_request (Mddev->queue, md_make_request);  
4847 blk_set_stacking_limits (&mddev->queue->limits);

Although the national PM has maintained a steady growth, but it can not stop us from looking at the eye of the code, in thousands of lines of code we can still quickly find the raid read and write portal is md_make_request.

328/* rather than calling directly into the personality make_request function,  
329 * IO requests come At we can check if the device is  
being suspended pending a reconfiguration.  
331 * We hold a refcount over the call to->make_request.  By "Time"  
332 * Call has finished, the bio has been linked to some internal structure 333 * And so are  
vis Ible to->quiesce () and so we don ' t need the refcount any more.  
334 */

Before we call the Make_request function, we check to see if the device hangs because of reconfiguration. Before calling the Make_request function, we increase the reference count of the device, and then decrement it when the make_request call completes. Adding a device reference count is primarily to ensure that the IO that is sent to the device is completed before the->QUIESCE () is invoked.

 335static void md_make_request (struct request_queue *q, struct bio *bio) 336{337 const int RW = Bio_data_di  
R (bio);  
338 struct Mddev *mddev = q->queuedata;  
339 int CPU;  
unsigned int sectors; 341 342 if (Mddev = null | | mddev->pers = = NULL 343 | |!mddev->ready) {344 bio_io_error  
(bio);  
345 return; 346} 347 SMP_RMB ();  
/* Ensure implications of ' active ' are visible * * 348 rcu_read_lock ();  
349 if (mddev->suspended) {define_wait (__wait); 351 for (;;) {352 prepare_to_wait (&mddev->sb_wait, &__wait, 353 task_uninterrupti  
BLE);  
354 if (!mddev->suspended) 355 break;  
356 Rcu_read_unlock ();  
357 Schedule ();  
358 Rcu_read_lock ();  
359} 360 finish_wait (&mddev->sb_wait, &__wait);  
361}362 Atomic_inc (&MDDEV->ACTIVE_IO);  
363 Rcu_read_unlock ();     364 365/* 366 * Save the sectors now since we bio can 367 * go away inside make_request 368/369  
Sectors = Bio_sectors (bio);  
370 Mddev->pers->make_request (Mddev, bio);  
371 372 CPU = Part_stat_lock ();  
373 Part_stat_inc (CPU, &MDDEV->GENDISK->PART0, IOS[RW]);  
374 Part_stat_add (CPU, &mddev->gendisk->part0, SECTORS[RW), sectors);  
375 Part_stat_unlock (); 376 377 if (atomic_dec_and_test (&mddev->active_io) && mddev->suspended) 378 wake_up (&am  
p;mddev->sb_wait); 379} 

337 line, get IO direction, for device information statistics

338 rows, gets the array pointer, which is assigned in the Md_alloc.

342 lines, basic check

348 lines, access struct Mddev information plus RCU read lock

Line 349, array suspend

350 lines, if the array suspend, that is, in the previous comment is being reconfigured, join the sb_wait wait queue

360 lines, array complete suspend, removing from wait queue

362 lines, incrementing the array reference count, in the previous comment for a reason

370 lines, sending bio to array

372 lines, this start is information statistics

377 lines, descending the array reference count, waking the process if it is being reconfigured

The real Data Channel command is also 370 lines, the other is the control channel.

For the RAID5 array, this request function corresponds to the Make_request function in raid5.c: