da0: 3.300MB/s transfers
da0: Command Queueing enabled
root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144
4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec)
1) Does a larger block size (bs=1m) help?
2) That's roughly the speed I'd expect without
You are right. It is not capped at that speed:
root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144
262144+0 records in
262144+0 records out
4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec)
you did test da1 while dmesg are about da0?
is it OK and da1
2) That's roughly the speed I'd expect without queueing. Is it really
making effective use of queueing, or is something limiting queueing to
one transfer at a time?
still 400-500 IOPS is way too little.
FreeBSD without VM machine can do well over 1 IOPS of 512 byte
sequential read with
Apache Traffic Server may use raw disk for caching, and for privilege
elevation, the worker process(traffic_server) will setuid to nobody, my
question is, how to make traffic_server access the /dev/ada*?
in linux, disk permitting is root:disk 0660, we can go with:
1, setup a new user 'ats', and
Apache Traffic Server may use raw disk for caching, and for privilege
elevation, the worker process(traffic_server) will setuid to nobody, my
question is, how to make traffic_server access the /dev/ada*?
in linux, disk permitting is root:disk 0660, we can go with:
1, setup a new user 'ats', and
- Original Message -
From: Dieter BSD dieter...@engineer.com
To: hack...@freebsd.org, curr...@freebsd.org
Sent: Sunday, July 22, 2012 1:19:32 AM
Subject: Re: Awful FreeBSD 9 block IO performance in KVM
da0: 3.300MB/s transfers
da0: Command Queueing enabled
kproc that vtblk_strategy() enqueues bio's to. This has been on my
todo for a while, but haven't had the time. Also, the use of
bioq_disksort() probably doesn't gain much for virtualized disks,
definitely. it is done by the host.
___
yeah, rules in devfs always work. and it may introduce more challenge on
operation management, is there any way that we can do it more clean?
should we set the permission for :operator g+w on disks and partitions?
then we can put a dedicate user for trafficserver into operator group.
在
On 23/07/2012, at 11:17, ming@gmail.com wrote:
yeah, rules in devfs always work. and it may introduce more challenge on
operation management, is there any way that we can do it more clean?
should we set the permission for :operator g+w on disks and partitions?
then we can put a dedicate
9 matches
Mail list logo
