Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Aug 2013 10:36:12 -0500
From:      Karl Denninger <karl@denninger.net>
Cc:        fs@freebsd.org
Subject:   Re: Fwd: Disk scheduling activity...
Message-ID:  <520BA3EC.1030304@denninger.net>
In-Reply-To: <520BA249.8030603@digiware.nl>
References:  <520B8B1E.7060002@digiware.nl> <alpine.GSO.2.01.1308140859070.2267@freddy.simplesystems.org> <520BA249.8030603@digiware.nl>

next in thread | previous in thread | raw e-mail | index | archive | help

On 8/14/2013 10:29 AM, Willem Jan Withagen wrote:
> On 2013-08-14 16:03, Bob Friesenhahn wrote:
>> On Wed, 14 Aug 2013, Willem Jan Withagen wrote:
>>>
>>> Just a point of information or curiosity, and I don't think/know if it
>>> is any problem...
>>>
>>> I have the raidz array with 8 disks, which I'm using to backup to.
>>> It is configured
>>>     4 disks on a mvs controller
>>>     4 disks on an Areca controller (JBODs with battery)
>>>     Both controllers are on a PCI-E slot
>>>
>>> Most of the time the source just fully loads the pipe and sends
>>> 1Gbit/s.
>>>
>>> When that happens I see this alternating pattern of writing either to
>>> the 4 mvs disks, or writing to the Areca disks.
>>> But almost never are all disk accesses at the same time.
>>> And really never, never is there a mix of writing between the
>>> controller
>>> sets.
>>
>
>> Are all 8 disks in the same raidz vdev?
>
> Yes is a raidz1 with 8 disks. I know it is not optimal in performance,
> but I needed the amount of remaining diskspace.
>
>> Are you basing write activity on the drive LEDs?
>
> Yup.
>
>>
>> The Areca controller may be caching the writes in its battery-backed
>> cache and deferring the writes to when zfs tells it to flush its cache.
>> The other controller may be issuing the writes right away. This would
>> explain apparent 'split' writing behavior.
>
> Sounds like a fair assumption. Could remove the battery and see what
> happens then. The mvs device is relatively "simple" and has no
> significant memory on board.
>
>> There is even the possibilty that one of the controllers ignores the
>> cache flush request and performs the writes later when it feels like it.
>
> That would then be the Areca controller, bacause I have the feeling
> that it always writes later.
>
> --WjW
> _
I very much doubt the ARECA is ignoring the cache-flush request.

I have several of these and can get them into a pathological state with
TERRIBLE performance when ZFS starts doing things that demand cache
flushes - the ARECA will perform the demanded flush which, if you have a
lot of RAM on the board, gets real interesting in terms of performance
impact.

-- 
Karl Denninger
karl@denninger.net
/Cuda Systems LLC/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520BA3EC.1030304>