On Sun, May 31, 2009 at 12:24 AM, Goswin von Brederlow <goswin-v-b@xxxxxx> wrote: > Redeeman <redeeman@xxxxxxxxxxx> writes: > >> On Sat, 2009-05-30 at 14:35 +0100, John Robinson wrote: >>> On 30/05/2009 06:44, SandeepKsinha wrote: >>> > Hi all, >>> > >>> > Say If I have a RAID 5 array of 50GB of five disks of 10GB each. >>> > >>> > I have data of 5GB. When a disk fails and replaced with a spare disk. >>> > Will the reconstruction happen only for the 5GB allocated disk blocks >>> > or it will happen for the whole disk size. >>> >>> The whole disc size, for now anyway; md does not currently note which >>> blocks have been used by its client (the filesystem, LVM, whatever). >>> >>> > Is it possible to make reconstruction intelligent enough to keep it optimized ? >>> >>> This has been discussed in combination with supporting SSD drives' TRIM >>> function, and would mean md had to keep track of used chunks or possibly >>> even sectors using a bitmap or something like that, but whether anyone's >>> working on it I don't know. >> >> I would say it should be possible to 'query' the filesystem for that >> information. Obviously this will only work if you run a filesystem on it >> which supports it, but it would seem like a nicer solution than a bitmap >> for it. > You have put a big constraint here of "filesystem which supports it". In general, I have not known any file system work as yet which leverages the underlying device topology to optimize its block allocation policies for enhaced I/O, etc. Or for any other reasons. Having a bitmap can surely have lot of other benefits too. Looking at the drive sizes in recent times, think of situation where you have to do a reconstruction or resysnc. It might take months for them to complete. Also, in the meanwhile you will have degraded I/O's. Just in worst case, if your drive has most of allocated blocks, it will be a penalty. > On the other hand checking a bitmap is quick. You could use the bitmap > not only for reconstruction but also for reads. If the bitmap say the > block is unused you can skip the read and just zero fill the > buffer. This would speed up reads and writes that don't cover the full > stripe. And compared to a raid with current bitmap there shouldn't be > any real slowdown for the extra "unused" bit. > > The only special case for resync would be that if all data blocks in a > stripe are unused then the parity blocks can be marked unused too. > > MfG > Goswin > -- Regards, Sandeep. “To learn is to change. Education is a process that changes the learner.” -- 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
