Pull to refresh

Comments 28

Незаслуженно обделили вниманием ZFS и NTFS.
Так же интересно увидеть сравнение VxFS на разных ОС — как влияет\влияет ли ОС.
А еще XFS, на которую перешел RH
Один раз попытался использовать вместо xfs ext4. Вся дружба с этой fs кончилась, после попытки chkfs на несколькотерабайтном диске. Скорость проверки-восстановления, по сравнению с xfs нереально медленная. Уж не помню точно цифры, но примерное соотношение — 10 терабайт реперится несколько дней. Сравните это с несколько секундами для xfs.
P.S. конечно всё восстановили из бэкапа
несколько секунд — это когда всё хорошо. Так и если на ext4 всё хорошо, то она тоже не несколько дней чекается.
Проблема начинается когда на fs всё плохо. Тогда xfs_repair может не только долго работать, но еще и памяти требует нереальное количество.
10Тб под XFS потребует минимум полтора гига памяти. И это абсолютный минимум. А уж далее зависит от ситуации.
xfs.org

Сервер с 10 террабайтным массивом сколько памяти на борту может иметь?
А непредсказуемо. В наше время 10 тб дисков может оказаться на виртуалке с 512 мегами. Но дело не в этом, а в том, что полтора гига — это совершенный минимум для раздела без файлов вообще. А если эти 10тб забить мелкими файлами, то требования к памяти сильно возрастут. Как, впрочем, и время восстановления.
Не подумайте, что я агитирую против xfs. Я сам её почти везде пользую. Но и в деда мороза я уже не верю. :)
Сегодня «10TB» это всего лишь три SATA-диска ;)
Возможно Вы путаете fsck.xfs, который действительно жрет память, но при этом он на самом деле ничего не делает, только проверяет факт целостности. И xfs_repair. Вторая жрет памяти гоораздо меньше fsck и несравнимо быстрее fsck.ext4. Реально занимает секунды. Долго работает только в случае больших проблем. И то, только из-за количества чтений/записей на таких объемах
Я путаю? Нет, уважаемый, это Вы путаете.

Очень рекомендую на произвольном линуксе (в других системах вроде SGI не уверен в результате) выполнить команду
cat `which fsck.xfs`
— думаю, что Вам понравится :)

P.S. я догадываюсь, что вы про xfs_check хотели сказать. Но все-таки check — это только check. А мы про восстановление. И таки xfs_repair хоть и жрет меньше памяти, чем xfs_check, но жрет.
Да, путаю в этом месте, потомучто уже много лет использую только _repair.
Конечно они оба потребляют память :) только вот xfs_check у меня для дисков от 8 терабайт никогда не отрабатывал, ибо прибивается по OoM.
Для теста запустил сейчас xfs_repair на 27терабайтный диск, 68 мегабайт потребление памяти.
попробуй ограничить память (ключ -m) например на 100 мегов. Или на гиг. И посмотри на результат.
И? Потребление памяти (ту память которую процесс таки использовал, а не просто аллоцировал) то при этом не изменилось. Что операционке дела до запрошенной но не используемой памяти?
Да, что-то пропустил её. Хорошо себя показывает на больших объёмах. По идее не большой оверхед должна давать.
Насчет NTFS вы забыли тег irony :)
С чего бы вдруг? Весьма достойная ФС.
все эти «speed benchmarks» обычно отражают убеждения его проводящих. Хотите — покажу ровно обратные результаты? Кому будем верить?
Тогда это замкнутый круг.
— X быстрее, чем Y
— докажи
— вот бенчмарки
— они ни о чем не говорят
— но X действительно быстрее
— докажи

Тогда как по вашему, надо мерить?
И да, хотел бы, чтобы вы показали ровно обратные результаты, если вам не трудно.
«Бенчмарки», которые не показывают устраивающего результата просто не показывают, и продолжают подбирать условия, пока результаты не начнут подтверждать мнение, которое требуется доказать.;)
Ну, вот, ниже про «бенчмарк» NTFS с использованием NTFS3g в userspace уже все и сказали.
Я понял. Но это бенчмарки от заинтересованных лиц. Вполне можно найти от третьих лиц.
Или вообще получить самому — их-то можно считать достоверными, или нет?
И вы ещё хотели мне показать ссылку на бенчмарк с ровно обратными результатами.
Вполне можно найти от третьих лиц.

Никаких «третьих лиц» не бывает. Либо вы считаете, что «Линукс-рулез, а венда-масдай», либо наоборот, разница только в градусе кипения разума возмущеного.
Те же, кто не «кипит разумом», они этой ерундой, как «бенчмарки», не интересуются обычно, так как уже и так все знает.

«Достоверными» — для вас. Для вас лично будет достоверным любой бенчмарк, который вы сами провели. Но для другого он будет недостоверным.
И так будет всегда, пока условия бенчмаркинга определяете вы сами.
Интересная у вас гипотеза насчет бенчмарков.
У вас получается, что однажды, в результате неких тайных действий, специалист получает озарение и больше никогда это не проверяет.
Ваша точка зрения понятна.
Планируете ли вы показать бенчмарки с ровно обратным результатом?
Или решили не показывать?
Там прямо в самом бенчмарке написано:
NTFS3g Szabolcs Szakacsits' NTFS user-space driver.
NTFS NTFS with Windows XP driver.
Нет бы с Win2k12 сравнить, ага.
По второй ссылке Microsoft Windows Server 2008 R2.
Статья от 2011/11/01.
Создание 16 файлов и потом запись/чтение из них — это имеет весьма малое отношение к файловой системе. Особенно если файлы создались заранее и фрагментация отсутствует.
При тестировании файловой системы куда более интересный сценарий это создание и удаление в произвольном порядке 10 миллионов файлов разного размера. Вот тогда разница разных fs будет видна. Как быстро файлы создаются, как быстро удаляются, как система справляется с фрагментацией.
Ну и таки хотелось бы чуть большего разнообразия файловых систем в тестировании.
Вынужден обратить внимание уважаемого ctapnep, что исследование всего разнообразия файловых систем не входило в задачу тестирования. Статья относится к серии посвященной флеш СХД. Оборудование данного типа, банально в силу своей стоимости, не используется в качестве файло-хранилищ. Его применение оправдано на корпоративных базах данных. Под эту специфику и подбирались, как файловые системы, так и и условия их тестирования. Что касается вопроса фрагментации — рекомендую ознакомиться со статьей Тестирование флеш СХД. Теоретическая часть. Там коротко объясняется разница в работе HDD и SSD.
Вы лихо ушли от основной идеи комментария :)
Я, собственно, упомянутую статью читал и таки, если вы заметили, там методику тестирования не критиковал. В том числе и вопросы фрагментации. Потому как, как вы правильно заметили, фрагментация данных самих по себе на флеш-носителях не имеет решающего значения. В случае-же файловых систем, мне кажется, ситуация несколько меняется. Возникает вопрос не только фрагментации самих данных, но и увеличения количества чтений метаданных, дабы собрать информацию о том, какие блоки вообще надо читать.
Что касается специфики — возможно имело смысл в таком случае в начале статьи описать данную специфику и объяснить причины выбора именно этих и только этих вариантов для тестирования. Хотя лично мне кажется, что раз уж вы имеете возможность провести толковое тестирование, то имело-бы смысл провести хорошее сравнение производительности различных популярных файловых систем. Оно было-бы многим полезно почитать. Особенно учитывая, что флеш-накопители в любом случае уже плотно входят в нашу повседневную жизнь и проблемы файловых систем становятся все более заметными на фоне всё более быстрых физических носителей.
Sign up to leave a comment.