Did you find a resoltion to this issue?
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Ah, vi does an fsync. So I suspect that this is bug:
6413510 zfs: writing to ZFS filesystem slows down fsync() on other files
in the same FS
Here's a snippet from the Evaluation:
---
ZFS keeps in list in memory of all transactions and will push *all*
of them out on a fsync.
I've some important information that should shed some light on this behavior:
This evening I created a new filesystem across the very same 50 disks including
the COMPRESS attribute. My goal was to isolate some workload to the new
filesystem and started moving a 100GB directory tree over to the n
I'll see if I can confirm what you are suggesting. Thanks.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Anantha N. Srirama wrote:
Quick update, since my original post I've confirmed via DTrace (rwtop script in
toolkit) that the application is not generating 150MB/S * compressratio of I/O.
What then is causing this much I/O in our system?
This message posted from opensolaris.org
Are you doi
Quick update, since my original post I've confirmed via DTrace (rwtop script in
toolkit) that the application is not generating 150MB/S * compressratio of I/O.
What then is causing this much I/O in our system?
This message posted from opensolaris.org
__
