getting off topic... ---- they have - reallocation > Bad blocks are only reallocated when you write to them. Since they are bad, > you can't read the previous contents anyway, so it does not matter whether > the OS cared about it before or not. when you write, if bad, mark block as bad. how? internal disk memory, spare blocks. it's a device level problem, if device can't correct move the problem to filesystem level. what device level could do? use a 'good block' (if exists) => dynamic reallocation 'good block' = block not in use by filesystem, not marked as bad, can be used by realloc with trim, you can inform device firmware what blocks are not in use by filesystem, if harddisk have reallocation it can use 'good blocks' to store blocks that was realloc on badblock errors. why implement it? if you have 11111filesystems mounted with bad blocks at same time you will have >=11111 iops to repair this error at filesystem level. if device can correct you don't need to waste cpu and memory at filesystem ------ any layer between ATA and [plate,NAND flash,NOR flash] can be implemented by harddisk/ssd firmware some layers that can be implemented: online reallocation, queue, online encrypt/decrypt, online compress/decompress and others, some ssd have optimizations to get better life time and write/read performace how to 'tune' these algorithms? ATA commands, SCSI or anyother protocol that support tune why trim? inform harddisk/ssd what block isn't in use what harddisk/ssd could do with trim information? dynamic reallocation (badblocks), any other operation that need not used blocks (some algorithms use it to get better read/write performace) on devices with byte read/write level (NAND flash) we could write to one timmed block without reading the block and write again, NOR flash and harddisk don't need this they work with bits not bytes/blocks why send a error to filesystem if it can be corrected at device level. just send error when can't correct it. 2011/2/21 Phillip Susi <psusi@xxxxxxxxxx>: > On 02/21/2011 08:55 PM, Roberto Spadim wrote: >> >> it can be used for badblock reallocation if harddisk have it >> a harddisk is near to NOR ssd with variable accesstime, if head is >> near sector to be read/write accesstime is small, if sector is far >> from head, access time increase (normaly<=1 disk revolution if head >> control system is good, for 7200rpm 1revolution is near to 8.33ms) > > Bad blocks are only reallocated when you write to them. Since they are bad, > you can't read the previous contents anyway, so it does not matter whether > the OS cared about it before or not. > > You seem to not understand the fundamental purpose of TRIM. Hard disks only > reallocate blocks when they go bad. SSDs move blocks around all the time. > That process can be optimized if the drive knows that the OS does not care > about certain blocks. Hard drives don't do this, so they have no reason to > support TRIM. > -- > 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
