Dimitry SibiryakovА мозгом почитать что такое блок ФС и как он используется?..
Поставишь меньше - получишь оверхэд по иопсам. Поставишь больше - по объёму в/в.

AFAIK там все очень сложно

если RAID, то есть блоки RAID, есть выравние логического раздела на диске, если размер кластера ФС (что такое блок ФС мне не очень понятно),есть размер блока СУБД, есть multi-block-read (в Oracle, думаю в PostgreSQL аналогично).

Прямой зависимость блок СУБД == сектор на диске, все равно нету (((

Есть ощущение, что для целей, которые ставил перед собой автор вопроса, ответ "несущественно" (C) Siemargl вполне правильный

AFAIK

Dima Tsstatisticпропущено...
Ну хорошо, понятно что 8 лучше чем 4.
Но какие минусы, если сделать, например, 64 ?
21678100 лишний в/в
БД запишет 8, а ОС будет писать 64.
Для этого хорошо ссылку на RTFM, что размер кластера == размеру операции ввода/вывода

Честно говоря, лично я, в этом совсем не уверен

p.s. Про SSD, вообще можно не говорить ))), Раздумей над strip size в RAID и выравнивания партиций ))) вполне достаточно, что бы мозги вспухли. IMHO & AFAIK

Dima TА чтение ОС делает кластерами, поэтому зачем читать лишнее?....
да и пофиг. Для магнитного жесткого диска, что прочитать сектор, что прочитать дорожку/цилиндр - однофиолетово. А размер дорожки на современных дисках, дофига. Главное, что бы головка не дергалась )))

Про SSD обсуждать не готов )))

В общем, все сложно.

AFAIK & IMHO

Dima TНасколько я знаю связные страницы (например одной таблицы) в БД редко идут последовательно друг за другом.

Например Oracle выделяет место под таблицами не блоками, а экстендами/сегментами. Они значительно больше блока Т.ч. ряд связных страниц часто идут последовательно.

Multi block count в Oracle под Windows AFAIK обычно около 1 Mb (размер атомарной операции ввода/вывода которое Oracle Co. считает оптимальной).

Dimitry SibiryakovЯ был в этом уверен ещё со времён DOS

А я со времен DOS в этом не уверен. Т.к. параметр buffers в config.sys всю жизнь задавался в секторах и никакого отношения к размеру кластера никогда не имел )))

Dimitry Sibiryakov многа
букафф от Руссиновича , эту уверенность потерял.

Вскольз просмотрел. Ничего существенного к данной дискуссии - не вижу (((

1. Есть упоминание про "Drivers commonly use buffered I/O when callers transfer requests smaller than one page (4 KB on x86 processors) or when the device does not support DMA."
Зависимость работы от размера memory page (никак не от кластера ФС) + косвеннная информация о том, что один физический requests может быть меньше 4 K.

2. Опять таки, memory mapped files. Сомневаюсь, что их работа как-то с размером кластера связана.

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

Ну и повторюсь еще раз, на практике , оптимальный размер операции ввода-вывода от СУБД к ОС, сильно больше и размера кластера и размера блока СУБД. (По мнению Oracle Co. на Windows около 1 Mb). AFAIK

Т.ч. ответ "несущественно" самое то. IMHO

Buffered I/O The I/O manager allocates a buffer in nonpaged pool of equal size to
the caller’s buffer . For write operations, the I/O manager copies the caller’s buffer
data into the allocated buffer when creating the IRP.


А callers это кто?

Ничего про размер блока для IO и его зависимости от размера кластера в данной статье не вижу.

Dima TНе надо многоточий. Я вместо них писал что излишнее чтение ведет к излишнему кэшированию прочитанного. Память не резиновая.
Читать по одному сектору/блоку не эффективно (Oracle под Windows старается по 1Mb работать).

Для СУБД вообще кэширования в ОС не эффективно.

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

"Память не резиновая" применительно к СУБД и кэшу - не верное утверждение. Памяти под кэш как раз должно быть достаточно, что бы закешировать используемую/ые таблицы/индексы. Обычно нормальное hit-ration для СУБД значительно больше 95 - 98 %. Экономия байтов разницы не сделает. А пенальти от IO, вполне себе может сказаться.

Т.ч. применительно к PostgreSQL, "излишнее кэширование" это плохо или хорошо - вопрос вообще дискуссионный.