Re: SSD - TRIM command

From: Roberto Spadim <roberto@spadim.com.br>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: "Mathias Burén" <mathias.buren@gmail.com>,
	"Eric D. Mudama" <edmudama@bounceswoosh.org>,
	"David Brown" <david@westcontrol.com>,
	linux-raid@vger.kernel.org
Subject: Re: SSD - TRIM command
Date: Tue, 22 Feb 2011 00:29:09 -0300	[thread overview]
Message-ID: <AANLkTik4qovN19Kv0q6wa54Cd-xCJBMbN491R4u6nbtX@mail.gmail.com> (raw)
In-Reply-To: <4D63218F.2000309@cfl.rr.com>

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@cfl.rr.com>:
> 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@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