> 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" <[email protected] on 
behalf of [email protected]> 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
    [email protected]
    http://mailman.nginx.org/mailman/listinfo/nginx
    

_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx

Reply via email to