[freebsd] Много файлов, тормоза ФС

[Pavel Astakhov]

Господа, а кто держит большие файлохранилища на фре? Досталось тут одно
хозяйство, веб-хайлоад, более 1.2Т картинок (>4М файлов), порядка 80qps
(все нормально разнесено по каталогам <1000 файлов), пробую перевести
сервер статики под топик - безбожные тормоза, gstat показывает задержки
порядка 40-60мс, на линупсе неправославном все работает нормально при
сравнимых дисках и их конфигурации. Что посоветуете покрутить?

[Vladislav V. Prodan]

1 февраля 2014 г., 0:34 пользователь Pavel Astakhov <ja...@jared.kiev.ua> написал:

Господа, а кто держит большие файлохранилища на фре? Досталось тут одно хозяйство, веб-хайлоад, более 1.2Т картинок (>4М файлов), порядка 80qps (все нормально разнесено по каталогам <1000 файлов), пробую перевести сервер статики под топик - безбожные тормоза, gstat показывает задержки порядка 40-60мс, на линупсе неправославном все работает нормально при сравнимых дисках и их конфигурации. Что посоветуете покрутить?

Самые главные вопросы - какая FS, какой RAID программный/аппаратный, какие диски.?

По какому протоколу отдаете? Через Апач?

Вот свежий пример хранилища на ZFS - Хабрасторадж, график сетевой загрузки:

http://habr.habrastorage.org/comment_images/a24/892/171/a24892171823f5ac40617f2c46da489b.png

 

У мну самое больше - на ZFS, двууровневое хранилище мелких файлов - овер 10к на директорию. Суммарно 80ГБ.

--
Vladislav V. Prodan            
System & Network Administrator
http://support.od.ua          
+380 67 4584408, +380 99 4060508
VVP88-RIPE

[Pavel Astakhov]

01.02.2014 00:44, Vladislav V. Prodan пишет:

> Самые главные вопросы - какая FS, какой RAID программный/аппаратный,
> какие диски.?
> По какому протоколу отдаете? Через Апач?

UFS, RAID аппаратный 1, диски SATA3 Seagate Constellation (на линуксовом
сервере конфигурация железа и рейда такая же). Протокол HTTP, отдаю
nginx+sendfile.

[Eugene Grosbein]

Для UFS и файлопомойки первым делом монтировать с noatime,
вторым делом мониторить vfs.ufs.dirhash_mem и когда оно приближается
к vfs.ufs.dirhash_maxmem, удваивать этот vfs.ufs.dirhash_maxmem.

[Anton Yuzhaninov]

В дополнение к тому, что написал Eugene Grosbein можно:

1. Собрать ядро с увеличенным MAXPHYS, например:
options MAXPHYS=(512*1024)

2. Увеличить vfs.read_max
sysctl vfs.read_max=256

3. А настройки аппаратного RAID такие же как были, NCQ он использует при
общении с дисками? Хотя для зеркала (RAID1) лучше вообще без аппаратного
рейда.

[Anton Yuzhaninov]

On 01.02.2014 02:47, Pavel Astakhov wrote:
> диски SATA3 Seagate Constellation

А на старом сервере модель дисков точно такая же?

Когда несколько лет назад работал в Рамблер-почте, мы несколько раз
пытались использовать SATA диски Seagate для хранения почты - на
синтетических тестах диски вели себя хорошо, а на той нагрузке, что была
в продакшене - работали раза в 2 медленнее, чем Hitachi (при сходных
характеристиках самих дисков - одинаковом размере кэша и т. д.).

Тесты проводили раза два или три с интервалом около года, с текущими на
тот момент дисками. Модели были разными - результат один и тот же. Такое
подозрение, что при определенном соотношении мелких и крупных запросов
софт в Seagate управляет диском неэффективно (или происходит
фрагментация памяти под буфер диска). При другом характере нагрузки диск
при этом может работать быстро.

Кстати, не написал ли кто geom-класс, пропускающий через себя все
запросы к диску, чтобы составить статистику по запросам, и потом на
основе этой статистики делать бенчмарки дисков?

[Vladislav V. Prodan]

2 февраля 2014 г., 18:58 пользователь Anton Yuzhaninov <cit...@citrin.ru> написал:

Кстати, не написал ли кто geom-класс, пропускающий через себя все запросы к диску, чтобы составить статистику по запросам, и потом на основе этой статистики делать бенчмарки дисков?

+1 реквестирую.

[Vladimir Sharun]

Добрый день,

fsck в случае чего может спокойно длиться много часов в случае крэша на UFS: на ext4 и прочих журналируемых под линуксом - аналогично, за исключением btrfs, но с ним плотно (пока) еще не работали. А еще в процессе fsck можно поймать какой-то паник или oom. Необязательно это будет питание (я про некондиционный shutdown), это может быть какая-то ядерная протечка и паник, паник при замене (отключении, выпадении) диска (бэкплейна) от контроллера, паник от некорректируемой ошибки в ECC, сетевухи тоже паничат :)

Проведенные исследования инхаус показали:
* у линукса самая быстрая и автотюнерная файловая система (ext4, btrfs), но ->
* у freebsd есть отличный zfs, но он драматически медленнее линуксов (на количестве файловых операций, там пока всё очень не ок, но в целом дле веба очень ок) но и настолько же надежнее их, хотя мы пока боремся с утечкой в L2ARC и компрессией: течет. сильно.
* zfs драматически тяжело "убить" + оно поднимается даже из самых жестоких крэшей как ни в чем не бывало. если не поднимается, zdb в руки.
* ufs - анахронизм, отказались от него

Подчеркну: получить некондиционный крэш - проще простого на любой системе (железо несовершенно, софт тоже), fsck может длиться бесконечно долго на ufs и в итоге можно получить в процессе fsck (хорошо еще если не в процессе repair'а) еще один крэш и потерять еще стопицот часов на downtime, копируя файлы со смонтированной RO FS. А еще во время fsck может вылететь диск и конрроллер может начать восстановление :-)

PS: raid - зло, от него больше проблем, чем пользы. Во время восстановления (инхаус) raid5 в половине случаев отказывает второй диск.

[Eugene Grosbein]

On 03.02.2014 13:44, Vladimir Sharun wrote:
> Добрый день,
>
> fsck в случае чего может спокойно длиться много часов в случае крэша на UFS: на ext4 и прочих журналируемых под линуксом - аналогично, за исключением btrfs, но с ним плотно (пока) еще не работали. А еще в процессе fsck можно поймать какой-то паник или oom. Необязательно это будет питание (я про некондиционный shutdown), это может быть какая-то ядерная протечка и паник, паник при замене (отключении, выпадении) диска (бэкплейна) от контроллера, паник от некорректируемой ошибки в ECC, сетевухи тоже паничат :)

fsck для UFS необязателен. ext4 - журналируемая fs, сравнивать её
с UFS с отключенным журналом нет смысла.

[Slawa Olhovchenkov]

On Mon, Feb 03, 2014 at 08:44:24AM +0200, Vladimir Sharun wrote:

> Добрый день,
>
> fsck в случае чего может спокойно длиться много часов в случае крэша на UFS: на ext4 и прочих журналируемых под линуксом - аналогично, за исключением btrfs, но с ним плотно (пока) еще не работали. А еще в процессе fsck можно поймать какой-то паник или oom. Необязательно это будет питание (я про некондиционный shutdown), это может быть какая-то ядерная протечка и паник, паник при замене (отключении, выпадении) диска (бэкплейна) от контроллера, паник от некорректируемой ошибки в ECC, сетевухи тоже паничат :)
>
> Проведенные исследования инхаус показали:
> * у линукса самая быстрая и автотюнерная файловая система (ext4, btrfs), но ->
> * у freebsd есть отличный zfs, но он драматически медленнее линуксов (на количестве файловых операций, там пока всё очень не ок, но в целом дле веба очень ок) но и настолько же надежнее их, хотя мы пока боремся с утечкой в L2ARC и компрессией: течет. сильно.

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

[Vladimir Sharun]

> fsck для UFS необязателен. ext4 - журналируемая fs, сравнивать её
> с UFS с отключенным журналом нет смысла.

Вы, вероятно, еще не сталкивались с ситуациями "журнал поврежден, необходим полный fsck".
В случае, когда журнал не поврежден, действительно, всё ок. Я говорю о ext4 и ufs/su+j.

[Eugene Grosbein]

В su+j сталкивался. На gjournal этого нет на практике.

[Eugene V. Boontseff]

А я и на gjournal сталкивался. Правда, там где разбиение разделов поверх
gjournal.

--
Eugene

[Vladimir Sharun]

> >> fsck для UFS необязателен. ext4 - журналируемая fs, сравнивать её
> >> с UFS с отключенным журналом нет смысла.
> >
> > Вы, вероятно, еще не сталкивались с ситуациями "журнал поврежден, необходим полный fsck".
> > В случае, когда журнал не поврежден, действительно, всё ок. Я говорю о ext4 и ufs/su+j.
>
> В su+j сталкивался. На gjournal этого нет на практике.

Ок, неск. моментов про ufs/gjournal:
1. на диск *всё* пишется дважды (если журнал не отдельный диск). если для мелких файлов проблем нет, то для гигабайтного контента - чувствуется, из-за этого в своё время отказался в пользу su+j (а потом уже - тотальный zfs)
2. файловая система неспособна к self heal'у и не может обнаружить ошибок чтения или записи блока (нет CRC)
3. всё еще возможна ситуация, требующая полного fsck (записалось случайно говнеца на какой-то диск в метадату: редко, но метко)

[Eugene Grosbein]

On 03.02.2014 16:05, Eugene V. Boontseff wrote:

> А я и на gjournal сталкивался. Правда, там где разбиение разделов поверх
> gjournal.

Так нельзя. gjournal рассчитан на отдельный журнал на каждую fs.

[Anton Yuzhaninov]

On 02/03/14 10:44, Vladimir Sharun wrote:

> fsck может длиться бесконечно долго на ufs и в итоге можно получить в
> процессе fsck (хорошо еще если не в процессе repair'а) еще один крэш и
> потерять еще стопицот часов на downtime, копируя файлы со смонтированной RO
> FS.

fsck длится бесконечно долго либо на FS с очень большим количеством очень мелких
файлов. Либо если взять N дисков и сделать из них одну большую FS на десятки
террабайт.
Такие задачи конечно бывают, но далеко не у всех.

У нас на большинстве серверов средний размер файлов около 10Мб, а размер одной
FS в пределах 1 Tb или 2 Tb - fsck конечно длится какое то время, но не
настолько долго, чтобы это напрягало (поэтому время и не засекал).

При таких ограничениях (на кол-во файлов и размер FS) UFS работает хорошо и не
жрет память гигабайтами в отличие от ZFS (размер ARC кэша можно уменьшать, но
хорошая производительность только с большим ARC кэшем).

Что же касается крэша в процессе fsck, то с таким не сталкивался больше чем за
10 лет использования UFS. Возможно мне повезло.

[Eugene V. Boontseff]

Я про это читал в рассылках уже после того, как сделал на домашней машине.
Но так и не понял, почему так нельзя. И где в документации сказано, что
так нельзя.
А изначально делал так потому что: на журнал рекомендуется ~ 3 размера
оперативный памяти.
Если у меня мирор из 2х дисков по 500 мб, 16 мб оперативки и три
достаточно больших раздела, чтобы сделать их журналируемыми, то на
журнал придется выделить 16Х3Х3 = 144 Мб - треть от всего - многовато.
А что делать, если ещё памяти добавить?)

--
Eugene

[Eugene Grosbein]

On 03.02.2014 16:30, Eugene V. Boontseff wrote:

> Я про это читал в рассылках уже после того, как сделал на домашней машине.
> Но так и не понял, почему так нельзя. И где в документации сказано, что
> так нельзя.

В документации это явно не сказано. Я спросил непосредственно у автора
и получил ответ.

> А изначально делал так потому что: на журнал рекомендуется ~ 3 размера
> оперативный памяти.
> Если у меня мирор из 2х дисков по 500 мб, 16 мб оперативки и три
> достаточно больших раздела, чтобы сделать их журналируемыми, то на
> журнал придется выделить 16Х3Х3 = 144 Мб - треть от всего - многовато.
> А что делать, если ещё памяти добавить?)

Суммарно на все журналы 3 размера оперативной памяти.
А вообще да, невыгодно делать больше одного высоконагруженного
раздела с gjournal. Дома у меня их два, но нагружен бывает только один.

[Eugene Grosbein]

On 03.02.2014 16:14, Vladimir Sharun wrote:

> Ок, неск. моментов про ufs/gjournal:
> 1. на диск *всё* пишется дважды (если журнал не отдельный диск). если для мелких файлов проблем нет, то для гигабайтного контента - чувствуется, из-за этого в своё время отказался в пользу su+j (а потом уже - тотальный zfs)

А в каких случаях бывает нужна настолько массированная линейная запись,
что вторая запись получается не в фоне, а синхронно?

> 2. файловая система неспособна к self heal'у и не может обнаружить ошибок чтения или записи блока (нет CRC)

Тут надо выбирать, или полнота фич, включая CRC, или скорость.

> 3. всё еще возможна ситуация, требующая полного fsck (записалось случайно говнеца на какой-то диск в метадату: редко, но метко)

Практически такого с gjournal на живом железе уже не бывает.
Возможно, зависит от тюнинга sysctl'ями.

[Eugene V. Boontseff]

On 03.02.2014 13:39, Eugene Grosbein wrote:

> On 03.02.2014 16:30, Eugene V. Boontseff wrote:
>
>> Я про это читал в рассылках уже после того, как сделал на домашней машине.
>> Но так и не понял, почему так нельзя. И где в документации сказано, что
>> так нельзя.
> В документации это явно не сказано. Я спросил непосредственно у автора
> и получил ответ.

Так что он ответил? Причина какая того, что так "делать нельзя"?

>
>> А изначально делал так потому что: на журнал рекомендуется ~ 3 размера
>> оперативный памяти.
>> Если у меня мирор из 2х дисков по 500 мб, 16 мб оперативки и три
>> достаточно больших раздела, чтобы сделать их журналируемыми, то на
>> журнал придется выделить 16Х3Х3 = 144 Мб - треть от всего - многовато.
>> А что делать, если ещё памяти добавить?)
> Суммарно на все журналы 3 размера оперативной памяти.

Так а что делать, если оперативку пришлось увеличить после того, как уже
создал журналы?)

> А вообще да, невыгодно делать больше одного высоконагруженного
> раздела с gjournal. Дома у меня их два, но нагружен бывает только один.
>
>

--
Eugene

[Eugene Grosbein]

On 03.02.2014 16:34, Anton Yuzhaninov wrote:

> Что же касается крэша в процессе fsck, то с таким не сталкивался больше чем за
> 10 лет использования UFS. Возможно мне повезло.

Креши в fsck бывают либо в background-режиме, либо в ранних версиях,
где в single user mode был низкий лимит на память для процессов
и на крупных файловых системах fsck не хватало памяти.

[Eugene Grosbein]

On 03.02.2014 16:44, Eugene V. Boontseff wrote:

>>> Я про это читал в рассылках уже после того, как сделал на домашней машине.
>>> Но так и не понял, почему так нельзя. И где в документации сказано, что
>>> так нельзя.
>> В документации это явно не сказано. Я спросил непосредственно у автора
>> и получил ответ.
> Так что он ответил? Причина какая того, что так "делать нельзя"?

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

>>> А изначально делал так потому что: на журнал рекомендуется ~ 3 размера
>>> оперативный памяти.
>>> Если у меня мирор из 2х дисков по 500 мб, 16 мб оперативки и три
>>> достаточно больших раздела, чтобы сделать их журналируемыми, то на
>>> журнал придется выделить 16Х3Х3 = 144 Мб - треть от всего - многовато.
>>> А что делать, если ещё памяти добавить?)
>> Суммарно на все журналы 3 размера оперативной памяти.
> Так а что делать, если оперативку пришлось увеличить после того, как уже
> создал журналы?)

Суть не в размере оперативки, а в интенсивности записи, сколько
данных может in-transit быть. Если характер этой нагрузки не сильно меняется,
можно ничего не делать.

[Anton Yuzhaninov]

background режим всегда отключаю. Кроме крешей с background хорошо проявляется
другой недостаток UFS - относительно дорогое создание снапшотов (особенно хорошо
заметно на больших FS - 1Tb и больше). Ну и пока работает background сервер,
который активно работает с диском, всё равно не будет работать достаточно быстро.

[Slawa Olhovchenkov]

ну последним двум пунктам zfs тоже подвержена, по большому счету

[Vasiliy P. Melnik]

3 февраля 2014 г., 11:54 пользователь Eugene Grosbein
<eu...@grosbein.net> написал:

> On 03.02.2014 16:44, Eugene V. Boontseff wrote:
>
>>>> Я про это читал в рассылках уже после того, как сделал на домашней машине.
>>>> Но так и не понял, почему так нельзя. И где в документации сказано, что
>>>> так нельзя.
>>> В документации это явно не сказано. Я спросил непосредственно у автора
>>> и получил ответ.
>> Так что он ответил? Причина какая того, что так "делать нельзя"?
>
> Не рассчитано на такое использование.

Ну да - мне тут говорили недавно, что на одном диске создавать
несколько zfs-пулов не хорошо. А оказалось, что только это меня спасло
от потери данных

[Slawa Olhovchenkov]

On Mon, Feb 03, 2014 at 01:34:45PM +0400, Anton Yuzhaninov wrote:

> On 02/03/14 10:44, Vladimir Sharun wrote:
>
> > fsck может длиться бесконечно долго на ufs и в итоге можно получить в
> > процессе fsck (хорошо еще если не в процессе repair'а) еще один крэш и
> > потерять еще стопицот часов на downtime, копируя файлы со смонтированной RO
> > FS.
>
> fsck длится бесконечно долго либо на FS с очень большим количеством очень мелких
> файлов. Либо если взять N дисков и сделать из них одну большую FS на десятки
> террабайт.
> Такие задачи конечно бывают, но далеко не у всех.
>
> У нас на большинстве серверов средний размер файлов около 10Мб, а размер одной
> FS в пределах 1 Tb или 2 Tb - fsck конечно длится какое то время, но не
> настолько долго, чтобы это напрягало (поэтому время и не засекал).
>
> При таких ограничениях (на кол-во файлов и размер FS) UFS работает хорошо и не
> жрет память гигабайтами в отличие от ZFS (размер ARC кэша можно уменьшать, но
> хорошая производительность только с большим ARC кэшем).

UFS и ZFS память жрут примерно одинаково. только в случае UFS никто не
говорит что это UFS память сожрала, а говорят "на кеш ушло". для
хорошей производительности размеры будт сопоставимы

[Anton Yuzhaninov]

On 02/03/14 14:21, Slawa Olhovchenkov wrote:
> UFS и ZFS память жрут примерно одинаково. только в случае UFS никто не
> говорит что это UFS память сожрала, а говорят "на кеш ушло". для
> хорошей производительности размеры будт сопоставимы

Разница в то, что память занятая кэшем на уровне VM отдается приложениям, при
необходимости (active/inactive/cache queue). А память которую однажды скушал ZFS
никому кроме ZFS уже не достанется (wired memory).

[Eugene Grosbein]

Тут другой случай. Тут конкретно разнос fs происходит однажды,
если поверх gjournal делать разбиение и несколько fs.
После ребута якобы fs чистая (fsck-то не отрабатывает),
а реально внутри ошибки и потом внезапные паники, когда система на эти ошибки
напарывается. Помогает только ручной fsck -y, но только до следующего раза.
Я через это всё проходил.

[Slawa Olhovchenkov]

отдается. я сам видел.

[Vasiliy P. Melnik]

3 февраля 2014 г., 12:41 пользователь Slawa Olhovchenkov
<s...@zxy.spb.ru> написал:

не всегда, вот например

last pid: 61066; load averages: 0.41, 0.64, 0.70
up
43+23:47:43 12:43:33
67 processes: 1 running, 66 sleeping
CPU: 2.5% user, 0.0% nice, 0.5% system, 0.0% interrupt, 97.0% idle
Mem: 824M Active, 844M Inact, 13G Wired, 137M Cache, 25M Buf, 669M Free
ARC: 12G Total, 723M MFU, 9939M MRU, 1440K Anon, 154M Header, 1137M Other
Swap: 1024M Total, 40M Used, 984M Free, 3% Inuse

[Slawa Olhovchenkov]

не противоречит. или ты про 40М в свапе?

[Volodymyr Kostyrko]

03.02.2014 12:47, Slawa Olhovchenkov написав(ла):

http://lists.freebsd.org/pipermail/freebsd-fs/2014-January/018864.html
http://lists.freebsd.org/pipermail/freebsd-fs/2014-January/018872.html

--
Sphinx of black quartz, judge my vow.

[Eugene V. Boontseff]

Кстати, да. Я тоже видел. Даже показать могу:
http://mail-stat.wdc.spb.ru/wdc.intranet/ss.wdc.intranet/memory.html
Это файл-сервер: там до 28 января в самбе был включен sendfile.
И днём smbd-процессам под это дело требовалось памяти.
Соответственно , днём, увеличивался active за счёт wired (и arc в точ
числе),
а ночью в спокойном состоянии почти вся память снова забиралась zfs.
После 28 sendfile был отменён и график выровняля. Но все-равно видно,
что во время дневной активности
wired сокращается, а active увеличивается.

--
Eugene

[Slawa Olhovchenkov]

на zfs sendfile смысла не имеет вообще.
т.е. у него и так смысла не очень много, а на zfs вообще нет.

[Eugene V. Boontseff]

Ну, так 28-го пришлось это понять :)

--
Eugene

[Eugene Grosbein]

On 03.02.2014 18:36, Slawa Olhovchenkov wrote:

> на zfs sendfile смысла не имеет вообще.

Почему?

> т.е. у него и так смысла не очень много, а на zfs вообще нет.

Смысл sendfile в уменьшении оверхеда на ненужные переключения контекста во-первых,
и на копирование данных из kernel space в user-space и обратно во-вторых,
и на mmap в третьих. Выигрыш вполне заметен, я замерял.

[Eugene Grosbein]

On 03.02.2014 18:36, Slawa Olhovchenkov wrote:

> на zfs sendfile смысла не имеет вообще.

Почему?

> т.е. у него и так смысла не очень много, а на zfs вообще нет.

[Slawa Olhovchenkov]

On Mon, Feb 03, 2014 at 09:49:29PM +0700, Eugene Grosbein wrote:

> On 03.02.2014 18:36, Slawa Olhovchenkov wrote:
>
> > на zfs sendfile смысла не имеет вообще.
>
> Почему?

потому что он не умеет напрямую в буфера ZFS/ARC и будет выполнять
копирование оттуда в свои буфера. а оверхед на сискол нынче на самом
деле довольно мал.

> > т.е. у него и так смысла не очень много, а на zfs вообще нет.
>
> Смысл sendfile в уменьшении оверхеда на ненужные переключения контекста во-первых,
> и на копирование данных из kernel space в user-space и обратно во-вторых,
> и на mmap в третьих. Выигрыш вполне заметен, я замерял.

нынче уже не копируется, оверхед на сискол тоже невелик на современных
процах.
на TCPшные таймеры мощи надо на порядки больше.

[Eugene Grosbein]

On 03.02.2014 22:12, Slawa Olhovchenkov wrote:
> On Mon, Feb 03, 2014 at 09:49:29PM +0700, Eugene Grosbein wrote:
>
>> On 03.02.2014 18:36, Slawa Olhovchenkov wrote:
>>
>>> на zfs sendfile смысла не имеет вообще.
>>
>> Почему?
>
> потому что он не умеет напрямую в буфера ZFS/ARC и будет выполнять
> копирование оттуда в свои буфера.

Всё равно на одно копирование меньше, иначе было бы два -
из kernel space в user space и обратно.

> а оверхед на сискол нынче на самом деле довольно мал.

Я бы так не сказал, он очень заметен. natd не ускорился резко.

>>> т.е. у него и так смысла не очень много, а на zfs вообще нет.
>> Смысл sendfile в уменьшении оверхеда на ненужные переключения контекста во-первых,
>> и на копирование данных из kernel space в user-space и обратно во-вторых,
>> и на mmap в третьих. Выигрыш вполне заметен, я замерял.
>
> нынче уже не копируется,

Где не копируется? Альтернатива sendfile'у это цикл с копированием или mmap.

> оверхед на сискол тоже невелик на современных
> процах.
> на TCPшные таймеры мощи надо на порядки больше.

Когда voluntary context switches начинают зашкаливать, это катастрофа.
sendfile от этого здорово помогает.

[Anton Yuzhaninov]

On 03.02.2014 19:12, Slawa Olhovchenkov wrote:
>> >Смысл sendfile в уменьшении оверхеда на ненужные переключения контекста во-первых,
>> >и на копирование данных из kernel space в user-space и обратно во-вторых,
>> >и на mmap в третьих. Выигрыш вполне заметен, я замерял.
> нынче уже не копируется, оверхед на сискол тоже невелик на современных
> процах.

И как данные из адресного пространства пользователя без копирования
попадают в адресное пространство ядра?

Overhead на syscall относительно небольшой, а на копирование есть.
Особенно если данных много.