The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Отставка сопровождающего файловую систему XFS, opennews (??), 02-Авг-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


151. "Отставка сопровождающего файловую систему XFS"  +2 +/
Сообщение от User (??), 03-Авг-23, 08:13 
>Доисторический NTFS, еще более архаичный FAT, да ReFS являющийся жалкой пародией на btrfs и zfs, не умеющий и трети от их возможностей.

Доисторический - не доисторический, а лучше-то и нету ничего, ага? Приемлемая производительность в большинстве реальных кейсов, _нормальные_ acl (POSIX-acl не предлагать!), больмень работающие snapshot'ы (Опять таки - про lvm нннинада), управление томами... Для каких-то случаев можно найти лучшую альтернативу - но в целом? Не-а. Без вариантов.

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

158. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Аноним (-), 03-Авг-23, 08:42 
> Доисторический - не доисторический, а лучше-то и нету ничего, ага?

В маздае - да. Хотя и туда с горя вон драйвер btrfs'а накодили. Правда не майкрософт, и с отставанием на дофига. А линух не настолько печальный по ФС все же.

Я же перейдя на линух тома в NTFS все извел. А зачем оно надо? Медленная печальная файлушка по лекалам 90х. Если у вас ничего слаще морковки нет - ну, окей.

> Приемлемая производительность в большинстве реальных кейсов,

Я тот же линукскернел компилю регулярно. Это примерно 200-300К файлов затрагивает. Можете даже не вякать как NTFS с таким работает - я видел, "никак". Тот же btrfs его обставит на типовых операциях с такой иерархией в разы. Только еще при этом может в снапшоты и рефлинки не через джеппу, в отличие от. И не встает колом на эн минут от например 60К файлов в 1 дире, как NTFS. А сэйвануть 1 документ в ворде можно хоть на FAT16, конечно.

> _нормальные_ acl (POSIX-acl не предлагать!), больмень работающие
> snapshot'ы (Опять таки - про lvm нннинада),

Это все рядом не стояло с btrfs и zfs. Вот там - нормальные снапшоты. Особенно в btrfs. Которые создаются мигом, места занимают только на дельту, ресурсов не жрут, прекрасно работая даже на роутере с 64 мегами оперативы на все, откат тоже в момент. А то что в винде - это такой мутант-франкенштейн, жалкая пародия на идею.

> управление томами...

Рядом не стояло с btrfs. Вообще совсем.

> Для каких-то случаев можно найти лучшую альтернативу - но в целом? Не-а. Без вариантов.

В целом это кусок легаси из 90х для тех кому 1 файлик в ворде сэйвить. На более масштабных задачах... одна из причин по которым Win и IIS рынок серверов в вебе профукали. Линух все то же делает в разы шустрее на том же железе, а бабки считать все любят. Особенно если вопрос в том чтобы еще и за серверную винду заплатить, она так то не дешевая. И юзают ее в результате корпораты, ради AD.

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

162. "Отставка сопровождающего файловую систему XFS"  +1 +/
Сообщение от User (??), 03-Авг-23, 09:38 
>Я же перейдя на линух тома в NTFS все извел. А зачем оно надо? Медленная печальная файлушка по лекалам 90х. Если у вас ничего слаще морковки нет - ну, окей.

Рабинович ntfs3g насвистел, да? Не, ну в таком изводе и впрямь - нинада.
>Я тот же линукскернел компилю регулярно.

Аааа, ну тут да, тут не поспоришь ). В дисциплине конпеляния линуксов у линуксов конкурентов нет ))).
>Можете даже не вякать как NTFS с таким работает - я видел, "никак".

NTFS определенно _медленнее_. В краевых случаях - _значительно_ медленнее. Впрочем, "краевые случаи", где другие ФС встают колом я тоже видел.
Беда в том, что при попытке не просто "навалить кучу" а сделать чего-нибудь полезное ситуация некоторым образом м-ммм...меняется. Запускаем какой-нибудь жЫрный постгрес и btrfs с его коровами-и-снапшотами превращается в тыкву. Ну ой, не преднозначено оно. Не, ну можно конечно коровок отломать - но тогда и со снапшотами попрощаешься. Захочешь ты фс зашифровать... ой, а оно ниумеет - а после того как ты какой luks\ecryptfs на скотч-и-изоленту к этому делу прикрутишь - ситуация с производительностью уже чуть-чуть, самую капельку, малость - отличаться будет. Решишь ты вместо "хипстерской коммуны" мал-мала порядок навести и acl для доступа накрутить - ээээ... а оно нионо. Т.е. можно в юзерспейсе - но "за перформанс" опять же не поговоришь.
По ряду кейсов таки да, можно найти инструмент получше и местами\временами это даже окупается. Но in general - без вариантов.

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

215. "Отставка сопровождающего файловую систему XFS"  –1 +/
Сообщение от Аноним (-), 04-Авг-23, 06:05 
> Рабинович ntfs3g насвистел, да? Не, ну в таком изводе и впрямь - нинада.

Ну, э, я их еще до того момента аннулировал. А так он работает. Но нтфс от этого лучше не станет. Как был писком 90 по технологиям так и остался.

> Аааа, ну тут да, тут не поспоришь ). В дисциплине конпеляния линуксов
> у линуксов конкурентов нет ))).

Создать технологии чтобы ими далее улучшать, развивать и кастомизировать технологии - это нормальный принцип bootstrap. Линуксоиды не первые кто придумал это. Этот принцип отлично работает. Попробуй так из своей виндочки, кули. Мне кажется у тебя будут определенные проблемы за пределами того что предусмотрел для тебя майкрософт. Поэтому я вон те штуки смогу, а ты нет.

> NTFS определенно _медленнее_. В краевых случаях - _значительно_ медленнее.

А виндовый кернел определенно медленнее линухового во многих случаях. В крайвых случаях - в разы. Может в гамезах с этим и можно поспорить, но я не геймер.

> Впрочем, "краевые случаи", где другие ФС встают колом я тоже видел.

Да они везде есть. Но в случае винды и NTFS почти любой проект куда ни ткни в 2-3 раза медленнее билдуется. Это похрен для фирмвари МК но совсем не похрен для более крупных проектов.

> жЫрный постгрес и btrfs с его коровами-и-снапшотами превращается в тыкву.

Ну, я не DBA c мегабазами. И мне жирный постргрес точно не первичный кейс. Это как раз тот случай для которого оракл nocow задуывал. Журналить журналы затея в принципе неблагодарная, с практически любыми технологиями.

> Ну ой, не преднозначено оно. Не, ну можно конечно коровок отломать -
> но тогда и со снапшотами попрощаешься.

Делать именно снапшоты, именно баз такого плана - затея довольно грабельная, мягко говоря. У базы какие-то свои идеи насчет консистентности - не очень предусматривавшие что кто-то заморозит их во времени "in flight" а потом сгоняет в прошлое помимо их воли.

> на скотч-и-изоленту к этому делу прикрутишь - ситуация с производительностью уже
> чуть-чуть, самую капельку, малость - отличаться будет.

Что поделать, на елку влезть не ободрав зад получается таки не всегда.

> а оно нионо. Т.е. можно в юзерспейсе - но "за перформанс"
> опять же не поговоришь.

В смысле? Как минимум posix ACL оно вроде сто лет умеет.

> По ряду кейсов таки да, можно найти инструмент получше и местами\временами это
> даже окупается. Но in general - без вариантов.

Ну вот не бывает в этом мире серебряных пуль. А вон там на RAW NAND вообще придется любить UBIFS какойнить. Просто потому что он в курсе особенностей столь дурной media. NTFS при этом вообще никак не поможет - он на RAW NAND вообще совсем никак не катит.

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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