Any method for NGINX (as a web-server) to skip metadata and serve content from cached file?

[Lucas Rolff]

> In this model, only the originally cached file at /disk1/cache can be served properly by the NGINX-proxy. 

You can balance disk usage using split_clients module in nginx, and use different proxy_cache’s (e.g. /disk1/cache, /disk2/cache and so on) as described in https://www.nginx.com/blog/nginx-caching-guide/ (Splitting the cache across multiple hard drives).


On 29/09/2017, 21.31, "nginx on behalf of rnmx18" <nginx-bounces at nginx.org on behalf of nginx-forum at forum.nginx.org> wrote:

    Hi Lucas,
    
    As long as the cached files (with the metadata at the beginning) reside in
    the directory specified with the proxy_cache_path directive, they are fine.
    The NGINX-proxy, which added them there in the first place, can serve the
    content correctly, after skipping the right amount of metadata bytes.
    
    In my case, I have a background application, which might copy the cached
    file to an alternate location. For example, a file movies/welcome.mp4 may be
    originally cached by NGINX-proxyon /disk1/cache as
    /disk1/cache/movies/welcome.mp4  (For the moment, let us forget the
    md5-based cache path for simplicity).  In my use-case, the file may either
    stay there itself, or sometimes, my application may copy it to another
    location  - say /disk2/cache/movies/welcome.mp4 or say,
    /disk3/cache/movies/welcome.mp4, say for some kind of disk usage balancing..
    The application exposes /disk1/pubroot/cache/movies/welcome.mp4 as the
    published location.
    
    In this model, only the originally cached file at /disk1/cache can be served
    properly by the NGINX-proxy. 
    
    The files in any of the other locations cannot be served by NGINX properly.
    It cannot serve as a server, as the copied file contains metadata. Even if I
    have other proxy-cache-paths defined for the alternate locations
    (/disk2/cache or /disk3/cache), the NGINX-proxy also cannot serve them as
    the corresponding in-memory metadata will not have the entries for these
    files. The files in those paths, would have been physically copied "under
    the hood" by another process, and not NGINX.
    
    Thanks
    Rajesh
    
    Posted at Nginx Forum: https://forum.nginx.org/read.php?2,276612,276621#msg-276621
    
    _______________________________________________
    nginx mailing list
    nginx at nginx.org
    http://mailman.nginx.org/mailman/listinfo/nginx