<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 19/04/2024 à 17:28, Sean Gillies a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAOodmJpo0n3hJDKbqzSsj0o28f4itwVB8zGjcsFXnbjNFCHQXg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Even,</div>
<div><br>
</div>
<div>Does the shared attribute of a VRT sourceFilename element
not affect caching at all? </div>
</div>
</blockquote>
<p>If shared is set to 0, then one GDALDataset per VRTSource will be
opened. This has little benefit.</p>
<p>The scope of sharing was initially greater since it extented to
potentially several GDALDataset instance of VRT, but this wasn't
safe in multithreaded scenarios where you would read one VRT in a
thread, another one in another thread, but both would point to
let's same the same TIFF GDALDataset. Hence the scope of sharing
was reduced to a single GDALDataset VRT instance to be safe by
default.<br>
</p>
<blockquote type="cite"
cite="mid:CAOodmJpo0n3hJDKbqzSsj0o28f4itwVB8zGjcsFXnbjNFCHQXg@mail.gmail.com">
<div dir="ltr">
<div>Is the cache avoided so that potentially stale data isn't
propagated, or for other reasons?<br>
</div>
</div>
</blockquote>
Are you reacting to "if it is triggered. VRTSource::IRasterIO()
calls IRasterIO() on the source band, which doesn't necessarily
always trigger block-based reading" ? I just meant that calling
IRasterIO() on a GDALDataset/GDALRasterBand doesn't necessarily
cause the block cache to trigger. This is dependent of the driver
and the parameters of the request. And this isn't specific to use it
from a VRT.<br>
<blockquote type="cite"
cite="mid:CAOodmJpo0n3hJDKbqzSsj0o28f4itwVB8zGjcsFXnbjNFCHQXg@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2024 at
9:09 AM Even Rouault <<a
href="mailto:even.rouault@spatialys.com"
moz-do-not-send="true" class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Sean,</p>
<p>Within a given GDALDataset opened on a VRT, if the VRT
references several times the same source, only one
GDALDataset will be opened for it, so you may benefit
from the block cache mechanism (if it is triggered.
VRTSource::IRasterIO() calls IRasterIO() on the source
band, which doesn't necessarily always trigger
block-based reading). But if you open another VRT (or
the same one), it will not share the same GDALDataset
for sources that may be common with the first one, so no
re-use of existing block cache. For network sources, the
I/O cache at the /vsicurl/ level works however on
filenames, not VSIFILE* instances, so you will save
network reads</p>
<p>Even<br>
</p>
<div>Le 19/04/2024 à 16:48, Sean Gillies via gdal-dev a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Happy Friday, folks!</div>
<div><br>
</div>
<div>Are the source rasters of a VRT added to the
block cache such that different VRTs using the same
source can avoid reads from disk or the network? Or
is it intended that the VSI cache covers this need
instead?</div>
<div><br>
</div>
<div>Thanks,<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br clear="all">
<br>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Sean Gillies</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>