>>>>> "km" == Kyle McDonald <kmcdon...@egenera.com> writes:
km> hese drives do seem to do a great job at random writes, most
km> of the promise shows at sequential writes, so Does the slog
km> attempt to write sequentially through the space given to it?
when writing to the slog, some user-visible application has to wait
for the slog to return that the write was committed to disk. so
whether it's random or not, you're waiting for it, and io/s translates
closely into latency because the writes cannot be batched with normal
level of aggressiveness (or they should jsut go to the main pool which
will eventually have to handle the entire workload anyway). io/s is
the number that matters.
``but but but but!''
<thwack> NO! Everyone who is using the code, writing the code, and
building the systems says, io/s is the number that matters. If you've
got some experience otherwise, fine, odd things turn up all the time.
but AFAICT the consensus is clear right now.
km> they can't overwrite one page (usually 4k) without erasing the
km> whole (512k) block the page is in.
don't presume to get into the business of their black box so far.
That's almost certainly not what they do. They probably do COW like
ZFS and (yaffs and jffs2 and ubifs), so they will do the 4k writes to
partly-empty pages until the page is full. In the background a gc
thread will evacuate and rewrite pages that have become spattered with
unreferenced sectors. They will write to the flash filesystem to keep
track of things about itself, like half-erased cels, toasted cels,
per-cel erase counts. Then there is probably a defragmenter thread,
or else the gc is itself data-reorganizing. And there is some lookup
state kept in DRAM during operation, and reconstructed from
post-mortem observation of what's in the FLASH at boot, like with any
filesystem.
Just look at the observed performance on microbenchmarks or in actual
use rather than trying to reverse-reason about these fancy and
otherwise-unobtainable closed-source filesystems, whichis what they
are really selling, in disk/``game cartridge'' form factor.
km> The Drive vendors have come up with a new TRIM command, which
km> some OS's (Win7) are talking about supporting in their
km> Filesystems.
this would be useful for VM's with thin-provisioned disks, too.
km> I would think that the slog code would need to use it in order
km> to keep write speeds up and latencies down. No?
read the goofy gamer site review please. No, not with the latest
intel firmware, it's not needed.
pgpSAHGwqAg1s.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
