On Sun, May 31, 2009 9:54 pm, Goswin von Brederlow wrote: > SandeepKsinha <sandeepksinha@xxxxxxxxx> writes: > >> On Sun, May 31, 2009 at 1:07 AM, Redeeman <redeeman@xxxxxxxxxxx> wrote: >>> On Sat, 2009-05-30 at 20:55 +0200, Goswin von Brederlow wrote: >>>> And just when I hit send I thought of something else. >>>> >>>> Instead of the initial sync when creating a raid the bitmap could just >>>> mark all blocks as unused. Much faster raid creation. >>> >> >> >> This really sounds like a good option. This would have a slight hit >> for writes which I believe will compensate for later re-constructions, >> replacing a disk, mirror resysnc and many more operation. > > What hit? Currently with bitmap support a write will set the block to > "unclean", write the data, write the parity and set the block to > "clean". Setting the "used" bit along the way should not cost much. > > Only difference I see is that the bitmap would have to have finer > granularity so one "used" bit covers one filesystem block (4k usualy). > Otherwise you could only "use" blocks but not "unuse" them again when > the filesystem frees them in 4k chunks. But the filesystem could "unuse" blocks in larger chunks. There is this thing called "thin provisioning" and I believe the proponents of that would like the "TRIM" command to be sent in aligned multiples of 1Gigabyte or something like that. I believe this is one aspect of Linux TRIM support that is still open. I think there would be real value in providing an 'allocated' bitmap even if it were quite coarsely grained. The problem with a very large grain is that every time you set a bit, you need to resync that region, and you don't want that to take too long. So 1 gig (10-30seconds?) would be an upper limit I would thing. If you used 1 sector for the bitmap, that is 4096 bits so on a terabyte array, you have 256Meg chunks that resync in a few seconds. Certainly an interesting idea to experiment with I think. NeilBrown > >> Neil any comments on this? >> >> I mean, how difficult would it be to maintain such a bitmap. This can >> though of making something optional as this will incur space. >> >> >>> A filesystem-coexist mode could also do this, by simply refusing >>> operation until such a time that a filesystem is detected, or i suppose >>> in worst case, mounted... >> >> >>> >>>> >>>> MfG >>>> Goswin > > MfG > Goswin > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
