Hi! А чего я нигде не встречал, что в http размер файла для нормальной работы с ним - 2GB? (ну, fseek() limitations - эт понятно, но в HTTP длина же в текстовом виде передаётся...). Или это бага апача? И что это за страшные лимиты в 2GB file size на ext3fs? Как люди с этим живут? (пример экстримов - лог дорастает до 2GB и сквид клеи ласты, а как в xDonkey "достать" файло на 3GB линуксоидам - ваще непонятно :) ). -- 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
Hi! On Mon, Jul 12, 2004 at 23:17 +0300, Paul Arakelyan wrote:
А чего я нигде не встречал, что в http размер файла для нормальной работы с ним - 2GB? (ну, fseek() limitations - эт понятно, но в HTTP длина же в текстовом виде передаётся...). Или это бага апача?
Это неправильно скомпиленный апач.
И что это за страшные лимиты в 2GB file size на ext3fs? Как люди с этим живут? (пример экстримов - лог дорастает до 2GB и сквид клеи ласты, а как в xDonkey "достать" файло на 3GB линуксоидам - ваще непонятно :) ).
Давно уже нет никаких лимитов, это инфа времен ядра версии 2.0 (хотя я уже не понмю, давно это было). Проблема в том, что в отличие от Фри в Линуховой libc есть два варианта вызовов -- один для работы с файлами до 2-х гиг (32-х битный) а второй -- 64-х битный. И вот если при компиляции сказать указать пару дефайнов, то все будет нормально, а если нет -- лимит в 2ГБ. -- Victor Cheburkin VCW61, VC319-RIPE, VC1-UANIC =================================================================== 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 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
Hi! On Wed, Jul 14, 2004 at 00:11 +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 кажись.
Начиная с 2.2 это значения не имеет, а может и раньше -- уже не помню.
Проблема в том, что в отличие от Фри в Линуховой libc есть два варианта вызовов -- один для работы с файлами до 2-х гиг (32-х битный) а второй -- 64-х битный. И вот если при компиляции сказать указать пару дефайнов, то все будет нормально, а если нет -- лимит в 2ГБ. То ли "об этом никто не знает", то ли просто не заморачивались.
Об этом знают все, кто этим занимается ;-)
Но всё-таки, чего ж логгинг валился нафиг (работающий прочесс по достижении 2Гб падал) - не ясно. Точно так же, думаю, что fopen() для логов делается обычно в append mode - то есть, тоже нигде не светится seek position, ну или fseek() "в конец файла" - тоже ничего "такого" не возвращает.
Просто вместо fopen нужно делать fopen64, вместо fseek -- fseek64 и т.д. Если проги скомпилить без нужных дефайнов (их там два), то эти вызовы использоваться не будут -- тот же struct FILE явно не заточен под 64-битные указатели, а обычный fseek позовет обычный lseek, а не lseek64.
И главное - насколько я понял в своё время - даже с ограничением 2GB fseek() вполне позволял fseek() куда угодно - ибо оно умело relative position - значит, нужно просто как-то "своими силами" отслеживать seek position и при необходимости делать кучу relative fseek().
Отслеживать seek position это конечно хорошо, но зачем, если можно перекомпилить прогу с двумя дополнительными дефайнами и все будет работать? -- Victor Cheburkin VCW61, VC319-RIPE, VC1-UANIC =================================================================== 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 Wed, Jul 14, 2004 at 09:07:22AM +0300, Victor Cheburkin wrote:
Hi!
сказать указать пару дефайнов, то все будет нормально, а если нет -- лимит в 2ГБ. То ли "об этом никто не знает", то ли просто не заморачивались.
Об этом знают все, кто этим занимается ;-) Видать немного народу страдает экстремистскими наклонностями :)
Просто вместо fopen нужно делать fopen64, вместо fseek -- fseek64 и т.д. Если проги скомпилить без нужных дефайнов (их там два), то эти вызовы использоваться не будут -- тот же struct FILE явно не заточен под 64-битные указатели, а обычный fseek позовет обычный lseek, а не lseek64. С fseek() - понятно, но зачем гробить полностью возможность записать файл >2GB....
То есть, вариант типа gzcat something>file не отличался работоспособностью (ну, это если tcsh/bash ещё пересобирать - то так вообще свой дистрибутив наверно сразу нужно делать...)
Отслеживать seek position это конечно хорошо, но зачем, если можно перекомпилить прогу с двумя дополнительными дефайнами и все будет работать? Примеров для линукса, когда "не получится" - вагон - особенно в области коммерческого софта (а в vmware для такого есть опция - "бить на файлы по 2Гб" - вот только готовую VM с файлом >2GB фиг получалось даже распаковать.
-- 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 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'ный. -- 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 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).
Хм - на разных линуксах на такое нарывался - apache from ensim, squid ( default - ./configure и "куда ставить"), vmware gsx 3.0. Это из того, на что я нарвался. "Тенденция, однако". Redhat7.x (httpd/ensim, squid), redhat 9.0 - vmware. -- 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 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
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() -netch- =================================================================== 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
participants (4)
-
Alexandr D. Kanevskiy -
Paul Arakelyan -
Valentin Nechayev -
Victor Cheburkin