Re: SSD - TRIM command

[Roberto Spadim <roberto@spadim.com.br>]

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@nexgo.de>:
>> 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@bounceswoosh.org>:
>> > 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@bounceswoosh.org
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> > the body of a message to majordomo@vger.kernel.org
>> > 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@vger.kernel.org
>> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html