>>С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.
> в оракловом случае не попадают.
> наоборот, ораклу пофиг на фрагментацию всего файла (большого файла. угу. на заметку).
> но не плевать на фрагментацию отдельных кусков этого файла.
> и эти куски очень сильно согласуются с контрольными точками и коммитами транзакций. И фрагментация тоже не многое объясняет, на SSD она мало влияет на скорость, тем не менее вот недавнее сравнение нашел. ИМХО правдоподобно.
http://www.mysqlperformanceblog.com/2012/05/22/btrfs-probabl.../
Если хочется докопаться до сути, наиболее правдоподобное на мой взгляд объяснение феномена было в мэйллистах федоры. http://comments.gmane.org/gmane.linux.redhat.fedora.devel/15.... Второй пост и далее по треду. Лично мне достаточно длительного существования проблемы и отсутствия решения, чтобы говорить, что не под эти задачи систему проектировали изначально.
>>Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.
> очевидно да.
> но это - либо менять структуру тогоже постгри/огнелис/прогресс/дб2, либо писать что-то
> новое. а клинический ынтырпрайз на енто не пойдётЪ. :D
Тот же мускуль что-то порядка десяти сторадж бэкендов имеет, а значит и в МарияДБ можно запилить еще скажем один. Во всяком случае не верю, что Оракл не верит, что конкуренты не способны воспользоваться его технологиями.
> и понимаем, что 1) это все только в унбрикэбл 2) у конкурентов
> это только в юзерспейсе 3) достичь таких объёмов в стиле fuse
> даже в теории низя.
> как то так. вот.
Ну да и поэтому они запилили бы свой модуль в свое анбрикабл ядро для своей базы данных, а не ФС для "враждебной" общественности.
