My understanding is that there's never any need for a reader to wait for a
write in progress. ZFS keeps all writes in memory until they're committed to
disk - if you ever try to read something that's either waiting to be, or is
being written to disk, ZFS will serve it straight from RAM.
One qu
On Tue, 28 Jul 2009, Marcelo Leal wrote:
Ok Bob, but i think that is the problem about picket fencing... and
so we are talking about commit the sync operations to disk. What i'm
seeing is no read activity from disks when the slog is beeing
written. The disks are "zero" (no read, no write).
T
Ok Bob, but i think that is the problem about picket fencing... and so we are
talking about commit the sync operations to disk. What i'm seeing is no read
activity from disks when the slog is beeing written. The disks are "zero" (no
read, no write).
Thanks a lot for your reply.
Leal
[ http:/
On Mon, 27 Jul 2009, Marcelo Leal wrote:
Well, i'm trying to understand this workload, but what i'm seeing to
reproduce this is just flood the SSD with writes, and the disks show
no activity. I'm testing with aggr (two links), and for one or two
seconds there is no read activity (output from s
Hello,
Well, i'm trying to understand this workload, but what i'm seeing to reproduce
this is just flood the SSD with writes, and the disks show no activity. I'm
testing with aggr (two links), and for one or two seconds there is no read
activity (output from server).
Right now i'm suspecting
byleal,
Can you share how to recreate or test this?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Hello all...
I'm seeing this behaviour in an old build (89), and i just want to hear from
you if there is some known bug about it. I'm aware of the "picket fencing"
problem, and that ZFS is not choosing right if write to slog is better or not
(thinking if we have a better throughput from disks)