<div dir="ltr"><div>Even,</div><div><br></div><div>Does the shared attribute of a VRT sourceFilename element not affect caching at all? Is the cache avoided so that potentially stale data isn't propagated, or for other reasons?<br></div><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">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"><u></u>

  
    
  
  <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>