Linux kernel MD Source code Interpretation 11 raid5d

It was with the previous reading and writing base that we began to look at the RAID5D code. RAID5D is not a read-write entry, nor is it a place to read and write, but simply a transit point or a transport hub. The hub has a commanding position, like the U.S. base in Singapore, which directly controls the transport hubs in the Pacific and Indian Oceans.

 4626/* 4627 * This is RAID5 kernel thread. 
4628 * 4629 * We scan the hash table for stripes which can is handled now. 4630 * During the scan, completed stripes are for us by the saved interrupt * 4631, so that handler'll not they 
To the for our next wakeup.  
4632 */4633 static void raid5d (struct Mddev *mddev) 4634 {4635 struct r5conf *conf = mddev->private;  
4636 int handled;  
4637 struct Blk_plug plug;  
4638 4639 pr_debug ("+++ raid5d active\n");  
4640 4641 md_check_recovery (Mddev);  
4642 4643 Blk_start_plug (&plug);  
4644 handled = 0;  
4645 Spin_lock_irq (&conf->device_lock);  
4646 while (1) {4647 struct bio *bio;  
4648 int batch_size;                         4649 4650 if (4651!list_empty (&conf->bitmap_list)) {4652 /* Now are a good time to flush some bitmap updates * * 4653 conf->seq_flush++;  
4654 Spin_unlock_irq (&conf->device_lock);  
4655 Bitmap_unplug (MDDEV->BITMAP);  
4656 SPIN_LOCK_IRQ (&conf->device_lock);  
4657 Conf->seq_write = conf->seq_flush;  
4658 activate_bit_delay (conf); 4659} 

4641 lines, md_check_recovery This function has been seen before to check for triggering synchronization

4643 lines, Blk_start_plug and 4688 lines Blk_finish_plug are a pair for merging requests.

4646 lines, why do you want a big cycle here? It may be a bit confusing to start by looking at 4629 lines of comments, but seeing this loop tells us that this is the place, and 4629 lines of comments say we don't have to wait until the next wake-up RAID5 thread to continue processing stripes, because there may be stripes already processed in the interrupt handler function to return.

4651 rows to determine if the array corresponds to a bitmap_list, if the list is not empty, enter the branch. What does bitmap have to do with strip processing? This is a more historic issue. For the RAID5 array, the scariest thing to do is to lose power in the process of writing, which means the array doesn't know what data is consistent or inconsistent? This is what SafeMode does to record the consistency of the array data. However, the data inconsistency caused by the code is the overall synchronization, this is RAID5 the most headache problem. OK, now there are bitmap can solve this problem, too happy. How did the bitmap solve the problem? Bitmap said that when you write each tape, I will record it and finish it. If the abnormal power off, as long as the synchronous power off when the completion of the ribbon can be. Wahaha is too happy!!! But please do not be happy too early, bitmap is also not a good on the ye, bitmap must write the tape before writing completed, where the writing is to write through that is synchronous writing. This is a sad reminder, bitmap writing process is too slow, completely drag down the performance of the RAID5. So with this bitmap_list,raid5 said, bitmap brother you write in batches, a bit similar to the bio of the merger request. However, this can only partially compensate for the negative performance of bitmap.

4655 lines, issued bitmap bulk write request.
4657 lines, update the serial number of the bitmap bulk write request.

4658 lines, will wait for bitmap to write the strip issued.

4660 raid5_activate_delayed (conf);

4660 lines, look at the function name is the activation of the delay stripe meaning. So why delay the handling of the stripe? In accordance with the common means of block devices, deferred processing is to merge the request, here is the same reason. When will the strip be delayed? We follow up the raid5_activate_delayed function:

3691static void raid5_activate_delayed (struct r5conf *conf)  
3692{  
3693     if (atomic_read &conf-> Preread_active_stripes) < Io_threshold) {  
3694 while          (!list_empty (&conf->delayed_list)) {  
3695               struct List_head *l = conf->delayed_list.next;  
3696               struct stripe_head *sh;  
3697               sh = list_entry (l, struct stripe_head, LRU);  
3698               List_del_init (l);  
3699               clear_bit (stripe_delayed, &sh->state);  
3700               if (!test_and_set_bit (stripe_preread_active, &sh->state))  
3701                    atomic_inc (&conf- >preread_active_stripes);  
3702               list_add_tail (&SH->LRU, &conf->hold_list);  
3703          }  
3704     }  
3705}

3693 lines, here control the number of prefetching.

3694 rows, traversing array delay processing linked list

3695 line, get array delay processing linked table header

3697 rows, get the first stripe of the array delay processing list

3698 rows, remove a stripe from the array delay processing list

3700 lines, setting the read-only flag

3702 lines, adding to the pre-read list