<div dir="ltr">Well, I'm not sure if it helps for your case. there are clearly a side-effect unless the cache dirs is also shared through NFS. we need any way to see the update without mtime for that then.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 29, 2015 at 7:36 PM, Nick Alcock <span dir="ltr"><<a href="mailto:nick.alcock@oracle.com" target="_blank">nick.alcock@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 29 Jul 2015, Akira TAGOH said:<br>
<br>
> Hi,<br>
><br>
> Since fontconfig validates a cache during loading it, you'll see your<br>
> concern after this change right.<br>
> I think we need to implement another way or API etc for that use case and<br>
> web font support instead of disabling this check. even checking mtime in<br>
> this case shouldn't be wanted. let me think more.<br>
<br>
</span>Yeah. I've noticed extreme slowdowns with an NFS-mounted font directory<br>
too (10+ seconds to start each fontconfig user after the NFS attribute<br>
cache expires) -- fontconfig's statting the whole thing every time,<br>
which is wholly pointless because will never be updated without running<br>
fc-cache on all NFS-connected machines. And that directory has thousands<br>
of fonts in it...<br>
<br>
Having an optional off-by-default way to quiesce this revalidation would<br>
be nice. (I was going to just implement it in an ugly local hack, but<br>
then this came up... so clearly this sort of thing not affecting just<br>
me.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
NULL && (void)<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Akira TAGOH</div>
</div>