On Sun, May 31, 2009 at 8:14 AM, NeilBrown <neilb@xxxxxxx> wrote: > 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, Is there likely to be any discussion of how trim / unmap will be invoked by the filesystem layer at OLS? Or how do those decisions get made? ie. The ext4 list was recently talking about sending down very small grained info, but large grained seems to make a lot more sense to me. Hopefully, each filesystem is not given the ability to decide for themselves. Very much seems like something the lk community should have input into, not just the ext4 maintainer. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- 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
