Joerg Schilling wrote:
Ragnar Sundblad <ra...@csc.kth.se> wrote:
On 1 jan 2010, at 17.28, David Magda wrote:
Don't really see how things are either hardware specific or dependent.
The inner workings of a SSD flash drive is pretty hardware (or
rather vendor) specific, and it may not be a good idea to move
any knowledge about that to the file system layer.
If ZFS likes to keep SSDs fast even after it was in use for a while, then
even ZFS would need to tell the SSD which sectors are no longer in use.
Such a mode may cause a noticable performance loss as ZFS for this reason
may need to traverse freed outdated data trees but it will help the SSD
to erase the needed space in advance.
Jör
the TRIM command is what is intended for an OS to notify the SSD as to
which blocks are deleted/erased, so the SSD's internal free list can be
updated (that is, it allows formerly-in-use blocks to be moved to the
free list). This is necessary since only the OS has the information to
determine which previous-written-to blocks are actually no longer in-use.
See the parallel discussion here titled "preview of new SSD based on
SandForce controller" for more about "smart" vs "dumb" SSD controllers.
From ZFS's standpoint, the optimal configuration would be for the SSD
to inform ZFS as to it's PAGE size, and ZFS would use this as the
fundamental BLOCK size for that device (i.e. all writes are in integer
multiples of the SSD page size). Reads could be in smaller sections,
though. Which would be interesting: ZFS would write in Page Size
increments, and read in Block Size amounts.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
