Новый системный вызов fallocate()

> Умный, бешеная фрагментация началась в Линаксе?

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

Простите что вмешиваюсь, кто там мне на linuxfest говорил что "проблемы фрагментации под unix никогда не было"? :). Сегодня смотрел как 2.5ТБ раздел при 100% iowait еле-еле 7мб в секунду выдавал. При том что rawspeed была в районе 90мб в секунду(raid в pci32 воткнут).

Reiser - это всё-таки reiserFs или Reiser4? Судя по тестам, подразумеваю, что reiserФС. А NTFS в печь.

>Cудя по работе Bittorrent могу сказать, что NTFS полный сакс, Reiser тоже. XFS быстрее райзера в два раза примерно.

Судя по работе MTA могу сказать, что XFS сакс by design, reiser быстрее раза в 3, минимум.

> Умный, бешеная фрагментация началась в Линаксе?

> Сам понял что сострил?

> ansi (06.08.2007 17:23:51)

Смысл в другом - у Линукса в этом минимальная надобность даже сейчас, поэтому её и не было так долго. Хотя, за долгое время работы с Линуксом, получал один раздел с фрагментацией 15-25% за два года (буфер для бэкапов на 15GB).

fallocate добавили в Linux в основном из-за специфики работы Офтопика и отсутствия на нем файлов с дырками и прямого механизма предаллокации:
Недавно Интел провело тестирования записи stream video по samba на различные OS. И на недолгую радость Отопиколагетам Linux слил в одном test Case "на записи и многократном чтении одного файла". Стали разбираться оказалось что Офтопик "fallocate ХАК=seek(N)+write(0)" под нормальными UNIX приводит к появлению дырок в файле в результате происходит бешенная фрагментация: средний размер фрагмента под Linux оказался в сотни раз меньше чем под Офтопик. Вот поэтому и решили побыстрее заделать эту несуразность в samba server с помощью fallocate.
BTW когда в записывающем софте выклюсили ОфтопХАК все встало на свои места, при любом варианте тестовой навгрузки Офтоп + Samba сливал Linux минимум в 2 раза.

> кое в чем линаксу еще долго догонять винду ( многоуровневая архитекткра i/o, полностью асинхронный i/o aka completion ports, асинхронный i/o cancelation и т.п. ). забавно, однако все это было уже в NT-4.0, а может и раньше. забавно, но ребятам из IBM и Oracle-а пришлось в свое время изрядно попотеть чтобы убедить г.н.-а
Может быть но это точно не про подсистему I/O. ..
1. AIO в Linux есть в достаточном объеме:
alexr@priscyla ~ $ apropos aio
aio.h [aio] (0p) - asynchronous input and output (REALTIME)
aio_cancel (3) - cancel an outstanding asynchronous I/O request
aio_cancel (3p) - cancel an asynchronous I/O request (REALTIME)
aio_error (3) - get error status of asynchronous I/O operation
aio_error (3p) - retrieve errors status for an asynchronous I/O operation (REALTIME)
aio_fsync (3) - asynchronous file synchronization
aio_fsync (3p) - asynchronous file synchronization (REALTIME)
aio_read (3) - asynchronous read
aio_read (3p) - asynchronous read from a file (REALTIME)
aio_return (3) - get return status of asynchronous I/O operation
aio_return (3p) - retrieve return status of an asynchronous I/O operation (REALTIME)
aio_suspend (3) - wait for asynchronous I/O operation or timeout
aio_suspend (3p) - wait for an asynchronous I/O request (REALTIME)
aio_write (3) - asynchronous write
aio_write (3p) - asynchronous write to a file (REALTIME)

2. Никаких заметных преимуществ кроме некоторых специфичных test-case данное API не дает (самая интересная работа с очередью запросов происходит на уровне BUFFER CACHE как и раньше)
3. Че толку под Офтопик в AIO если там самый отстойный cache и блок аллокатор и mft локализована а не распределена.
4. В нашей конторе занимаются системами видеозаписи. Раскрою вам большую тайну результатов тестирования вех возможных Офтопик API поверх FS... чтобы под Офтопик писать быстро нужно писать как минимум кусками по 1M и тогда блокированный доступ дает лучший результат. В LINUX достаточно писать минимум кратно размеру блока файловой системы который вернул stat(...). Но это далеко не максимум линукса.
BTW Офтопик ведет себя ужасно на задачах массового I/O обслуживания, в нем нету даже возможности выбрать/настроить I/O scheduler.

> Торвальдса в необходимости KAIO и RAW-IO. он долго отпирался - упертый оказался мужик!
Ну и правильно делал ... Толку от них все равно мало...
RAW I/O тоько ORACLE и юзает поскольку у них свой специфичный BUFFER CACHE. AIO X3 кому надо всеравно проблемму 10K не решает (кто не знает это проблемма обслуживания более 10'000 клиентов) разве нехоторые офтопичные проекты стало легше переносить....
Ведь нафиг ломать VFS если это никому не нужно. Вот стало нужно критической массе разработчиков способных все сделать аккуратно и поддерживать это хозяйство так патчи и включили. Стандартная психология PMа.
> а сколько было сломано копий, чтобы убедить сего господина включить в ядро потдержку потоков?
Столько же сколько и при добавлении любой новой большой фичи...

> Простите что вмешиваюсь, кто там мне на linuxfest говорил что "проблемы фрагментации под unix никогда не было"? :). Сегодня смотрел как 2.5ТБ раздел при 100% iowait еле-еле 7мб в секунду выдавал. При том что rawspeed была в районе 90мб в секунду(raid в pci32 воткнут).

Больше слушай мелких пи*болов. Сам наблюдал не раз картину как интенсивно юзаемая система в которой регулярно устанавливается/обновляется и удаляется софт страдает жесткими тупняками на reiser3 разделе и как моментально оживала после копирования данных на другой раздел, форматирования прежнего и копирования данных обратно...

> Стали разбираться оказалось что Офтопик "fallocate ХАК=seek(N)+write(0)" под нормальными UNIX приводит к появлению дырок в файле в результате происходит бешенная фрагментация: средний размер фрагмента под Linux оказался в сотни раз меньше чем под Офтопик.

Гыгы под "ненормальным" оффтопиком фрагментации нет, а "нормальные" юнипсы бешенно фрагментируются при том, что все красноглазые п-дят что фрагментация в юниксах не происходит пытаясь оправдать отсутствие дефрагментаторов.

ты еще хер дверью прищеми, а потом говори, что двери неправильные (с)

>страдает жесткими тупняками на reiser3 разделе

CCЗБ

Да я тебя понял.
Я до недавнего времени тоже использовал reiser4.
Сейчас перешёл на jfs.
Ты до конца пробовал раздел заполнять?

Нет. А что там? Говорят, системный запор начинается, да?

> А ка поставил гену поемержил и система вся фрагментировалась, пришлось делать антифрагментатор

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

> Сам наблюдал не раз картину как интенсивно юзаемая система в которой регулярно устанавливается/обновляется и удаляется софт страдает жесткими тупняками на reiser3 разделе и как моментально оживала после копирования данных на другой раздел, форматирования прежнего и копирования данных обратно...

если на раздел сливались логи, программы, пользовательские хомяки, производилась компиляция, то неудивительно

> Если серъёзно, то на дефрагментацию и так 5% диска уходит.

Это вам кто-то соврал.

> кое в чем линаксу еще долго догонять винду ( многоуровневая архитекткра i/o, полностью асинхронный i/o aka completion ports, асинхронный i/o cancelation и т.п. )

Полностью асинхронный i/o ??? А почему же при этом если какая-то прога зависнет на i/o, в основном с сетевыми дисками встречался с этим. То приходит пушной зверёк для всего i/o, пока то не просрётся?

> линуксоидам - не прошло и 12 лет, как у вас это появилось бугага!

у нас на ЛОРе бугога появилось относительно недавно. а у Вас оно постоянно происходит ? К врачу не пробовали... ?

>> кое в чем линаксу еще долго догонять винду ( многоуровневая архитекткра i/o, полностью асинхронный i/o aka completion ports, асинхронный i/o cancelation и т.п. ) > Полностью асинхронный i/o ??? А почему же при этом если какая-то прога зависнет на i/o, в основном с сетевыми дисками встречался с этим. То приходит пушной зверёк для всего i/o, пока то не просрётся?

Насчет полностью асинхронного i/o я тоже где-то в доках ms читал. Так же читал про отсутствие глобальных блокировок где только можно, про великолепно работающий планировщик (хуже которого я еще не встречал) и etc. В пресс-релизах у них всегда все гладко.

> fallocate добавили в Linux в основном из-за специфики работы Офтопика и отсутствия на нем файлов с дырками и прямого механизма предаллокации

Sparse files поддерживаются начиная с win2000: http://msdn2.microsoft.com/en-us/library/aa364596.aspx

Про предаллокацию уже написали выше.

>кое в чем линаксу еще долго догонять винду ( многоуровневая архитекткра i/o, полностью асинхронный i/o aka completion ports, асинхронный i/o cancelation и т.п. ). забавно, однако все это было уже в NT-4.0, а может и раньше. забавно, но ребятам из IBM и Oracle-а пришлось в свое время изрядно попотеть чтобы убедить г.н.-а Торвальдса в необходимости KAIO и RAW-IO. он долго отпирался - упертый оказался мужик! а сколько было сломано копий, чтобы убедить сего господина включить в ядро потдержку потоков?

Вообще-то kqueue (completion ports) или как оно там называется было в freebsd очень давно, и также существовал порт этого под линукс.

А вокруг Торвальдса слишком много славословий и поклонения. Упертость, конечно, дело хорошее, но до определенного момента. Дальше - пожалуйте в президиум, сидите и надувайте щеки, но не лезьте в то, чего не понимаете.

> Стали разбираться оказалось что Офтопик "fallocate ХАК=seek(N)+write(0)" под нормальными UNIX приводит к появлению дырок в файле в результате происходит бешенная фрагментация: средний размер фрагмента под Linux оказался в сотни раз меньше чем под Офтопик.

Ай спасибо! Я давно заметил этот прикол - seek(N)+write(0). Вообще - логично, а вот дырки... интересно кто-нить кроме ext2/ext3 их поддерживает? Мне кажется, что существует не так уж и много файлов, в которых более блока нулей. Дырки - зло.

> CCЗБ

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

> Я так понял, ты поставил дженту и не догадался выделить отдельный раздел для сборки?

Нет. А должен был догадаться? И сколько под него нужно отводить? 5 Гиг? 10 Гиг или 20(чтобы новый опенофис собрался)? А под tmp сколько гиг? Вообще это забавно выкинуть пару десятков гигов под отдельныйе разделы для сборки и их нельзя будет использовать для хранения полезных данных. Это даже круче висты которая по слухам занимает десяток гиг на винте - здесь десяток гиг на винте будет выделен строго под сборку. Но и даже так при установке-удалении пакетов будет происходить фрагментация и неоптимальное раположение файлов, что в итоге ведет к тупнякам и тормозному запуску приложений.

> Полностью асинхронный i/o ??? А почему же при этом если какая-то прога зависнет на i/o, в основном с сетевыми дисками встречался с этим. То приходит пушной зверёк для всего i/o, пока то не просрётся?

Да потому што видимо ядро NT начали писать хакеры, а дописывали ядро и писали юзерспейс менеджеры и индусы.

> нда, рано ещё популязировать юникс системы, люди нифига головой думать не хотят, хоть бы почитали документацию, что ли?

Мне слишком жалко отдавать под отдельно стоящий /tmp десяток гиг, чтобы его точно хватило, жалко десятка гигов, которые будут свободными на /var, когда свободно место под /home будет исчерпано. С какой стати я должен выкидывать гигабайты дискового пространства под всякую херню? Хочу использовать дисковое пространство максимально эффективно!

По большому счёту, никого твои проблемы не *бут, т.к. уже не раз зачемечно, что скажешь на форуме, к пример,у что места мало - "Купи себе нормальный винт!" Скажешь, что DE латентный\тормозит - "Никому нах твой pII/PIII c 128Мб озу не нужен". Зато тру-posix-унифицировано-опенсорц шопесдетс. А ты главное покупай железо, оно нынче дёшево (это основной аргумент в их ответах).

> Полностью асинхронный i/o ??? А почему же при этом если какая-то прога зависнет на i/o, в основном с сетевыми дисками встречался с этим. То приходит пушной зверёк для всего i/o, пока то не просрётся?

По конкретнее можно?

Какая версия ядра?
На какой файловой системе?
Какие опции монтирования fs?

Описанная выше проблемма может касаться только одной файловой системы, например NFS с опцией моунта hard (default). Остальные замоунченные fs будут прекрасно работать, никаких проблемм нет с этим... По крайней мере я не встречал на ядрах 2.2.xx, 2.4.xx, 2.6.xx (2.0.xx и 1.x.xx не тестировал)
Конечно если это была root файловая система то тогда пинцет... Но так это ж с любой OS также будет здесь вариантов нет...

"hard" The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed unless you also specify intr.
When the NFS server is back online the program will continue undisturbed from where it was. This is probably what you want.

" soft" This option allows the kernel to time out if the nfs server is not responding for some time. The time can be specified with timeo=time. This option might be useful if
your nfs server sometimes doesn't respond or will be rebooted while some process tries to get a file from the server. Usually it just causes lots of trouble.

> По конкретнее можно?

Он вообще-то на Винду жаловался.

> Фрагментация под юниксами есть и все кто твердят что этого нет,

Фрагментация есть

> поэтому дефрагментаторы не нужны - п-болы.

дефрагментаторы не нужны и совсем не поэтому

> С какой стати я должен выкидывать гигабайты дискового пространства под всякую херню? Хочу использовать дисковое пространство максимально эффективно!

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

> дефрагментаторы не нужны и совсем не поэтому

А почему? У меня есть жутко фрагментированный (судя по тому как кряхтит бедный винт, хотя он на 7 килооборотов) раздел с Gentoo на reiser3. Чем его дефрагментировать, чтобы избавиться от фрагментации? Нечем. Пщтому, что какой-то фанатик решил, что дефрагментация не нужна(только тогда зачем в reiser4 встроенный дефрагментатор, если не врут?)

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

Не пори горячку. Та мне на 5-10 гиг зарезервировано и не намертво как в случае с разбиением на кучу фиксированных разделов.

> не жалко потерь от того что маленький файл/хвост фаила занял целый блок?

man reiser

> Не жалко места, которое cxавал журнал и таблицы размещения?

Журнал можно отключить. А без таблиц размещения это уже не ФС будет а непонятно что. Это все крохи от объема винта, в отлчиие от 1/4 винта, которую предлагается отдать под сборку и которую ни с какой другой целью уже не заюзать, если не заниматься извращениями с симлинками.

> какой-то фанатик решил, что дефрагментация не нужна

да нужна, конечно..

> только тогда зачем в reiser4 встроенный дефрагментатор

его там и нет: был только в планах: Ханс хотел его платной опцией сделать..

>Мне слишком жалко отдавать под отдельно стоящий /tmp десяток гиг, чтобы его точно хватило, жалко десятка гигов, которые будут свободными на /var, когда свободно место под /home будет исчерпано. С какой стати я должен выкидывать гигабайты дискового пространства под всякую херню? Хочу использовать дисковое пространство максимально эффективно!


man LVM