Nginx record length during disk IO

[oscaretu .]

When a call to rename(2) returns -1 and in errno the value es EXDEV, it
means the system file doesn't support the rename feature, so the
application is supposed to be able to solve this creating a file in the new
filesystem and deleting the old file. This is something that I read
recently about aufs filesystem (Docker uses aufs by default)

Kind regards,
Oscar

On Mon, Jan 16, 2017 at 1:10 PM, nicktgr15 <nginx-forum at forum.nginx.org>
wrote:

> Thanks for the useful information Maxim!
>
> We ended up using strace to monitor the system calls and it looks like that
> with our current setup (i.e. default buffer size) the record length is
> 65536
> bytes.
>
> read(17, "\355\247=^\256\36\361\235~\356z"..., 65536) = 65536
> write(18, "\355\247=^\256\36\361\235~\356z"..., 65536) = 65536
>
> At the moment we are setting use_temp_path=on using tmpfs as our temporary
> location which triggers a failed rename system call and then the above
> read/write calls happen.
>
> rename("/var/lib/nginx/tmp/proxy/1/00/0000001",
> "/dev/shm/cache/a/f8/0c725bfea12c2f361c37") = -1 EXDEV (Invalid
> cross-device
> link)
>
> Do you think that having use_temp_path=on in combination with tmpfs has any
> advantages or we should set use_temp_path=off as suggested in the docs?
>
> Regards,
> Nik
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,271961,272003#msg-272003
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
Oscar Fernandez Sierra
oscaretu at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170116/ffc0dd4a/attachment.html>