On Wed, 17 Apr 2013 12:29:07 +0800 Robin Dong <robin.k.dong@xxxxxxxxx> wrote: > 2013/4/17 Robin Hill <robin@xxxxxxxxxxxxxxx> > > > > On Tue Apr 16, 2013 at 05:46:07PM +0200, Roy Sigurd Karlsbakk wrote: > > > > > > > Is there any method to just resync WRITTEN data to new-added-disk ? > > > > > Or any developing plan to add this feature? > > > > > > > > No, because md is a block device it has no knowledge of what data has > > > > actually been written to the disk or where it is stored. This means it > > > > has to rebuild the entire disk. > > > > > > > > There are plans to improve this by keeping track of which stripes have > > > > been written to, which should help (and will also mean no need for an > > > > initial RAID sync). I don't know whether this has progressed beyond > > > > the idea stage yet though. > > > > > > Interesting - do you have any docs about this? I haven't seen any talk > > > on this list about it... > > > > > It's from Neil's 2011 MD/RAID roadmap: > > http://neil.brown.name/blog/20110216044002 > > > > The basic idea was mentioned in a 2009 roadmap as well, but is a lot > > more fleshed out in the above one. > > > Hi, Neil > > Has anyone began to develope non-sync-bitmap feature? If not, I want to > take a chance. > Will the non-sync-bitmap be built on the write-intent-bitmap or I need to > create a new bitmap in 'array state info' of v1.x metadata? > Hi Robin et al, No, no implementation has been started. You cannot use the same bits as the write intent bitmap as they mean something different. But you could possibly use the same storage space. i.e. have an alternate style of bitmap where there are two bits per 'chunk'. One bit maps "this was written recently, a resync might be needed after a crash" and the other means "This has been written since array create, so the chunk needs to be recovered to any spare". I don't know if this is the best approach - I haven't really thought about it much. There are several parts to this: 1/ decide how to store the new bitmap on disk, and implement that 2/ decide how to store the new bitmap in memory and implement that. It might be the same... 3/ Set a bit in the new bitmap on each write (if it isn't set), and trigger a resync of that chunk. 4/ Update the recovery process for each level to honour this new bit 5/ Allow "discard" operations to clear these bits. If you do proceed with this, feel free to post a more concrete design before proceeding to code - or just post code if you prefer. NeilBrown
Attachment:
signature.asc
Description: PGP signature
