On Tue, 4 Dec 2012 12:12:23 +0900 Taejin Kim <taejin1999@xxxxxxxxxxxxxxxxx> wrote: > Dear Neil Brown, > > I'm Taejin Kim, Ph.D student at Seoul National Universtiy in Korea. > Recently, I got interested in RAID for flash memory and just started > studying about RAID. > > I have seen that there are considerable number of writes during > initialization of mdadm, reconstructing array from degraded status. > When I search for what mdadm does, I was able to find your article about > the RAID5 initialization of mdadm so I now understand what happens. > (http://marc.info/?l=linux-raid&m=112044009718483&w=2) > > However, I'm wondering why we need to make sure the parity blocks are all > correct even for a "new" RAID5 array. Because when a single block is updated, the raid5 module might use a read-modify-write cycle. i.e. - read old data and parity - subtract old data from parity, and add new data to parity - write new data and parity If the parity block wasn't correct before, then it won't be correct after. So we must make sure it is correct at the start. > In my point of view, there would be no meaningful data in a "new" drive so > we can write data and parity block from the beginning without having > consistent parity block calculated from meaningless data in a "new" drive. > > I could come up with one possible reason for the initialization, which is a > bad block management. > Is it correct to recognize bad blocks in each drive during initialization > by trying to write out parity blocks? > If not, would you explain the reason for this initialization? > > I'm also wondering if this process is necessary only for mdadm or for other > RAID tools, too. I believe most RAID implementations perform an initial sync. md doesn't current require it for other levels (just RAID5 and RAID4) as they don't do any read-modify-write. However it is possible that the implementation for RAID6 might change one day, so don't assume that --assume-clean is safe for RAID6 long-term. NeilBrown > > I would appreciate if you let me know above questions. It would be very > helpful for my research. > I'm looking forward to your reply. > Thank you. > > Sincerely. >
Attachment:
signature.asc
Description: PGP signature
