Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Feb 2012 03:04:10 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Peter Jeremy <peterjeremy@acm.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: disk devices speed is ugly
Message-ID:  <20120215010410.GS3283@deviant.kiev.zoral.com.ua>
In-Reply-To: <20120214200258.GA29641@server.vk2pj.dyndns.org>
References:  <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <CAJ-VmomezUWrEgxxmUEOhWnmLDohMAWRpSXmTR=n2y_LuizKJg@mail.gmail.com> <4F37F81E.7070100@os2.kiev.ua> <CAJ-Vmok9Ph1sgFCy6kNT4XR14grTLvG9M3JvT9eVBRjgqD%2BY9g@mail.gmail.com> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org>

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

--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 <gpalmer@freebsd.org> 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--



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