On Fri, Jun 15, 2012 at 12:56 PM, Timothy Coalson wrote:
> Thanks for the suggestions. I think it would also depend on whether
> the nfs server has tried to write asynchronously to the pool in the
> meantime, which I am unsure how to test, other than making the txgs
> extremely frequent and watch
Thanks for the suggestions. I think it would also depend on whether
the nfs server has tried to write asynchronously to the pool in the
meantime, which I am unsure how to test, other than making the txgs
extremely frequent and watching the load on the log devices. As for
the integer division givi
On Jun 14, 2012, at 1:35 PM, Robert Milkowski wrote:
>> The client is using async writes, that include commits. Sync writes do
>> not need commits.
>>
>> What happens is that the ZFS transaction group commit occurs at more-
>> or-less regular intervals, likely 5 seconds for more modern ZFS
>> sys
[Phil beat me to it]
Yes, the 0s are a result of integer division in DTrace/kernel.
On Jun 14, 2012, at 9:20 PM, Timothy Coalson wrote:
> Indeed they are there, shown with 1 second interval. So, it is the
> client's fault after all. I'll have to see whether it is somehow
> possible to get the s
Indeed they are there, shown with 1 second interval. So, it is the
client's fault after all. I'll have to see whether it is somehow
possible to get the server to write cached data sooner (and hopefully
asynchronous), and the client to issue commits less often. Luckily I
can live with the current
On 14 Jun 2012, at 23:15, Timothy Coalson wrote:
>> The client is using async writes, that include commits. Sync writes do not
>> need commits.
>
> Are you saying nfs commit operations sent by the client aren't always
> reported by that script?
They are not reported in your case because the com
> The client is using async writes, that include commits. Sync writes do not
> need commits.
Are you saying nfs commit operations sent by the client aren't always
reported by that script?
> What happens is that the ZFS transaction group commit occurs at more-or-less
> regular intervals, likely 5
> The client is using async writes, that include commits. Sync writes do
> not need commits.
>
> What happens is that the ZFS transaction group commit occurs at more-
> or-less regular intervals, likely 5 seconds for more modern ZFS
> systems. When the commit occurs, any data that is in the ARC bu
Hi Tim,
On Jun 14, 2012, at 12:20 PM, Timothy Coalson wrote:
> Thanks for the script. Here is some sample output from 'sudo
> ./nfssvrtop -b 512 5' (my disks are 512B-sector emulated and the pool
> is ashift=9, some benchmarking didn't show much difference with
> ashift=12 other than giving up 8
Thanks for the script. Here is some sample output from 'sudo
./nfssvrtop -b 512 5' (my disks are 512B-sector emulated and the pool
is ashift=9, some benchmarking didn't show much difference with
ashift=12 other than giving up 8% of available space) during a copy
operation from 37.30 with sync=stan
On Jun 13, 2012, at 4:51 PM, Daniel Carosone wrote:
> On Wed, Jun 13, 2012 at 05:56:56PM -0500, Timothy Coalson wrote:
>> client: ubuntu 11.10
>> /etc/fstab entry: :/mainpool/storage /mnt/myelin nfs
>> bg,retry=5,soft,proto=tcp,intr,nfsvers=3,noatime,nodiratime,async 0
>>0
>
>
Interesting...from what I had read about NFSv3 asynchronous writes,
especially bits about "does not require the server to commit to stable
storage", led me to expect different behavior. The performance impact
on large writes (which we do a lot of) wasn't severe, so sync=disabled
is probably not wo
On Wed, Jun 13, 2012 at 05:56:56PM -0500, Timothy Coalson wrote:
> client: ubuntu 11.10
> /etc/fstab entry: :/mainpool/storage /mnt/myelin nfs
> bg,retry=5,soft,proto=tcp,intr,nfsvers=3,noatime,nodiratime,async 0
> 0
nfsvers=3
> NAME PROPERTY VALUE SOURCE
> m
I noticed recently that the SSDs hosting the ZIL for my pool had a large
number in the SMART attribute for total LBAs written (with some
calculation, it seems to be the total amount of data written to the pool so
far), did some testing, and found that the ZIL is being used quite heavily
(matching t
14 matches
Mail list logo
