From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 01:04:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6338F10657CC for ; Wed, 15 Feb 2012 01:04:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E89918FC14 for ; Wed, 15 Feb 2012 01:04:17 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1F14AAx049128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1F14AgC000279; Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1F14AmY000278; Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Feb 2012 03:04:10 +0200 From: Konstantin Belousov To: Peter Jeremy Message-ID: <20120215010410.GS3283@deviant.kiev.zoral.com.ua> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ien3FGZY55BN3Fs2" Content-Disposition: inline In-Reply-To: <20120214200258.GA29641@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:04:18 -0000 --ien3FGZY55BN3Fs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 07:02:58AM +1100, Peter Jeremy wrote: > On 2012-Feb-13 08:28:21 -0500, Gary Palmer wrote: > >The filesystem is the *BEST* place to do caching. It knows what metadata > >is most effective to cache and what other data (e.g. file contents) does= n't > >need to be cached. >=20 > Agreed. >=20 > > Any attempt to do this in layers between the FS and > >the disk won't achieve the same gains as a properly written filesystem.= =20 >=20 > Agreed - but traditionally, Unix uses this approach via block devices. > For various reasons, FreeBSD moved caching into UFS and removed block > devices. Unfortunately, this means that any FS that wants caching has > to implement its own - and currently only UFS & ZFS do. Block caching is still there, only user-accessible interface was removed. UFS utilizes the buffer cache for the device which carries the volume, for metadata caching. There are some memory areas in UFS which can be classified as caches on its own, but their existence is mostly to support operation, and not caching (e.g. the inodeblock copy accompaniying each inode). >=20 > What would be nice is a generic caching subsystem that any FS can use > - similar to the old block devices but with hooks to allow the FS to > request read-ahead, advise of unwanted blocks and ability to flush > dirty blocks in a requested order with the equivalent of barriers > (request Y will not occur until preceeding request X has been > committed to stable media). This would allow filesystems to regain > the benefits of block devices with minimal effort and then improve > performance & cache efficiency with additional work. >=20 > One downside of the "each FS does its own caching" in that the caches > are all separate and need careful integration into the VM subsystem to > prevent starvation (eg past problems with UFS starving ZFS L2ARC). Other filesystems which use vfs_bio, like cd9660 or ufs, use the same disk cache layer as UFS. --ien3FGZY55BN3Fs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk87BIgACgkQC3+MBN1Mb4jbGwCgrTTJjedaASuWu5YV1z9ASwxu OJMAoKUq+gnre+3bhN3ehFdwEsbjLjN5 =dSnK -----END PGP SIGNATURE----- --ien3FGZY55BN3Fs2--