nice =) but check that parity block is a raid information, not a filesystem information for raid we could implement trim when possible (like swap) and implement a trim that we receive from filesystem, and send to all disks (if it´s a raid1 with mirrors, we should sent to all mirrors) i don´t know what trim do very well, but i think it´s a very big write with only some bits for example: set sector1='00000000000000000000000000000000000000000000000000' could be replace by: trim sector1 it´s faster for sata communication, and it´s a good information for hard disk (it can put a single '0' at the start of the sector and know that all sector is 0, if it try to read any information it can use internal memory (don´t read hard disk), if a write is done it should write 0000 to bits, and after after the write operation, but it´s internal function of hard disk/ssd, not a problem of md raid... md raid should need know how to optimize and use it =] ) 2011/2/9 Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>: >> ext4 send trim commands to device (disk/md raid/nbd) >> kernel swap send this commands (when possible) to device too >> for internal raid5 parity disk this could be done by md, for data >> disks this should be done by ext4 > > That's an interesting point. > > On which basis should a parity "block" get a TRIM? > > If you ask me, I think the complete TRIM story is, at > best, a temporary patch. > > IMHO the wear levelling should be handled by the filesystem > and, with awarness of this, by the underlining device drivers. > Reason is that the FS knows better what's going on with the > blocks and what will happen. > > bye, > > pg > >> >> the other question... about resync with only write what is different >> this is very good since write and read speed can be different for ssd >> (hd don´t have this 'problem') >> but i´m sure that just write what is diff is better than write all >> (ssd life will be bigger, hd maybe... i think that will be bigger too) >> >> >> 2011/2/9 Eric D. Mudama <edmudama@xxxxxxxxxxxxxxxx>: >> > On Wed, Feb 9 at 11:28, Scott E. Armitage wrote: >> >> >> >> Who sends this command? If md can assume that determinate mode is >> >> always set, then RAID 1 at least would remain consistent. For RAID 5, >> >> consistency of the parity information depends on the determinate >> >> pattern used and the number of disks. If you used determinate >> >> all-zero, then parity information would always be consistent, but this >> >> is probably not preferable since every TRIM command would incur an >> >> extra write for each bit in each page of the block. >> > >> > True, and there are several solutions. Maybe track space used via >> > some mechanism, such that when you trim you're only trimming the >> > entire stripe width so no parity is required for the trimmed regions. >> > Or, trust the drive's wear leveling and endurance rating, combined >> > with SMART data, to indicate when you need to replace the device >> > preemptive to eventual failure. >> > >> > It's not an unsolvable issue. If the RAID5 used distributed parity, >> > you could expect wear leveling to wear all the devices evenly, since >> > on average, the # of writes to all devices will be the same. Only a >> > RAID4 setup would see a lopsided amount of writes to a single device. >> > >> > --eric >> > >> > -- >> > Eric D. Mudama >> > edmudama@xxxxxxxxxxxxxxxx >> > >> > -- >> > 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 >> > >> >> >> >> -- >> Roberto Spadim >> Spadim Technology / SPAEmpresarial >> -- >> 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 > > -- > > piergiorgio > -- > 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 > -- Roberto Spadim Spadim Technology / SPAEmpresarial -- 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
