Re: В логах pread() failed

[Elifan]

Здравствуйте, Maxim.

Вы писали 10 марта 2010 г., 2:44:00:

> Hello!

> On Wed, Mar 10, 2010 at 12:05:49AM +0200, Elifan wrote:

>> Здравствуйте, Igor.
>> 
>> Вы писали 26 февраля 2009 г., 13:07:40:
>> 
>> > > Из странного, после обновления еще появилось:
>> > > 
>> > > 2009/02/26 13:11:31 [alert] 8690#0: *1999469 pread() read only 2361 of 2787 
>> > > from "/home/multiki/mult_raid/screen/mini/karusel_8.jpg" while sending 
>> > > response to client, client: 92.100.96.143, server: mults.spb.ru, request: 
>> > > "GET /screen/mini/karusel_8.jpg HTTP/1.1", host: "mults.spb.ru", referrer: 
>> > > "http://mults.spb.ru/rss.php";

> [...]

>> Подниму старую тему. Та же проблема, на маленьких файлах .js
>> nginx/0.7.65
>> 7.2-RELEASE FreeBSD
>> ufs, gmirror
>> 
>> directio вообще не описан в конфиге, только
>>     sendfile         off;
>> 
>> из кеширования есть еще:
>>     open_file_cache          max=10000  inactive=200s;
>>     open_file_cache_valid    2s;
>>     open_file_cache_min_uses 2;
>>     open_file_cache_errors   off;
>> 
>> open_file_cache_valid  раньше  был  300  секунд,  сейчас  занизил.  не
>> помогает.  ошибки  о несоответствии ожидаемого и фактического размеров
>> не уходят.

> Такое может быть, если файлы переписываются по месту.

Есть такое, по крону раз в 10 часов, но может быть форсировано вручную, через веб, файл  изменяется
php скриптом fopen('', "w")

> Сейчас open_file_cache проверяет inode number.  При редактировании
> файла по месту - он не меняется, и кеш считает файл неизменившимся 
> со всеми вытекающими последствиями.  Можно пытаться проверять ещё 
> и размер/mtime, но это в общем-то мёртвому припарки - лишь снижает 
> вероятность проблемы, но не устраняет её (т.е. если вы поменяете 
> файл в момент между проверкой размера и собственно отдачей клиенту 
> - опять же будет ошибка).  

А как же open_file_cache_valid    2s ?
Даже  если  в  течении  этих  2х  секунд  и  был старый inode number и
следовательно  старый  размер  файла,  то  почему  ошибка остается и в
дальнейшем, пока не graceful ну и restart само собой?
Даже через inactive=200s ничего хорошего не случается..

> Правильно - менять файлы атомарно.  Т.е. писать рядом новый файл, 
> а потом делать mv(1) или rename(2).