В XFS завезут CoW

А есть ссылки?

Должны быть.

а TRIM-то зачем? Современным контроллерам он только мешает. Я недавно на эту тему общался с поцонами из HGST.

Прохладная история.

Прохладная история.

Я вполне серьезно. У железок есть ниибацо сложные алгоритмы, обеспечивающие равномерный износ ячеек и GC. И TRIM сильно сбивает их с толку.

Если trim мешает сборщику мусора, то прошивку явно криворукие обезьяны писали. HGST, говорите? Спасибо.

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

Поищи по ЛОРу за последние лет 5-7, найдешь кучу свидетельств. Я не спорю, в свое время reiserfs была очень крутой фс, и жутко надежной. Лично у меня она работала на жестком диске с глючным контроллером, и не рассыпалась, в отличии от ext3 (ext4 тогда еще небыло). Но современное ее состояние в ядре удручает.

Если trim мешает сборщику мусора, то прошивку явно криворукие обезьяны писали. HGST, говорите? Спасибо.

Ну дело твое.

На ЛОРе есть Свидетели Напильника, так что я бы не щетал посты на ЛОРе чем-то вменяемым. Есть ссылки на багзиллу ядра?

«УМВНР», ясно-понятно.

/fixed

Пф-ф-ф, вот, например, очень похожий по описанию баг, висит как минимум с 2011 года: https://bugzilla.kernel.org/show_bug.cgi?id=29162
Но там еще есть, мог бы и сам поискать по слову reiserfs

Лучше завезти BtrFS на кладбище.

И убрать все следы этого позора из ядра...

Мои результаты посмотри, а потом трынди. По факту COW не работает.

Мои результаты посмотри

Ну так после этих результатов у тебя были другие.

В ядре 4.8 будет доступен новый формат XFS с поддержкой copy-on-write, рефлинками, дедупликацией и прочими плюхами.

На самом деле там будет только поддержка Reverse-Mapping, что в теории, в неком отдалённом будущем даёт возможность реализовать для XFS «copy-on-write c рефлинками, дедупликацией и прочими плюхами»

мормонский

fxd

Как ни странно после отключения COW. Это только подтверждает мой вывод.

Фейспалм. Вообще-то, именно CoW-файлухам свойственно начинать тормозить при определённом уровне занятости раздела. Если моск ещё не весь съеден вендотроллингом на лоре - поймёте почему.

Вообще-то, именно CoW-файлухам свойственно начинать тормозить при определённом уровне занятости раздела.

Тормозит == файловая система не работает. Именно это я утверждаю. То что сама fs с COW не работает, а не конкретная фича fs. И на кой хрен тогда COW-fs нужны?

Когнитивно-аналитические способности уровня среднего пользователя ZverDVD

Спасибо. Поржал.

Использую ReiserFS на файлопомойке с незапамятных времён. Сейчас там кернел 3.16 (Debian Jessie), тоже с таким не сталкивался.

Ооо, BTRFS мы ждём-ждём-ждём! А также CoW - если он еще и будет управляемым, как например в BTRFS_CLONE_RANGE, то ваще аццкий агонь-агонь будет!!!

Как ни странно после отключения COW

Как ни странно, ты отключал не ВЕСЬ COW, а только для ДАННЫХ. COW создает большую фрагментацию, поэтому необходима постоянная работа дефрагментатора, а дефрагментатор, как известно, нуждается в запасе свободного места для эффективной работы. Но тем не менее, метаданные у тебя по-прежнему CoW'ились, и сами данные могли CoW'иться в случае, если бы программа об этом попросила.

В ядре 4.8 будет доступен новый формат XFS с поддержкой copy-on-write, рефлинками, дедупликацией и прочими плюхами.

Новость безусловно интересная! Но только поправка: в 4.8 (или 4.9) будет только базовый функционал (reverse mapping) для всех этих фич. Фичи только запланированы на будущее, еще не допилены. Поддержка в user space появится позже, после поддержки в ядре. А в остальном все верно.

а меня бы и новые фишки на старом добром xfs устроили:) всеравно, если на серверах hardware raid, зачем мне btrfs.:)

если на серверах hardware raid, зачем мне btrfs.:)

Эммм... Хардварный RAID это конечно хорошо, но вообще никаким образом не «серебряная пуля». Существует вполне себе определенный набор случаев, когда классический RAID достаточно сильно говнякает.

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

а на чем говнякает?

Opteron IO performance? (комментарий)

Каким образом команда от ос, оповещающая контроллер, о том, что вот тут у нас не нужно, можно стирать будет мешать GC и распределению разброса?
Кроме того, HGST сложно назвать крупным производителем ssd, может чье-то более релевантное мнение приведете?

даа, xfs давно имеет стабильный формат, чоужтам.

нехрен что попало использовать в опциях фс

«УМВР», ясно-понятно.

а у тебя ничего не работает и ничего не ясно

https://www.redhat.com/f/pdf/RHEL6_FileSystem_WP_5677547_0311_dm_web.pdf
третья по счёту, даже после ехт3. что-то ты темнишь

RHEL7, а не 6

Каким образом команда от ос, оповещающая контроллер, о том, что вот тут у нас не нужно, можно стирать будет мешать GC и распределению разброса?

Они не вдавались в детали, ссылаясь на NDA. Но я не очень представляю, зачем им было мне врать.

Кроме того, HGST сложно назвать крупным производителем ssd, может чье-то более релевантное мнение приведете?

Нет, больше ни с чьими инженерами я не общался напрямую. Тем не менее, я бы не назвал их мелкими производителями SSD-дисков. В Enterprise они довольно-таки неплохую нишу имеют.

Они не вдавались в детали, ссылаясь на NDA. Но я не очень представляю, зачем им было мне врать.

Феерично.

Феерично.

Чувак, это практически единственное, что делают вендоры SSD дисков. Кристаллы выращиывают не они, контроллеры тоже делают сторонние конторы. Так что ВНЕЗАПНО алгоритмы GC, EC и распределения износа под анальным NDA.

Я ещё тут всё сказал, продолжайте жечь))

а на чем говнякает?

Любая операция изменения размера (кроме добавления в 1+0). Лютый песец по производительности при заменен устройства. Втыкание дисков другой / разной емкости.

Я ещё тут всё сказал, продолжайте жечь))

У Intel ровно та же самая история, если чо.

P.S. Как раз для их ранних моделей TRIM и требовался.

Тоже по секретным документам тайным рассказам анонимных инженеров?

Тоже по секретным документам тайным рассказам анонимных инженеров?

Ммм... Чувакам, которые делают SSD диски и знают процесс, я верю как-то больше, чем анонимусу с ЛОР.

Можешь привести номер свежего бага, который приводит к потерям данных?

Даже искать особо не надо: https://bugzilla.redhat.com/show_bug.cgi?id=1356396

После выхода семерки я поставил три виртуалки с xfs. Две сдохли необратимо (репаир не работал). Тот баг, на который я нарвался уже вроде залечили.

После выхода семерки я поставил три виртуалки с xfs.

Настраивать виртуалку пробовал?

http://xfs.org/index.php/XFS_FAQ#Q:_Which_settings_are_best_with_virtualizati...

Кстати что не так с xfs/btrfs ? Можешь привести номер свежего бага, который приводит к потерям данных? Не будет номера засчитаю слив!

https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNE...

https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNE...

PS: Я не говорю, что эти фс плохие, но ты сам попросил.

Я вполне серьезно. У железок есть ниибацо сложные алгоритмы, обеспечивающие равномерный износ ячеек и GC. И TRIM сильно сбивает их с толку.

А как ещё накопитель может узнать, что место не занято?

На всякий случай замечу, что часто разрабы ядра на ядерную багзиллу просто кладут.

Что из этого приводит к потере данных?

А как ещё накопитель может узнать, что место не занято?

Что ты понимаешь под занятым местом?

Ежу понятно, что cache write в виртуализации отключен.

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