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 is
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 sin
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 pu
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 p
- Original Message -
> From: "Dieter BSD"
> 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
> >
> > root@freebsd:/root #
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.
___
freebsd-hackers@fre
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.
在 2012-07-2
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 dedi
What is the default kernel thread stack size on FreeBSD? I am
particularly interested in knowing about i386 and amd64, but knowing
this for other architectures (such as MIPS) would also be useful.
signature.asc
Description: OpenPGP digital signature
9 matches
Mail list logo
