just some ideas... hummm thinking about TRIM in a mixed supported/non supported raid1 array... when a filesystem will read a block that is trimmed? since filesystem first write and after read, maybe never trimmed blocks are unused blocks (filesystem know where they are) maybe with a (read/compare/write if diff) resync function, we will have problems with non trimmed (with support to TRIM) disks being added on raid1 maybe.... i think that sending trim to devices isn´t a problem, it´s optimization of disk that must be done by filesystem, raid1 should only send this command to disks. the problem is, if a disk don´t have trim, we must implement a trim compatible command (or not... filesystem know about free blocks) 2011/2/21 Phillip Susi <psusi@xxxxxxxxxx>: > On 2/9/2011 11:19 AM, Eric D. Mudama wrote: >> For SATA devices, ATA8-ACS2 addresses this through Deterministic Read >> After Trim in the DATA SET MANAGEMENT command. Devices can be >> indeterminate, determinate with a non-zero pattern (often all-ones) or >> determinate all-zero for sectors read after being trimmed. > > IIRC, it was a word in the IDENTIFY response, not the DATA SET > MANAGEMENT command. > > On 2/9/2011 11:28 AM, 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. > > The drive tells YOU how its trim behaves; you don't command it. > > If the drive is deterministic and always returns zeros after TRIM, then > mdadm could pass the TRIM down and process it like a write of all zeros, > and recompute the parity. If it isn't deterministic, then I don't think > there's anything you can do to handle TRIM requests. > -- > 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
