<div dir="ltr">Well, it's two different file systems, two different operating systems, and (I assume) two different machines with different disks and different network links.  Maybe even two different encryption setups?  I don't know if the FreeBSD machine is using ZFS or UFS - if it's UFS, it's not recording history so there's less overall work.  That can make a difference too. Unfortunately this all adds up to a shoulder shrug, in terms of an answer.<div style>
<br></div><div style>There's been a lot of discussion about the disk scheduler and how to position reading vs. writing for Hammer over the past year or two.  If you really want to dive into it, there's the 'dsched' man page, and the other pages it links to from there.  Also, there's scheduler-related links on the Digest: </div>
<div style><br></div><div style><a href="http://www.shiningsilence.com/dbsdlog/index.php?s=sched">http://www.shiningsilence.com/dbsdlog/index.php?s=sched</a><br></div><div style><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sun, Feb 10, 2013 at 5:17 AM, Carsten Mattner <span dir="ltr"><<a href="mailto:carstenmattner@gmail.com" target="_blank">carstenmattner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I compared FreeBSD 9.1 geli based full disk encrypted system<br>
with a dfly (HAMMER) 3.2.2 full disk encrypted system I noticed that<br>
using an ssh session is considerably less responsive on dfly if I<br>
rsync data from another machine to the dfly machine in parallel.<br>
On FreeBSD the ssh session doesn't get unresponsive. This is<br>
subjective and not scientifically measured and I'm just curious<br>
to hear your thoughts. Is it just probably caused by default settings?<br>
</blockquote></div><br></div>