From: Ross Walker [mailto:rswwal...@gmail.com]
Sent: Friday, June 17, 2011 9:48 PM
The on-disk buffer is there so data is ready when the hard drive head
lands,
without it the drive's average rotational latency will trend higher due to
missed landings because the data wasn't in buffer at the
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
Conclusion: Yes it matters to enable the write_cache.
Now the question of whether or not it matters to use the whole disk versus
partitioning, and how to enable the
On Jul 2, 2011, at 6:39 AM, Edward Ned Harvey wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
Conclusion: Yes it matters to enable the write_cache.
Now the question of whether or not it matters to use the
2011-06-19 3:47, Richard Elling пишет:
On Jun 16, 2011, at 8:05 PM, Daniel Carosone wrote:
On Thu, Jun 16, 2011 at 10:40:25PM -0400, Edward Ned Harvey wrote:
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 10:27 PM
Is it still the case, as it once was, that
On Sun, 19 Jun 2011, Richard Elling wrote:
Yes. I've been looking at what the value of zfs_vdev_max_pending should be.
The old value was 35 (a guess, but a really bad guess) and the new value is
10 (another guess, but a better guess). I observe that data from a fast, modern
I am still using
On Jun 21, 2011, at 8:18 AM, Garrett D'Amore wrote:
Does that also go through disksort? Disksort doesn't seem to have any
concept of priorities (but I haven't looked in detail where it plugs in to
the whole framework).
So it might make better sense for ZFS to keep the disk queue depth
From: Richard Elling [mailto:richard.ell...@gmail.com]
Sent: Sunday, June 19, 2011 11:03 AM
I was planning, in the near
future, to go run iozone on some system with, and without the disk cache
enabled according to format -e. If my hypothesis is right, it shouldn't
significantly affect
On Sun, Jun 19, 2011 at 08:03:25AM -0700, Richard Elling wrote:
On Jun 19, 2011, at 6:28 AM, Edward Ned Harvey wrote:
From: Richard Elling [mailto:richard.ell...@gmail.com]
Sent: Saturday, June 18, 2011 7:47 PM
Actually, all of the data I've gathered recently shows that the number of
On Jun 20, 2011, at 6:31 AM, Gary Mills wrote:
On Sun, Jun 19, 2011 at 08:03:25AM -0700, Richard Elling wrote:
On Jun 19, 2011, at 6:28 AM, Edward Ned Harvey wrote:
From: Richard Elling [mailto:richard.ell...@gmail.com]
Sent: Saturday, June 18, 2011 7:47 PM
Actually, all of the data I've
Richard Elling wrote:
On Jun 19, 2011, at 6:04 AM, Andrew Gabriel wrote:
Richard Elling wrote:
Actually, all of the data I've gathered recently shows that the number of IOPS
does not significantly increase for HDDs running random workloads. However the
response time does :-( My data
For SSD we have code in illumos that disables disksort. Ultimately, we believe
that the cost of disksort is in the noise for performance.
-- Garrett D'Amore
On Jun 20, 2011, at 8:38 AM, Andrew Gabriel andrew.gabr...@oracle.com wrote:
Richard Elling wrote:
On Jun 19, 2011, at 6:04 AM,
On Sun, Jun 19, 2011 at 08:03:25AM -0700, Richard Elling wrote:
Yes. I've been looking at what the value of zfs_vdev_max_pending should be.
The old value was 35 (a guess, but a really bad guess) and the new value is
10 (another guess, but a better guess). I observe that data from a fast,
Richard Elling wrote:
Actually, all of the data I've gathered recently shows that the number of
IOPS does not significantly increase for HDDs running random workloads.
However the response time does :-( My data is leading me to want to restrict
the queue depth to 1 or 2 for HDDs.
Thinking
From: Richard Elling [mailto:richard.ell...@gmail.com]
Sent: Saturday, June 18, 2011 7:47 PM
Actually, all of the data I've gathered recently shows that the number of
IOPS does not significantly increase for HDDs running random workloads.
However the response time does :-(
Could you
On Jun 19, 2011, at 6:28 AM, Edward Ned Harvey wrote:
From: Richard Elling [mailto:richard.ell...@gmail.com]
Sent: Saturday, June 18, 2011 7:47 PM
Actually, all of the data I've gathered recently shows that the number of
IOPS does not significantly increase for HDDs running random
On Jun 19, 2011, at 6:04 AM, Andrew Gabriel wrote:
Richard Elling wrote:
Actually, all of the data I've gathered recently shows that the number of
IOPS does not significantly increase for HDDs running random workloads.
However the response time does :-( My data is leading me to want to
On Fri, Jun 17, 2011 at 07:41:41AM -0400, Edward Ned Harvey wrote:
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 11:05 PM
the [sata] channel is idle, blocked on command completion, while
the heads seek.
I'm interested in proving this point. Because I
On Jun 16, 2011, at 8:05 PM, Daniel Carosone wrote:
On Thu, Jun 16, 2011 at 10:40:25PM -0400, Edward Ned Harvey wrote:
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 10:27 PM
Is it still the case, as it once was, that allocating anything other
than whole
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 10:27 PM
Is it still the case, as it once was, that allocating anything other
than whole disks as vdevs forces NCQ / write cache off on the drive
(either or both, forget which, guess write cache)?
I will only
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 11:05 PM
the [sata] channel is idle, blocked on command completion, while
the heads seek.
I'm interested in proving this point. Because I believe it's false.
Just hand waving for the moment ... Presenting the
2011-06-17 15:41, Edward Ned Harvey пишет:
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 11:05 PM
the [sata] channel is idle, blocked on command completion, while
the heads seek.
I'm interested in proving this point. Because I believe it's false.
Just hand
2011-06-17 15:06, Edward Ned Harvey пишет:
When it comes to reads: The OS does readahead more intelligently than the
disk could ever hope. Hardware readahead is useless.
Here's another (lame?) question to the experts, partly as a
followup to my last post about large arrays and essentially
a
On Jun 17, 2011, at 7:06 AM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
I will only say, that regardless of whether or not that is or ever was true,
I believe it's entirely irrelevant. Because your system performs read and
write caching and buffering in ram,
On Thu, Jun 16, 2011 at 09:15:44PM -0400, Edward Ned Harvey wrote:
My personal preference, assuming 4 disks, since the OS is mostly reads and
only a little bit of writes, is to create a 4-way mirrored 100G partition
for the OS, and the remaining 900G of each disk (or whatever) becomes either
a
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 10:27 PM
Is it still the case, as it once was, that allocating anything other
than whole disks as vdevs forces NCQ / write cache off on the drive
(either or both, forget which, guess write cache)?
I will only
On Thu, Jun 16, 2011 at 10:40:25PM -0400, Edward Ned Harvey wrote:
From: Daniel Carosone [mailto:d...@geek.com.au]
Sent: Thursday, June 16, 2011 10:27 PM
Is it still the case, as it once was, that allocating anything other
than whole disks as vdevs forces NCQ / write cache off on the
On 06/16/11 20:26, Daniel Carosone wrote:
On Thu, Jun 16, 2011 at 09:15:44PM -0400, Edward Ned Harvey wrote:
My personal preference, assuming 4 disks, since the OS is mostly reads and
only a little bit of writes, is to create a 4-way mirrored 100G partition
for the OS, and the remaining 900G
27 matches
Mail list logo
