The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS" +2 +/
Сообщение от Аноним (-), 23-Июн-11, 17:43 
> Файловая система должна работать с любыми данными. Если заявила отсутствие ограничений
> на число файлов - будь добра обеспечить.

У них раньше было ограничение прямо в утилитах - они посылали при попытке создать том менее 2 Гб. Шишкин создал 600Мб и завалил его мелкими файлами. Получив вполне предсказуемый результат.

> Об этом и речь, что нет гарантии что бтрфс на конкретной структуре
> данных и особенностях с ними работы не сдохнет, не займёт всё место.

В сложной конфигурации вам вообще никто ничего и никогда не гарантирует. XFS в частности хорош лишь для больших нефрагментированных файлов. На куче мелочи он вообще зверски тормознут. В последних версиях ядра (в районе 37..39 ядер чтоли) это подтянули слегка правда, стало более-менее похоже на остальные типа EXT4/JFS/... даже.

> Никто не проверял алгоритмы, на то что фрагментация гарантированно меньше
> некоторого значения (как в XFS например).

Теория - это прекрасно. Проблема только в том что если не миндальничать и взять дейстивтельно негуманный сценарий, например, забить XFSный том до упора торентами с мелкими блоками, слитыми без преаллокации - сдуется он точно так же как и любая другая ФС. И толку с теоретизирований будет немного. Все-равно без дефрагментации будет неюзабельно. Когда диск выдающий на крайних треках 150Мб/сек натужно шуршит, выдавая 10Мб/сек при последовательном чтении файла - толку то с ваших теоретических гарантий? На практике - Ж!

> Замечены попытки решения задач способами
> которые для этого не приспособлены, с вытекающими побочными эффектами.

А именно? И конечно же вы, или Шишкин готовы предложить более хорошее по параметрам решение? Или вы/Шишкин/кто там еще готовы создать решение лучше и гарантировать что оно во всех ворклоадах сделает btrfs? Если посмотреть на реальные бенчи - btrfs довольно злая штука и зачастую всех натягивает. При этом успевая честный журналинг данных, чего XFS не только не делает, но раньше еще и тер сомнительные места в данных нулями. Знаете как круто когда вам кусок базы данных нулями протрут и однажды все резко наворачивается? :)

> Да добавили костыль на один случай. Будут ещё. И будет код пухнуть
> исключениями, больше и больше.

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

> А потом чтобы разобраться в бардаке и восстановить данные оракл потребует у корпораций миллиарды :)

Для начала, CoW не убивает данные при перезаписи. И кстати кто оплатит протертые нулями XFSом файлы?Есть желающие? :)

Вообще, файловые системы которые вы противопоставляете - очень разные по функционалу. Ну например у XFS нет снапшотов. И перезапись - разрушающая. И полного журналирования - нет (спасибо что хоть вытирание нулями спорных кусков удавили). И фоновый дефраг/ребаланс и прозрачное добавление диска в пул с XFS не сделаешь. XFS это "просто еще одна ФС". А btrfs это такой комплексный комбайн. К слову довольно прилично надирающий зад и в режиме "якобы мы тут простая ФС".

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Изучение изменения размера кодовой базы Ext4, Btrfs и XFS, opennews, 23-Июн-11, 12:28  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру