The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes.

не оно.

должна поддерживать файловая система

фс ext3

в гугле: ext3 2gb
(large file support ?)

и чего? коню понятно что support.
речь про *>2Gb за один вызов write()*

Даже, если оно вдруг и позволяет, то не факт, что оно у тебя за раз действительно прочитает/запишет. Ты ведь не сможешь заставить пыхтеть вызов, пока он тебе 2 гига не испишет?

если оно *вдруг позволяет* то код будет проще в 5 раз. Пока приходится писать 10 Гб файл за 5 приёмов с помощью pwrite64()

На Lenny, 32-битовом ядре 2.6.32 - нет.

#include <fcntl.h>
#include <errno.h>

int main()
{
        int fd = open("/dev/zero", O_RDONLY);
        char *t = malloc(1024*1024*1024*2u+1024);

        printf("%p\n", t);
        errno = 0;
        read(fd, t, (size_t)(1024*1024*1024*2u));
        perror("read");
}

0x3762b008
read: Invalid argument

Если поставить размер чтения на 1024 меньше, начинает работать.

спс. интересно то же самое для 64 бит посмотреть для полной ясности вопроса.

>read(fd, t, (size_t)(1024*1024*1024*2u));

ясен пень тут же каститнг явный и не явный к size_t который 32 бит в 32 битной системе

#define _LARGE_FILE_API

нужно просто использовать

>#define _LARGE_FILE_API

cиё актуально только для 32-бит систем для доступа к *64() версиям функций. В 64-бит системах это просто алиасы на дефолтовые функции.

у меня read возвращает 2147479552 байт

>>если оно *вдруг позволяет* то код будет проще в 5 раз. Пока приходится писать 10 Гб файл за 5 приёмов с помощью pwrite64()

А где гарантия, что оно именно за один прием запишет? Все равно придется проверять и дописывать в случае необходимости.

Посмотри в ядре условие, почему нельзя больше. Время, конечно, придется потратить. %)

> ясен пень тут же каститнг явный и не явный к size_t который 32 бит в 32 битной системе

Ясен пень, что беззнаковый 32-битный целый тип позволяет задать размер до 4 гигабайт.

>у меня read возвращает 2147479552 байт

uname -a ?

>Посмотри в ядре условие, почему нельзя больше. Время, конечно, придется потратить. %)

Лень :) Если мне склероз не изменяет там была заглушка в sendfile()

s/заглушка в sendfile()/заглушка, связанная с sendfile()/

спс, значит пока не выпилили из актуальных этот лимит. Вопрос закрыт.

>Ясен пень, что беззнаковый 32-битный целый тип позволяет задать размер до 4 гигабайт.

может внутри size_t к long int приводиться

>если оно *вдруг позволяет* то код будет проще в 5 раз.

write в любом случае не гарантирует запись всего объева за раз

write в любом случае не гарантирует запись всего объева за раз

Случаи негарантирования рассмотрены в первом каменте. Все они гарантируют незапись вообще (недописанный образ в моём случае не имеет смысла вообще)

PS: Собственно вопрос возник при перетряхивании старого кода где синк огромного образа задачи разбит на два случая:

1) Данных > 2Gb 2) Данных < 2Gb

Во втором случае кода в 5 раз меньше.

PS: Собственно дело в

/*
 * rw_verify_area doesn't like huge counts. We limit
 * them to something that fits in "int" so that others
 * won't have to do range checks all the time.
 */
#define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)

>если оно *вдруг позволяет*
даже если и так, рассчитывать на это - верх криворукости.

>даже если и так, рассчитывать на это - верх криворукости.

Я смотрю тут телепаты подтянулись :)

>write в любом случае не гарантирует запись всего объева за раз

Была вроде длительная дискуссия по этому поводу.

http://www.linux.org.ru/jump-message.jsp?msgid=4719110&cid=4723447

Пришли вроде к выводу, что если пишем в обычный файл на диске, то гарантируется запись за один раз.

Поправьте если что не так.

О при открытии и/или записи разве не нужно указывать | O_LARGEFILE, чтобы смещения были 64-битными?

open64() для открытия файла попробуй. Или я не о том?

>О при открытии и/или записи разве не нужно указывать | O_LARGEFILE, чтобы смещения были 64-битными?

это туда же http://www.linux.org.ru/jump-message.jsp?msgid=5057918&cid=5059207

Понял, сорри за дезинформацию

>Поправьте если что не так.
там про прерывание сигналом,а я о том что когда ты говоришь write() записать скажем 100 байт - совершенно не факт что они запишутся за один раз. могут записаться 10 байт например и придется еще раз вызвать write() который в это раз например запишет 80 байт и придется еще раз вызвать write() который например запишет 10 байт - и того 100 байт записались за три вызова write() или за один или за сто - никто не знает сколько их потребуется.

Приветствую

А такой вариант пробовали:
%getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
%gcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ...

?

>А такой вариант пробовали:

Это ровно по предыдущей ссылке. Я таки залез в ядро (не последнее но более менее актуальное) и привёл ниже MAX_RW_COUNT

>там про прерывание сигналом,а я о том что когда ты говоришь write()

Там именно про то, что если пишешь блок данных в регулярный файл, то он либо запишется целиком, либо произойдет критическая ошибка. А ситуация с записью данных кусками невозможна. Т.е. эта операция будет атомарна.

Вот у сокетов и COM-портов ситуация иная.

>там про прерывание сигналом,а я о том что когда ты говоришь write() записать скажем 100 байт - совершенно не факт что они запишутся за один раз

Шаман-вендузятнег ? :) У любого явления есть *причины*.

>У любого явления есть *причины*.

правда? write() может работать так как я описал, не учитывать это - все равно что не учитывать коды возврата