From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 17:21:01 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E78CB6B5; Sat, 28 Mar 2015 17:21:01 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88900D23; Sat, 28 Mar 2015 17:21:01 +0000 (UTC) Received: by wgdm6 with SMTP id m6so129733833wgd.2; Sat, 28 Mar 2015 10:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1LxlOfOLUxU2KEooV0UB8p7GkDjYuebqp2Yl3dKx37E=; b=czemo3O70ZFPTpIKvn+HKdDo5xE7le6R/OtWrqe+kss7sZuLBmnI+RjH9nDbu5DoQz TSR9cs3Z9+MdJ/jtoYjjWfgAoueN5oUCiLJhyekhiVjf60g9Yw04eLOGiis7+1TbS/FN AB5ZQLJ2GgOhbiB2iIQcUdvU4EijvmRzQkgKFuVciE2nxQGH5Anpc0mdguqwSfdHEEIu ky6tXk67LEBNVHjIKqYeeGX4YGyxWicIj4eZwfQYXVGiPwr05T1QSnaDOxZR0uZmljfV DwDVWTkMMaQ4nj8AExPYw83ILWSKvqVaIqp3UEwCqniKjBjUsez4ydRVFpzmW2Ny3R4e es6Q== X-Received: by 10.194.185.68 with SMTP id fa4mr46456489wjc.111.1427563260021; Sat, 28 Mar 2015 10:21:00 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id ga8sm7884714wib.11.2015.03.28.10.20.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 10:20:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <5516E2F9.20205@FreeBSD.org> Date: Sat, 28 Mar 2015 19:20:57 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: MAXBSIZE increase References: <5515C421.4040703@FreeBSD.org> <20150328171315.GU2379@kib.kiev.ua> In-Reply-To: <20150328171315.GU2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 17:21:02 -0000 On 28.03.2015 19:13, Konstantin Belousov wrote: > On Fri, Mar 27, 2015 at 10:57:05PM +0200, Alexander Motin wrote: >> Experimenting with NFS and ZFS I found an inter-operation issue: ZFS by >> default uses block of 128KB, while FreeBSD NFS (both client and server) >> is limited to 64KB requests by the value of MAXBSIZE. On file rewrite >> that limitation makes ZFS to do slow read-modify-write cycles for every >> write operation, instead of just writing the new data. Trivial iozone >> test show major difference between initial write and rewrite speeds >> because of this issue. >> >> Looking through the sources I've found and in r280347 fixed number of >> improper MAXBSIZE use cases in device drivers. After that I see no any >> reason why MAXBSIZE can not be increased to at least 128KB to match ZFS >> default (ZFS now supports block up to 1MB, but that is not default and >> so far rare). I've made a test build and also successfully created UFS >> file system with 128KB block -- not sure it is needed, but seems it >> survives this change well too. >> >> Is there anything I am missing, or it is safe to rise this limit now? > > This post is useless after the Bruce explanation, but I still want to > highlidht the most important point from that long story: > > increasing MAXBSIZE without tuning other buffer cache parameters > would dis-balance the buffer cache. Allowing bigger buffers increases > fragmentation, while limiting the total number of buffers. Also, it > changes the tuning for runtime limits for amount of io in flight, see > hi/lo runningspace initialization. I would be happy if somebody with more skills in buffer cache brought some order into that area, hopefully once and forever. -- Alexander Motin