On Sep 7, 2009, at 11:48 AM, Bob Friesenhahn wrote:
On Mon, 7 Sep 2009, Richard Elling wrote:
Yep, it is there to try and solve the problem of rewrites in a
small area,
smaller than the bulk erase size. While it would be trivial to
traverse the
spacemap and TRIM the free blocks, it might not improve performance
for COW file systems. My crystal ball says smarter flash
controllers or a
form of managed flash will win and obviate the need for TRIM
entirely.
Without TRIM there is no way for the FLASH device to know that a
region of data is free and can be reclaimed. It is pretty difficult
to be intelligent without that.
Yes, it is a trade-off for the page size mismatch. But you could
manage this
by reading the page, erasing, and writing... as long as you have some
sort
of nonvolatility arrangement -- hence a managed solution. TRIM just
tries to
eliminate the need for a nonvolatile buffer by pushing that decision
to the OS.
The interesting question is what happens when the important page is
never
free? I presume you just get stuck being slow.
Regardless, TRIM only improves the perception of performance under
relatively light loads where the device is able to erase faster than
the amount of writes. This is important for PCs, where perception
is everything. It does not improve sustained maximum write
throughput.
As far as your crystal ball goes, people here might be interested in
this article about an apparent Sun product which had its
documentation released to the Sun web site a bit too early:
http://www.theregister.co.uk/2009/09/03/sun_flash_array/
The Flash Modules are well known and used in several products already.
http://www.sun.com/storage/flash/module.jsp
The rest is just packaging... (another famous last words :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
