Минимальная единица объема информации для записи в файл

Книжку не читал, но в моей glibc 4 кБайт это размер буфера по умолчанию

а где это прописано?

То есть сброс буфера это не управление? А вобще, ″man setvbuf″.

согласен, я ошибся. Забыл совсем про setvbuf...

man mke2fs, в районе -b block-size

-b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically deter- mined by the filesystem size and the expected usage of the filesystem (see the -T option). If block-size is preceded by a negative sign ('-'), then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for certain hardware devices which require that the blocksize be a multiple of 2k.

слышь, пернатое, где ты увидел слово «кластер»?? Или твой ман надмозг-ГСМ переводил? Плюнь ему в рожу, и объясни, что слово block переводится на русский как БЛОК, а «кластер» это совсем другое слово.

Мне кажется или пятница дает о себе знать. Обезьянки, совы и ослики никак не могут ужиться. Про кластер я знаю, и знаю что это минимальная логическая единица емкости на блочном устройстве. И если у меня будет файл в 1 байт то все равно на устройстве он занимает у меня 1 кластер=в большинстве случаев это 4096 байт (4 килобайт). Но речь не об этом, господа. Мне кажется emulek более всего близок к ответу, пока вы там фекалиями кидайтесь.

вывода в файл по умолчанию 1 кБайт

но означает ли что в файл не будет ничего записано пока «в буфере» (если это можно так назвать) не наберется этот 1 килобайт? Но выше опять таки говорилось про POSIX, и там речь идет об 1 байте.

У fat и ntfs он кластером называется, в линуксовых фc - блоком, но суть от этого не меняется, хоть ты его дерижаблем назови.

Пока не сделаешь sync или close, ничего туда не запишется, тебе это и пытаются сказать.

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

Один байт. Если меньше размера буфера - тоже один байт, но физически запись в файл на фс произойдёт не сразу после команды вывода, а чуть пожже. Так понятнее?

В контексте книжки и работы сис.админа данное предложение лишь означает, что парсер логов (других файл-отходов) программы не стоит делать в режиме real time. Но больше всего это касается пайпов. Хотя ни перл, ни баш, ни что-то еще из готовых утилит не имеют с данным поведением особых проблем. Действительно, чем меньше знаешь, тем крепче спишь.

но означает ли что в файл не будет ничего записано пока «в буфере» (если это можно так назвать) не наберется этот 1 килобайт?

и да, и нет. Зависит от того, КАК открыт этот файл. Если ты его открыл с O_SYNC, то в файл запишется 1 этот байт и ещё 4095 байтов мусора. А если без O_SYNC, то будет ждать, пока наберётся 4096 байт.

Но выше опять таки говорилось про POSIX, и там речь идет об 1 байте.

ну ты всегда можешь записать один байт нужной информации. А ещё у тебя запишется 4095 байтов ненужной ерунды, если ты в Linux. В твоей книжке всё правильно написано. И со стандартом нет никаких противоречий: ты МОЖЕШЬ записать 1 байт. А про побочные эффекты там просто не сказано. Я и твоя книжка про это тебе рассказываем, а если не веришь — читай мануалы.

Да, про маздай я не в курсе.

А ещё у тебя запишется 4095 байтов ненужной ерунды

помнится, была какая-то ФС, которая умела блоки между файлами делить. Или она уже давным-давно канула в Лету?

У fat и ntfs он кластером называется, в линуксовых фc - блоком, но суть от этого не меняется, хоть ты его дерижаблем назови.

уважаемый, здесь вам не винфак, и ссылку вы мне дали на man mke2fs, а не на FORMAT \?. Извольте выражаться грамотно, а то я вас просто не понимаю.

В контексте книжки и работы сис.админа данное предложение лишь означает, что парсер логов (других файл-отходов) программы не стоит делать в режиме real time.

можно. Просто нужно знать, КАК работает эта ваша буферизация. УМВР. А следовательно я — знаю.

Но больше всего это касается пайпов. Хотя ни перл, ни баш, ни что-то еще из готовых утилит не имеют с данным поведением особых проблем. Действительно, чем меньше знаешь, тем крепче спишь.

там головняк действительно именно с пайпами, но вот сам по себе буфер — это не слишком большая проблема. Проблема возникает тогда, когда два процесса начинают писать в один файл _одновременно_ (только не надо вставлять «не нужно», что с логом-то делать, расскажешь?)

помнится, была какая-то ФС, которая умела блоки между файлами делить. Или она уже давным-давно канула в Лету?

ЕМНИП это же райзерФС, только с хвостами!

notail By default, reiserfs stores small files and `file tails' directly into its tree. This confuses some utilities such as LILO(8). This option is used to disable packing of files into the tree.

Было недавно тут: используй npipe, file lock

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

но означает ли что в файл не будет ничего записано пока «в буфере» (если это можно так назвать)

Вы пытались разобраться с тем скриптом, который я привёл? Что он делает и почему даёт такой вывод?

то все равно на устройстве он занимает у меня 1 кластер=в большинстве случаев это 4096 байт (4 килобайт)

Вам нужно определится, с каким уровнем абстрации вы собрались разбираться. И учить соотв. матчасть, ибо, у вас там в голове какая-то каша про кластер. Вобщем то вам уже написали, что не кластер, а блок, что его размер обычно можно задать при создании ФС, и что некоторые ФС, например, райзер могут хранить данные двух файлов в одном блоке.

Есть прикладной уровень абстракции, страндартизированный POSIX'ом, там есть прямая запись в файл write() и потоковая fwrite(). Есть блочное устройство и драйвер файловой системе в ядре, который пишет блоками. Есть драйвер блочного устройства (НЖМД, допустим), который пишет секторами (или группами секторов). Есть микроконтроллер на жёстком диске, со своим дисковым кешем, который может писать данные своими блоками (на SSD нельзя переписать один байт или сектор, и на НЖМД давно аналогичная ситуация).

буферов там несколько уровней.

1. буфер приложения (точнее, буфер libc) - fwrite пишет в него. Поэтому kill приложения, которое сделало fwrite и не сделало fflush, обычно приводит к неожиданным последствиям.

2. буферы VFS. Когда дело доходит до реального write (man 3 write), данные попадают в кэши VFS. Собственно, write может быть на любой размер - не только кратным размеру блока, и если write не выровнен по границе блока (а он весьма редко выровнен), делается read всех задействованных блоков, запись в кэш и пометка блоков кэша как «грязного». Но таки да, kill после write не приводит к потере данных. А отрубание питания - приводит.

Собственно запись на диск делает только cоответствующая ядерная нить.

P.S.: да, есть ещё O_DIRECT, который в принципе минует VFS, работая напрямую с ФС. Но у него write должен быть выровнен по 512 байтам, и это вообще отдельный случай.

В исходниках glibc, реализующих потоковый вывод в файл. В файле libio/filedoalloc.c :

  size = _IO_BUFSIZ;
  if (fp->_fileno >= 0 && __builtin_expect (_IO_SYSSTAT (fp, &st), 0) >= 0)
    {
      if (S_ISCHR (st.st_mode))
        {
          /* Possibly a tty.  */
          if (
#ifdef DEV_TTY_P
              DEV_TTY_P (&st) ||
#endif
              isatty (fp->_fileno))
            fp->_flags |= _IO_LINE_BUF;
        }
#if _IO_HAVE_ST_BLKSIZE
      if (st.st_blksize > 0)
        size = st.st_blksize;
#endif
    }
  ALLOC_BUF (p, size, EOF);
  INTUSE(_IO_setb) (fp, p, p + size, 1);
  return 1;

ALLOC_BUF это и есть выделение буфера по умолчанию (потом он может быть переопределён через setvbuf) размером size. size в начале принимает значение _IO_BUFSIZ (равное 8 кБайт, определяется в файле libio.h), а потом переопределяется через размер блока файловой системы. st.st_blksize это поле структуры stat, возвращемой функцией fstat().

Для терминала st.st_blksize равен 1 кбайт, для большинства ext4fs равен 4 кбайт.

Было недавно тут: используй npipe, file lock

а я и без этого справился. Где-то в манах нашёл, что запись 512 гарантированно атомарная. Мне 512 байт вполне хватает, и потому УМВР. Ничего не перепутывается. А flock(2) это ИМХО тормоза (хотя я и не углублялся в эту тему)

полностью согласен, два уточнения:

райзер могут хранить данные двух файлов в одном блоке.

там, как я понял, ещё круче, прямо в дереве можно короткие файлы хранить. Т.е. типа как в инодах EXT4 (кстати в инодах EXT4 это отключено для простых файлов). И да, мегабакс ЕМНИП говорил, что лучше НЕ юзать эту фичу для райзера.

на SSD нельзя переписать один байт или сектор, и на НЖМД давно аналогичная ситуация

на НЖМД и на флопиках такое изначально. Как и на ленте. Ну и на флешках. На NAND так вообще конструктивно можно писать только по очень хитрым схемам, а не как хочется. Т.ч. по одному байту с такой сложной топологией и не получится. Только страницами, обычно тоже по 4К.

ага, спасибо.