in my back pocket so I get a head start when
we get around SAS testing again.
On 18/01/2013 6:32 PM, Karim Fodil-Lemelin wrote:
On 18/01/2013 5:42 PM, Matthew Jacob wrote:
This is all turning into a bikeshed discussion. As far as I can tell,
the basic original question was why a *SAS
On 18/01/2013 10:16 AM, Mark Felder wrote:
On Thu, 17 Jan 2013 16:12:17 -0600, Karim Fodil-Lemelin
fodillemlinka...@gmail.com wrote:
SAS controllers may connect to SATA devices, either directly
connected using native SATA protocol or through SAS expanders using
SATA Tunneled Protocol (STP
On 18/01/2013 5:42 PM, Matthew Jacob wrote:
This is all turning into a bikeshed discussion. As far as I can tell,
the basic original question was why a *SAS* (not a SATA) drive was not
performing as well as expected based upon experiences with Linux. I
still don't know whether reads or writes
On 16/01/2013 2:48 AM, Dieter BSD wrote:
Karim writes:
It is quite obvious that something is awfully slow on SAS drives,
whatever it is and regardless of OS comparison. We swapped the SAS
drives for SATA and we're seeing much higher speeds. Basically on par
with what we were expecting (roughly
On 15/01/2013 3:03 PM, Dieter BSD wrote:
Disabling the disks's write cache is *required* for data integrity.
One op per rev means write caching is disabled and no queueing.
But dmesg claims Command Queueing enabled, so you should be getting
more than one op per rev, and writes should be fast.
Is
On 15/01/2013 3:55 PM, Adrian Chadd wrote:
You're only doing one IO at the end. That's just plain silly. There's
all kinds of overhead that could show up, that would be amortized over
doing many IOs.
You should also realise that the raw disk IO on Linux is by default
buffered, so you're hitting
On 15/01/2013 4:54 PM, Wojciech Puchar wrote:
# dd if=/dev/zero of=foo count=1 bs=1024
1+0 records in
1+0 records out
1024 bytes transferred in 19.579077 secs (523007 bytes/sec)
you write to file not device, so it will be clustered anyway by FreeBSD.
128kB by default, more if you put
On 15/01/2013 4:54 PM, Wojciech Puchar wrote:
# dd if=/dev/zero of=foo count=1 bs=1024
1+0 records in
1+0 records out
1024 bytes transferred in 19.579077 secs (523007 bytes/sec)
you write to file not device, so it will be clustered anyway by FreeBSD.
128kB by default, more if you put
Good day,
I have stumbled into a strange problem where my FBSD 4.x box keeps
crashing under network traffic load. I have enabled INVARIANTS and
debugging and was able to gather a trace. The context here is that a
listening connection created a syncache entry sent a syn-ack and is now
Hi,
Your problem here is that your TTCP connection times out and the
data is retransmitted (loosing all the benefits of TTCP) see my other
email for why this happens.
Karim.
Danny Braniss wrote:
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644
10 matches
Mail list logo
