On Feb 20, 2012, at 12:24 PM, Alex Samorukov wrote: > On 02/15/2012 05:50 AM, Scott Long wrote: >> >> 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. >> >> Any filesystem that uses bread/bwrite/cluster_read are already using the >> "generic caching subsystem" that you propose. This includes UDF, CD9660, >> MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage >> filesystem in the tree except for ZFS. Not all of them implement >> VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vnode >> pager, not requirements for using buffer-cache services on block devices. >> As Kostik pointed out in a parallel email, the only thing that was removed >> from FreeBSD was the userland interface to cached devices via /dev nodes. >> This has nothing to do with filesystems, though I suppose that could maybe >> sorta kinda be an issue for FUSE?. > May be its possible to provide some generic interface for fuse based > filesystems to use this generic cache? I can test it and report performance. >
What you're asking for is to bring back the cached raw devices. I don't have a strong opinion on this one way or another, except that it's a pretty specific use case. Does the inherent performance gap with user land filesystems warrant this? Maybe a simple cache layer can be put into FUSE that would allow client filesystems the same control over block caching and clustering that is afforded in the kernel? Scott _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
