ограничение файловой системы
Напомните мне плиз, какое ограничение в ext2 на размер файла.
Не 2Гига случаем?
Подписаться
Бесплатный дискуссионный лист
Подписчиков 995
За последние 60 дней ни разу не выходила
Сайт листа:
http://www.linuxrsp.ru
Открыт:
25-07-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.linux.discuss-list@subscribe.ru
Адрес
модератора: comp.soft.linux.discuss-owner@subscribe.ru
Модератор
Статистика
995 подписчиков
0 за неделю
0 за неделю
Ответы:
Konstantin Mitkinyh пишет:
Было такое ограничение в ядрах 2.0.XX. Начиная с 2.2.XX оно снято.
Другое дело, какими запросами ввода/вывода пользуется конкретная задача.
Если обычными (не 64-битными), то имеется такое ограничение независимо
от используемой файловой системы.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7868; Возраст листа: 314; Участников: 1153
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/162004
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
Hello Yuri,
Friday, June 4, 2004, 2:51:10 PM, you wrote:
Гмм..
Используется Redhut 6.2, ядро 2.4.17, в качестве приложения - Oracle8i
8.1.6 Думаю, запросы у него, как вы говорите, обычные. Видимо, в этом
всё дело.
А "имеется такое ограничение" - это сколько все-таки?
Konstantin Mitkinyh пишет:
Ограничение 32-битного числа со знаком: 2^31-1 = 2147483647. Т.е.
фактически 2Gb без одного байта.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7877; Возраст листа: 314; Участников: 1153
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/162148
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
i386-asplinux-linux)
И снова здравствуйте!
On Fri, 04 Jun 2004 16:47:43 +0300
"Yuri N. Glibovetz" <gyn***@m*****.ru> wrote:
Почему же без байта? Если считать от нулевого адреса, то как раз 2Gb и
получается.
Ivan Savochenko пишет:
А что по вашему для 2Gb файла должен вернуть lseek(fd, 0L, SEEK_END)?
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7896; Возраст листа: 315; Участников: 1155
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/162664
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
Max Vasin пишет:
Идем по порядку:
Размер файла = 0: lseek(fd, 0L, SEEK_END) = 0;
Размер файла = 1: lseek(fd, 0L, SEEK_END) = 1;
....
Размер файла = 2147483647: lseek(fd, 0L, SEEK_END) = 2147483647;
Размер файла = 2Gb: lseek(fd, 0L, SEEK_END) = ???
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7899; Возраст листа: 315; Участников: 1155
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/162682
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
И снова здравствуйте!
В своём сообщении от Sat, 05 Jun 2004 13:39:15 +0300
Yuri N. Glibovetz (aka "YNG") поведал:
и
Может мы говорим о разных вещах?
Я понимаю так:
- 1 килобайт = 2^10 = 1024 байт;
- 2 --"--"-- = 2^11 = 2048 байт;
[==8<--]
- 1 гигабайт = 2^30 = 1073741824 байт;
- 2 --"--"-- = 2^31 = 2147483648 байт.
Соответственно и вернуться должно 2147483648. Но вопрос был о другом. По
этому поводу "посыпаю голову пеплом", так как если ограничение и есть
2Gb, то размер файла может быть какой угодно, только не 2Gb
Hi, Yuri.
Вы писали 4 июня 2004 г., 17:47:43:
Только там используется long long, т.е. 64 битная адресация.
Адресация в файловой системе происходит блоками. Следовательно
увеличив размер блока увеличивается максимальный размер файла.
Вот цитата о лимитах из документации для ядер 2.4
Filesystem block size: 1kB 2kB 4kB 8kB
File size limit: 16GB 256GB 2048GB 2048GB
Filesystem size limit: 2047GB 8192GB 16384GB 32768GB
i586-asplinux-linux-gnu)
А что это за файл? Что в нем находится? Я предполагаю что, если
используются только функции open/read/write (без lseek), то
ограничения в 2G не влияет. Или я ошибаюсь?
Konstantin Korikov пишет:
read/write действительно не влияют. А вот выбор open/open64 влияет.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7897; Возраст листа: 315; Участников: 1155
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/162671
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
On Sat, 5 Jun 2004, Yuri N. Glibovetz wrote:
А где Вы нашли open64? В glibc? Потому, что в ядре такого нет.
Вот в `fs/open.c' оно само определяет на какой архитектуре работает:
...
long sys_open(const char * filename, int flags, int mode)
{
char * tmp;
int fd, error;
#if BITS_PER_LONG != 32
flags |= O_LARGEFILE;
#endif
...
Кстати, получается Linux не может работать ни на одной <32-разрядной
архитектуре, если у них в ядре такое ;-)
Кстати об lseek. Тут вообще забавный код:
...
loff_t generic_file_llseek(struct file *file, loff_t offset, int
origin)
{
long long retval;
switch (origin) {
case 2: /* вот здесь */
offset += file->f_dentry->d_inode->i_size;
break;
case 1: /* и здесь */
offset += file->f_pos;
}
...
Да и вообще в `read_write.c' полнейший бред с long/off_t/loff_t и
unsigned/[signed] int. Сами посудите:
off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)
^^^^^ ^^^^^^^^^^^^
вызывает (со своими же параметрами):
loff_t llseek(struct file *file, loff_t offset, int origin)
^^^^^^ ^^^
Вот еще штука:
#if !defined(__alpha__) /* а че там с альфой не так, кто нам скажет? */
long sys_llseek(unsigned int fd, unsigned long offset_high,
unsigned long offset_low, loff_t * result,
unsigned int origin)
Чего куда здесь коннектится вообще хрен поймешь... Помойка короче :-)
Хоть комментарий бы написали, что ли...
Mike Belopuhov пишет:
/usr/include/fcntl.h
Интересно. Получается что можно использовать обычный open, добавив в
flags "|O_LARGEFILE". Надо будет попробовать. Хотя не знаю, правильно ли
это идеологически.
А смысл?
Вообще-то origin - это:
#define SEEK_SET 0
#define SEEK_CURR 1
#define SEEK_END 2
Да, здесь некрасиво, но преобразовать 0, 1, 2 из unsigned int в int
несмертельно.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 7937; Возраст листа: 317; Участников: 1160
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/163947
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
On Mon, 7 Jun 2004, Yuri N. Glibovetz wrote:
Это от glibc.
Это будет идеологически неправильно, если Вы пишите переносимый софт.
O_LARGEFILE заморочка линуксовская.
Но и в программах ориентированных на Linux тоже не стоит этим
пользоваться из-за того, что это не стандарт и в любой момент они
легко могут изменить ситуацию.
Также, мне кажется, не надо особо думать об open/open64. OC сама
должна обрабатывать такую ситуацию, ведь никто не знает, где будет
собрана и использована программа.
И еще: open64 это тоже только в glibc и посему также непереносимо
(но уже в плане исходников). А использовать libtool и auto{conf,make}
и заявлять, что это обеспечивает максимальную портабельность исходного
кода (как делает подавляющее большинство GNU программистов) вообще
неприемлимо.
Да в общем никакого, просто интересно :-)
[skip]
[skip]
В таких делах лучше быть параноиком :-]
i586-asplinux-linux-gnu)
В сообщении от Mon, 7 Jun 2004 22:34:36 +0400 (MSD) Вы написали:
А чем плох такой код?
#include "../config.h"
....
#ifdef ENABLE_LARGE_FILE
fd = open(filename, O_RDONLY | O_LARGEFILE);
#else
fd = open(filename, O_RDONLY);
#endif
....
Скрипт configure определит (сам или при помощи пользователя) есть
ли в системе O_LARGEFILE, если есть то в config.h будет:
#define ENABLE_LARGE_FILE 1
Чем плох такой подход?
Mike Belopuhov пишет:
Можно конечно задать в флагах gcc -D_FILE_OFFSET_BITS=64 и тогда по
умолчанию будут использоваться 64-битные варианты функций. Но не люблю я
такую "игру в темную" - обязательно где-то вылезет. Хотя с точки зрения
переносимости конечно это выход.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 8028; Возраст листа: 318; Участников: 1164
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/165029
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
Hi, Mike.
Вы писали 5 июня 2004 г., 20:02:30:
glibc в любом случае не предоставляет системных вызовов :-)
Ну разумеется. На архитектурах <32 нет защищенного режима.
On Mon, 7 Jun 2004, Nekipelov Alex wrote:
А в чем проблема его реализовать на <32 битной архитектуре? Другое
дело, что вроде как никто не делал (и не будет).
Mike Belopuhov wrote:
Проблема в режиме работы процессора. Защищенный режим в процессорах
появился только начиная с i386. Это, если речь идет о PC -архитектуре.
Для других "слабых" и <32 разрядных, и процов без "защищенного режима",
естественно, были порты ядра и ранее, а с 2.6 и стандартное ядро может
быть собрано для таких процессоров.
-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 8004; Возраст листа: 318; Участников: 1164
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/164751
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.discuss--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
Hello Konstantin,
Saturday, June 5, 2004, 2:08:15 AM, you wrote:
Файл базы данных. Думаю вы ошибаетесь, т.к. файл более 2 Гиг создать
не удалось ;-) Это обходится элементарно, просто наш DBA спросил
почему, а я что-то затруднился с ответом.
On Пятница 04 Июнь 2004 10:52, Konstantin Mitkinyh wrote:
Documentation/filesystems/ext2.txt:
Filesystem block size: 1kB 2kB 4kB 8kB
File size limit: 16GB 256GB 2048GB 2048GB
Filesystem size limit: 2047GB 8192GB 16384GB 32768GB