точно, прописано 255

но, помнится была у меня трабла, при ext нельзя было записать 255 русских букв

мож уже путаю чего

Всегда ставил ext2 на загрузчик и ext4 на все остальные разделы, да и много где в мануалах рекоммендуют именно его, всегда считал универсальной фс. Даже не ожидал, что его кто-то будет считать кривым говном. Если ext4 говно, то что тогда тогда нормальное? Хотелось бы конкретики, а не разводить холлтвыры в стиле Gnome vs KDE.

Дык что в итоге постановили ведущие аналитики?

RHEL и десятки (сотни?) тредов в стиле «btrfs опять сдохла» — всё врут? Или же btrfs действительно уже стала стабильно дурно пахнуть?

Ясен перец, что в RHEL7 оно будет жить не хуже, чем в RHEL6. Потому что они все уже в продакшене. А вот в RHEL8 возможны варианты...

Так 255 символов однобайтных. UTF-8 - двухбайтный. Поэтому всего около 120 символов в юникоде. 4096 на полный путь.

«Кривое говно» это слишком категорично, но Ext4 и вправду имеет очень серьёзные косяки.

Кстати, о её надёжности: на своей многолетней Ext4-файлопомойке я иногда с удивлением обнаруживаю файлы, которые не открываются.

/me наслаждаюсь болью хипстеров.

Да народ просто путает названия ФС, среди выхлопов mount глаза разбегаются, потом пишут всякую хересь тут. Кто нормально юзал btrfs, тот её и закапывал под табличкой «no space left on device».

У ext проблемы с производительностью на тысячах мелких файлов (по сравнению с reiserfs). ext2-3 не держат 8тб+.

Файловая система Btrfs объявлена устаревшей в рамках линейки RHEL 6.x. В качестве причины названо фактическое прекращение развития этой файловой системы.

Что, масло прогоркло?

У ext проблемы с производительностью на тысячах мелких файлов (по сравнению с reiserfs)

Да, вот такие иксперды обычно и хоронят Btrfs :D

у ext проблема, если к файлу много пользователей обращается.

к файлу много пользователей обращается

На запись одновременно?

Кто работал с сорцами толстых проектов — тот знает.
Остальных это никак не касается.

Кто работал с сорцами толстых проектов — тот знает.

Ядро Linux можно назвать толстым проектом? Ни на каталогах с сорсами ядра, ни на дереве портежа reiserfs не быстрее ext4.

«Работал» и «распаковывал пару раз с помощью tar xf» — это немного разные вещи.

Не распаковывал, а собирал ядро и делал rsync. По-моему, вполне себе интенсивное использование и годный бенчмарк способностей ФС.

Пропатчили примерно как тут http://wiki.etersoft.ru/Linux/VLFN#BTRFS

Не распаковывал, а собирал ядро и делал rsync. По-моему, вполне себе интенсивное использование и годный бенчмарк способностей ФС.

Интенсивный бенчмарк — это годик-другой минимум пилить проект в команде, с использованием vcs, подтягивая и создавая точечные изменения среди кучи файлов. А то, что у тебя — это бенчмарк io-кеша, а не ФС.

Напомню, что тред про продакшен и энтерпайз.

А вы думаете, я дерево портежа и каталог с сорсами ядра каждую неделю удалял и создавал заново?

И да, расскажите мне про стабильную скорость reiserfs, которая уже через несколько месяцев проваливается в днище из-за дикой фрагментации))

Напомню, что тред про продакшен и энтерпайз.

Тогда почему ты вспоминаешь reiserfs?

Ну учитывая твои громкие заявления на ЛОРе ранее, считаю это вполне вероятным вариантом. В конце концов, ты не программер при любом раскладе, поэтому тут спорить смысла нет — ты будешь говорить, что у тебя не тормозит и будешь как бы прав. А на всякий потреж найдётся свой костыль типа pacman-optimize по крону.

ты не программер при любом раскладе, поэтому тут спорить смысла нет

Вот это аргументация. Впрочем, вполне в вашем духе)

Не имею права — анонимус запретил?

Файловая система Btrfs объявлена устаревшей в рамках линейки RHEL 6.x

Она только-только объявлена стабильной. Несколько лет прошло. :-) Они на что её менять-то собрались ? ZFS довеском таскать без включения в ядро, что ли ? Впрочем, после поддержки разработки systemd, ждать можно чего угодно...

touch «Возможно ntfs работает немного по-другому, если монтировать через ntfs-3g. Но вообще все эти велечины прописаны в limits.h ядра123456789012345678901234567890123456789023456789012345» touch: невозможно выполнить touch для 'Возможно ntfs работает немного по-другому, если монтировать через ntfs-3g. Но вообще все эти велечины прописаны в limits.h ядра123456789012345678901234567890123456789023456789012345': Слишком длинное имя файла

touch «Возможно ntfs работает немного по-другому, если монтировать через ntfs-3g. Но вообще все эти велечины прописаны в limits.h ядра1234567890123456789012345678901234567890»

все ок

echo «Возможно ntfs работает немного по-другому, если монтировать через ntfs-3g. Но вообще все эти велечины прописаны в limits.h ядра1234567890123456789012345678901234567890»|wc 1 18 256

ext4 чот я запутался

that this change affects RHEL6 only

А, ну тогда всё и вправду норм. Хотя объявлять новую ФС устаревшей на устаревшей ветке шапки - это вещества.

Всегда ставил ext2 на загрузчик и ext4 на все остальные разделы

ext2-то зачем ? Для разнообразия, что ли ?

Хотя объявлять новую ФС устаревшей на устаревшей ветке шапки - это вещества.

Просто у какого-то крупного клиента ФС полегла. Поэтому пока тренируются с безопасного расстояния.

https://en.wikipedia.org/wiki/Comparison_of_file_systems Всего в трёх ФС длина пути на одном уровне вложенности равна 255 СИМВОЛОВ а не байт.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx Внезапно в мастдае самый длинный MAX_PATH - 16384 для уникодовых функций. Сам «ишак» продолжает урезать длину имён в дань совместимости. MAX_PATH в солярис и БСД 1024 в лялихе 4096.

Просто их любимая XFS недостаточно пропиарена. Вот они и баззвордят.

малый MAX_PATH - дань производительности ЕМНИП

Ещё лучше бы Ганса на свободу и за комп!

Или подкинуть идею шарашек - просто за комп.

я не знаю, как они это сделали, но теперь в шары влезают
файлы длиной в ~260 русских букв, для вендоюзеров - щастье

Вероятно как-то так: http://wiki.etersoft.ru/Linux/VLFN
Хотя нет, тогда было бы значительно больше.

Когда в rhel7 дропнут, тогда да.

Кстати да. Вероятнее, что имеется ввиду, что в устаревшую rhel6 не будут портировать новые наработки по btrfs. Видимо, что-то стало сложно тащить в старые ядра.

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

Сказал некто с тэгом «archlinux» в избранных.

Там двукратное кэширование by design. Последнее касается только ZOL.

Факт!

в мануалах рекоммендуют ext4
пацаны с ЛОРа сказали, что ext4 - говно
Если ext4 говно, то что тогда тогда нормальное?

Вот как размножаются хипстеры!

Btrfs и eCryptfs не рекомендованы к использованию в рамках RHEL 6.х (комментарий)

^^255 символов utf-8, ext4

будет время - проверю с иероглифами

Файловая система Btrfs объявлена устаревшей

Ржу бл )

Без политкорректности ты потрешь же.

Не надо иероглифов, достаточно не латинских символов и уникодовой локали. Ещё проще глянуть в limits.h в заголовочных файлах которые к системе, от них и ядро и библиотеки берут в т.ч. вышеуказанные ограничения.

наркоманы. если код ФС не меняется - значит, она стала стабильной.

Btrfs была разработана корпорацией Oracle в качестве альтернативы ZFS.

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

Если перестали пилить код, значит, серьёзных проблем нет.

Или боятся даже палочкой потрогать - вдруг окончательно развалится.

Ждём в скором времени новость от RedHat о прекращении поддержки systemd в связи с устареванием.

Не верю в такой поворот событий. Вот бомбануло бы у systemd-фанов.

Вброс отличный.

Самое странное в том, что код Btrfs никто пилить не перестал.

Не грузится.

А я только недавно перевел свои машины на btr. Думал самая крутая и современная.

С такой формулировкой я даже свой локалхост не стану ни на что переводить :-).

Reiser4

Думал самая крутая и современная.

Переходите на Reiser4.

Шишкин негодуэ

Самое странное в том, что код Btrfs никто пилить не перестал.

Reiser4 тоже пилится, и что?

И где эта Reiser4?