On Tue, Jul 13, 2004 at 12:00:07AM +0300, Victor Cheburkin wrote:

Hi!

On Mon, Jul 12, 2004 at 23:17 +0300, Paul Arakelyan wrote:

...

А чего я нигде не встречал, что в http размер файла для нормальной работы с ним - 2GB? (ну, fseek() limitations - эт понятно, но в HTTP длина же в текстовом виде передаётся...). Или это бага апача?

Это неправильно скомпиленный апач. Вообще гофоря, не факт - ибо поведение того же wget при получении "большого числа" - не предсказуемо. И так при таскании такого оно писать отрицательный размер и скорость начинает ;). Думаю, с кучей другого софта были бы те же проблемы, и послать "unspecified length" вместо числа - лучшее решение.

...

И что это за страшные лимиты в 2GB file size на ext3fs? Как люди с этим живут? (пример экстримов - лог дорастает до 2GB и сквид клеи ласты, а как в xDonkey "достать" файло на 3GB линуксоидам - ваще непонятно :) ).

Давно уже нет никаких лимитов, это инфа времен ядра версии 2.0 (хотя я уже не понмю, давно это было). kernel-2.4.21 кажись. Проблема в том, что в отличие от Фри в Линуховой libc есть два варианта вызовов -- один для работы с файлами до 2-х гиг (32-х битный) а второй -- 64-х битный. И вот если при компиляции сказать указать пару дефайнов, то все будет нормально, а если нет -- лимит в 2ГБ. То ли "об этом никто не знает", то ли просто не заморачивались. Но всё-таки, чего ж логгинг валился нафиг (работающий прочесс по достижении 2Гб падал) - не ясно. Точно так же, думаю, что fopen() для логов делается обычно в append mode - то есть, тоже нигде не светится seek position, ну или fseek() "в конец файла" - тоже ничего "такого" не возвращает. И главное - насколько я понял в своё время - даже с ограничением 2GB fseek() вполне позволял fseek() куда угодно - ибо оно умело relative position - значит, нужно просто как-то "своими силами" отслеживать seek position и при необходимости делать кучу relative fseek().

-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Wed, Jul 14, 2004 at 09:07:22AM +0300, Victor Cheburkin wrote:

...

...

Это неправильно скомпиленный апач. Вообще гофоря, не факт - ибо поведение того же wget при получении "большого числа" - не предсказуемо. И так при таскании такого оно писать отрицательный размер и скорость начинает ;). Думаю, с кучей другого софта были бы те же проблемы, и послать "unspecified length" вместо числа - лучшее решение. Это зависит от автора что он имел ввиду под MAX filelength.

...

Но всё-таки, чего ж логгинг валился нафиг (работающий прочесс по достижении 2Гб падал) - не ясно. Точно так же, думаю, что fopen() для логов делается обычно в append mode - то есть, тоже нигде не светится seek position, ну или fseek() "в конец файла" - тоже ничего "такого" не возвращает.

Просто вместо fopen нужно делать fopen64, вместо fseek -- fseek64 и т.д. Если проги скомпилить без нужных дефайнов (их там два), то эти вызовы использоваться не будут -- тот же struct FILE явно не заточен под 64-битные указатели, а обычный fseek позовет обычный lseek, а не lseek64.

При нормально написанных исходниках рассчитанных на largefile делать такого ненадо. Это сделают за тебя libc. При наличии defines: _LARGEFILE_SOURCE Some more functions for correct standard I/O. _LARGEFILE64_SOURCE Additional functionality from LFS for large files. _FILE_OFFSET_BITS=N Select default filesystem interface. эти же define включаются автоматом при наличии define _GNU_SOURCE или _XOPEN_SOURCE >= 500. -- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Jul 13, 2004 at 11:50:32PM +0300, Paul Arakelyan wrote:

On Tue, Jul 13, 2004 at 12:24:46PM +0300, Alexandr D. Kanevskiy wrote:

...

On Mon, Jul 12, 2004 at 11:17:23PM +0300, Paul Arakelyan wrote:

...

Hi! А чего я нигде не встречал, что в http размер файла для нормальной работы с ним - 2GB? (ну, fseek() limitations - эт понятно, но в HTTP длина же в текстовом виде передаётся...). Или это бага апача? И что это за страшные лимиты в 2GB file size на ext3fs? Как люди с этим живут? (пример экстримов - лог дорастает до 2GB и сквид клеи ласты, а как в xDonkey "достать" файло на 3GB линуксоидам - ваще непонятно :) ).

Криво собранно приложение. В Linux и в glibc давным давно уже lseek 64bit'ный. На грабли я нарывался в логгинге в основном. Нафига работающему процессу вообще куда-то seek делать по логу? (Вопрос не в том, чтоб logs rotate). а кто говорит seek ? это вполне могут быть проблемы 32bit'ных функций fopen/fwrite/f*() в glibc. при включении LARGEFILE_SUPPORT это все автоматом уходит на f*64().

Хм - на разных линуксах на такое нарывался - apache from ensim, squid ( default - ./configure и "куда ставить"), vmware gsx 3.0. Это из того, на что я нарвался. "Тенденция, однако". Redhat7.x (httpd/ensim, squid), redhat 9.0 - vmware. squid ничего об этом не знает. полностью полагается на libc. Видать никто авторам squid'а об этом еще не писал :) решается одним define.

apache1 - там да, там грустно. apache2 - знает об largefile и ведет себя с ними корректно. (через apr библиотеку: .... adding "-D_XOPEN_SOURCE=500" to CPPFLAGS ....) wget-1.9.1 аналогично _XOPEN_SOURCE=500 имеет. т.е. потенциально более 2Gb файлы тоже должен понимать. xDonkey - на совести их писателей. Далее, судя по коду vsftpd на других операционках аналогичная картина: port/solaris_bogons.h: /* Safe to always enable 64-bit file support. */ #define _FILE_OFFSET_BITS 64 #define _LARGEFILE_SOURCE 1 #define _LARGEFILE64_SOURCE 1 sysutil.c: /* Activate 64-bit file support on Linux/32bit plus others */ #define _FILE_OFFSET_BITS 64 #define _LARGEFILE_SOURCE 1 #define _LARGEFILE64_SOURCE 1 .... sysdelutil.c: #if (defined(__FreeBSD__) && __FreeBSD__ >= 3) #define _FILE_OFFSET_BITS 64 #define _LARGEFILE_SOURCE 1 #define _LARGEFILE64_SOURCE 1 #endif Т.е. мелкое резюме - те кто пишет код нормально - они догадываются о многих вещах. Кто пишет под себя и только под свою длинну ручки грабель - тот пишет по другому. Угадывать что-же хотел пользователь libc не обязанна. -- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Wed, Jul 14, 2004 at 02:19:36PM +0300, Valentin Nechayev wrote:

Tue, Jul 13, 2004 at 23:50:32, unisol wrote about "[uanog] Re: HTTP and files over 2GB":

...

...

...

А чего я нигде не встречал, что в http размер файла для нормальной работы с ним - 2GB? (ну, fseek() limitations - эт понятно, но в HTTP длина же в текстовом виде передаётся...). [...]

...

На грабли я нарывался в логгинге в основном. Нафига работающему процессу вообще куда-то seek делать по логу? (Вопрос не в том, чтоб logs rotate).

Наверно основная проблема для него в stat() Да там вообще уже странности начались - сквид на кончание места начал ругаться, когда размер лога ~300M был (кэша - ~30M, раздел на ~20G). Когда ж найдётся злобный буратин... Я не думал, что аптайм там пару недель превысит, ну пару месяцев... А оно уже более полугода молотит - но вначале таких гляков не наблюдалось... (это в смысле аптайм такой).

-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message