Nicolas Williams wrote:
On Sat, May 13, 2006 at 08:23:55AM +0200, Franz Haberhauer wrote:
Given that ISV apps can be only changed by the ISV who may or may not be
willing to
use such a new interface, having a "no cache" property for the file - or
given that filesystems
are now really cheap with ZFS - for the filesystem would be important
as well,
like the forcedirectio mount option for UFS.
No caching at the filesystem level is always appropriate if the
application itself
maintains a buffer of application data and does their own application
specific buffer management
like DBMSes or large matrix solvers. Double caching these typicaly huge
amounts data
in the filesystem is always a waste of RAM.
Yes, but remember, DB vendors have adopted new features before -- they
want to have the fastest DB. Same with open source web servers. So I'm
a bit optimistic.
Yes, but they usually adopt it only with their latest releases, but it
takes time until these are
adopted by customers. And it's not just DB vendors, there are other apps
around which could
benefit, and there are always some who may not adopt a new feature in
Solaris at all.
Remember when UFS Directio was introduced - forcedirectio was in much
wider use than
apps which used the API directly.
Also, an LD_PRELOAD library could be provided to enable direct I/O as
necessary.
This would work technically, but wether ISVs are willing to support such
usage is a different
topic (there may be startup scripts involved making it a little tricky
to pass an library path
to the app).
So while having the app request no caching may be the architecturally
cleaner approach, having
it as a property on a file or filesystem is a pragmatic approach, with
faster time-to-market
and a potential for a much broader use.
- Franz
Nico
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
