Bob Friesenhahn wrote:
Of course, it is my understanding that the zfs slog is written
sequentially so perhaps this applies instead:
Actually, reading up on these drives I've started to wonder about the
slog writing pattern. While these drives do seem to do a great job at
random writes, most of the promise shows at sequential writes, so Does
the slog attempt to write sequentially through the space given to it?
Also there are all sorts of analysis out there about how the drives
always attempt to write new data to the pages and blocks they know are
empty since they can't overwrite one page (usually 4k) without erasing
the whole (512k) block the page is in. This leads to a drop in write
performance after all the space (both the space you paid for, and any
extra space the vendor putin to work around this issue) has been used
once. This shows up in regular filesystems because when a file is
deleted the drive only sees a new (over)write of some meta-data so the
OS can record that the file is gone, but the drive is never told that
the blocks the file was occupying are now free and can be pre-erased at
the drives convience.
The Drive vendors have come up with a new TRIM command, which some OS's
(Win7) are talking about supporting in their Filesystems. Obviously for
use only as an sLog device ZFS itself doesn't need (until people start
using SSD's as regular pool devices) to know how to use TRIM, but I
would think that the slog code would need to use it in order to keep
write speeds up and latencies down. No?
If so, what's the current concensus, thoughts, plans, etc. on if and
when TRIM will be usable in Solaris/ZFS?
-Kyle
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
