disk devices speed is ugly

Konstantin Belousov kostikbel at gmail.com
Wed Feb 15 01:04:18 UTC 2012

On Wed, Feb 15, 2012 at 07:02:58AM +1100, Peter Jeremy wrote:
> On 2012-Feb-13 08:28:21 -0500, Gary Palmer <gpalmer at 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) doesn't
> >need to be cached.
> Agreed.
> >  Any attempt to do this in layers between the FS and
> >the disk won't achieve the same gains as a properly written filesystem. 
> 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

> 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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120215/d96723b7/attachment.pgp

More information about the freebsd-stable mailing list