В коде файловой системы XFS обнаружена уязвимость (CVE-2021-4155), позволяющая локальному непривилегированному пользователю читать данные неиспользуемых блоков напрямую с блочного устройства. Все значительные версии ядра Linux старше 5.16, содержащие драйвер XFS, подвержены этой проблеме. Исправление вошло в версию 5.16, а также в обновления ядер 5.15.14, 5.10.91, 5.4.171, 4.19.225 и т.д. Состояние формирования обновлений с устранением проблемы в дистрибутивах можно отследить на данных страницах: Debian, RHEL, SUSE, Fedora, Ubuntu, Arch...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56508
> их наличие похоже на бекдор.
> According to the glibc compat header for Irix 4, these ioctls originated
> in April 1991 as a (somewhat clunky) way to preallocate space at the end
> of a file on an EFS filesystem. XFS, which was released in Irix 5.3 in
> December 1993, picked up these ioctls to maintain compatibility and they
> were ported to Linux in the early 2000s.
> Recently it was pointed out to me they still lurk in the kernel, even
> though the Linux fallocate syscall supplanted the functionality a long time ago.А вот Линус считает что похоже на давно устаревший код, но никак не на бекдор
UPD: Ошибся, не Линус, а автор патча по удалению
Да всё ядро можно устаревшим кодом назвать, столько мусора ещё никуда упихнуть не смогли. Постоянно находят уязвимости!
Забыть занулить выделяемый непривилегированному блок с диска - похоже скорее на диверсию, чем на легаси код и "неподумал". Даже идиот понимает, чем чревато отдавать куски памяти и блоки диска, которые могли прийти от одного приложения (SSH, например) в другое приложение. А учитывая, что вряд-ли кто-то считает, что XFS имплементили дурачки - то это именно на специально оставленную закладку и похоже
возможно и так
То есть никто не понимает, зачем mkfs.xfs вызывается с ключем -K?
Silicon Graphics её делала для Irix.
Только в линукс вошла далеко не та реализация. Во-первых весь этот код с новыми ioctl был модифицирован для линукса, во-вторых было много изменений и упрощений - убран менеджер томов, убрана поддержка блоков > 4K (те создать можно, а использовать такую фс потом нет), убраны фичи типа Guaranteed-rate I/O и поддержка иерархии сторейджей и тп. Ну и если вспомнить сколько проблем было там со стэком (в оригинальном коде много вызовов функций, на SGI IRIX это было ок, а на x86 не хватало стэка и приходилось ядро собирать с поддержкой large stacks, что ломало некоторые другие вещи) и тп.
А XFS умел в "убран менеджер томов", очень интересно.
Ого, перечислетите тех, кто умеет в "убрана поддержка блоков > 4K"
"фичи типа Guaranteed-rate I/O" - бред
"поддержка иерархии сторейджей" - офигеть, одна фс, один путь!
Интересные фичи вырезали чтобы врагам не достались.Интересно вот ZFS угробят в конец или таки пожалеют.
zfs гробят сами "враги", которым она, к сожалению, досталась.От переписывания на криволинукс, не умеющий управлять памятью (хихи, еще и стековой тоже, оказывается? Я думал, там только кучей не умеют.) до полного отсутствия в 2k22 средств восстановления - не считая единственной закрытой коммерческой программы под угадайте какую ОС.
Поздно там уже жалеть, зак@пывайте - и кол, кол осиновый тащите, "это уже не Джонни!"
Скорее уж WD (обещала) перепишет нам нормально raid6 в btrfs, или рептилоиды открыто возьмут власть и начнут нас просто есть. (В порядке возрастания вероятности событий.)
Интересно, чем это ее гробят?
Хреновой реализацией и созданием проблем которые согласно бизнес модели "спонсоров" должна решать их техподдержка по подписке.
Нет. Это сказка из серии страшных и ужасных бэкдоров в xfs.
Бизнесмодель спонсоров совершенно другая - продавать фри...тру...хренасы короче.
То есть китайской сборки компьютер с воткнутыми непригодными для zfs (привет, хрюнас из wd red) и вообще любого бизнес-использования дисками по очень вкусным скидочкам (им, разумеется, а не щисливым клиентам) с интуитивно-приятным веб-интерфейсиком. (И еще чтоб докер в докере под докером, конечно.) Ну и fs у них того же качества.Потому что покупатели - хлебушки, и сами ничего собрать и настроить не могут. А на netapp у них нет бабосов и серверрумов с нормальным охлаждением (не говоря про звукоизоляцию).
Решать проблемы ЭТА техподдержка не могет. У нее ни квалификации, ни ресурсов, ни возможностей.
Те кто хотя бы частично пытался следовать твоей бизнесмодели - уже "out of business". https://omnios.org/about/about.html
А торговцы десктопным железом под видом серверного - вполне себе процветают.
> А XFS умел в "убран менеджер томов", очень интересно.Умел, вырезали сказав что дублирование функций LVM не нужно. Но тут невелика потеря.
> Ого, перечислетите тех, кто умеет в "убрана поддержка блоков > 4K"
Эмм. Ну NТFS например умеет под виндой, поэтому под линуксом тоже пришлось поддерживать.
XFS на IRIX умеет блоки до 64К. А под линуксом это не работает, из man.xfs:
-b block_size_options
Section Name: [block]
This option specifies the fundamental block size of the
filesystem. The valid block_size_option is:size=value
The filesystem block size is specified with a
value in bytes. The default value is 4096
bytes (4 KiB), the minimum is 512, and the
maximum is 65536 (64 KiB).Although mkfs.xfs will accept any of these
values and create a valid filesystem, XFS on
Linux can only mount filesystems with pagesize
or smaller blocks.
> "фичи типа Guaranteed-rate I/O" - бредПочему бред? Это для рилтаймовых систем, можно открыть поток чтения/записи, которому нужно гарантировать пропускную способность не менее такой-то (или несколько), и другие запросы на ввод/вывод на этот диск не смогут этим потокам помешать. Т.е. специализированный шедулер IO внутри ФС. Ничего страшного тут нет, в том же ZFS тоже свой шедулер внутри и ему стандартный линуксовый для блочных устройств только мешает (и она его отключает).
Но в линукс версию XFS это не вошло.
> "поддержка иерархии сторейджей" - офигеть, одна фс, один путь!
Ну что-то в линуксе это все пытаются переизобрести, то в btrfs никак не могут допилить, то костылями типа bcache, то вовсе работающих решений кроме как взять сомнительный по лицензии zfs нет..
Задача иметь tiered storage с быстрыми SSD первого уровня, медленными второго, жесткими дисками третьего например довольно много где встречается, и когда ФС ее умеет решать, это неплохо. А внешними средствами эффективность совсем не та выходит.
LVM хорош уже тем, что в pvmove умеет. Понятия не имею, как это было(было ли) в XFS реализовано.Ну, btrfs тоже умеет в блоки >4k, вот только монтироваться не будет на amd64/x86_64. Кстати, очень удобно то, что btrfs умеет в разные уровни четности над блочными устройствами. Правда, я предпочитаю над lvm собирать, и только дома.
Я, вероятно, несколько поторопился с ответом(сколько раз давал зарок бухим не писать :)), RT на уровне ФС - штука весьма спорная, мы же не про rtdev говорим?
Позвольте не согласиться, я лучше ФС знаю, какие данные где хранить, bcache - не панацея, но штука работающая, пусть и не всегда так, как задумывалось :) Я бы с удовольствием посмотрел на фс с tiered storage levels, вот так с ходу в голову ничего не приходит, а было бы неплохо. Наверное. На данный момент я считаю, что фс не справится с задачей распределения данных.
А можно поподробнее про размер стека? Почему на ириксах это к проблемам не приводило?
> А можно поподробнее про размер стека? Почему на ириксах это к проблемам
> не приводило?Потому что архитектура процессора другая и ядро другое. В реализации xfs много вложенных вызовов и стэк вырастал больше того, которое ядро давало по умолчанию (все ж таки линукс для десктопов, нельзя просто так взять и выдать сразу всем кучу стэка, как на серверных ОС.. я утрирую но идея понятна :) А стэк нужно выдавать сразу всем процесам, тредам и тп)
В итоге под линуксом не один год вылезали проблемы типа такой https://access.redhat.com/solutions/54544
Тк в тредах ядра для экономии памяти использовали 4К стэк. В итоге пришлось убирать экономию и на десктопах тоже брать 8К стэк, а когда пришел x86-64, экономить и вовсе перестали. Но и в 8К стэк можно упереться, как оказалось, в итоге решили что придется 16к стэк брать...
Т.е. проблема не в рекурсивном спуске(предположительно), а в релизации стэка? Ну, хрен знает, не в курсе проблемы, на вскидку по ссылке проблема с кэшем инодов.
Спасибо за информацию, изучу. А в ириксе размер стека был больше, или параметры передавались через регистры, или что? Почему там не было проблем?
Дело не в архитектуре провессора (MIPS - это примитив полнейший, i386 продвинутее был), а в том, что в лайноксе управление памятью кривое. Там под стек выделяется страница либо их пара, а сделать по-человечески коран не позволяет.
Может идиот и понимает.
Но тру Си программисты далеко не идиоты.
Знал я, что XFS - зло. Никаких преимуществ поверх ext4 практически нет, зато бэкдоры - пожалуйста.
У ext4 вообще никаких нет.
Ну как же нет. Хотя бы отсутствие бэкдоров. А ещё распространённость, даже дефолтовость; лучшая чем у xfs устойчивость при отключении питания, наличие драйвера для винды, да и вообще лучше поддержка всяким разным софтом, менеджерами разделов например.
> да и вообще лучше поддержка всяким разным софтом,Ну да..
STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the
WiredTiger storage engine
STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
Они знали про бекдор! Это сговор!
Какую-то фигню написал про поддержку софтом, а на другие агрументы вообще ответа нет. Слив защитан.
Никто не спорит: у ext4 нет никаких преимуществ перед ext4.
она быстрее на больших файлах, сильно быстрее, раньше использовал XFS, отказался
А главное она эти большие файлы куда быстрее чем EXT3 удаляет. Вот уж проблема была...
>Никаких преимуществ поверх ext4 практически нетПо сравнению с extX, любая ФС с динамическими нодами - преимущество.
NTFS лучше всего
неимоверно быстро фрагментируется тварь
> неимоверно быстро фрагментируется тварьЭто косяк ntfs.sys, а не файловой системы.
Diskeeper продаёт FS filter поверх NTFS, который сводит фрагментацию к минимуму. Стоит крутых бабок, но он реально работает.
// b.
Оно уже давно не Diskeeper, аDymaxIO by Condusiv
Можно подумать, brtfs и прочие не имеют этой проблемы. В линуксе нет нормально дефрагментатора, к сожалению. Только какой-то shake-fs, но это не совсем дефрагментатор, он просто копирует каждый файл в надежде, что копия будет менее фрагментированной. Да и то, эта утилита не обновлялась уже несколько лет
У лялиха сильно больше 2.5 фс виндовых, поэтому дефрагментатор - задача сильно фс-специфичная. Тот же btrfs умеет в defrag, для extX тоже были, сейчас не знаю. Проблема(надуманная) в VFS, нет там возможности писать в bdev куда захочешь, надо же :)
Куча ФС, и ни одной рабочей.
e4defrag
Говорить про фрагментацию в эпоху SSD это прям трэш какой-то.
У меня 7 летний HDD, причём с пониженной скоростью, 5400 об/мин вместо стандартных 7200, так что за всех не говори
Возвращайся, когда 100 терабайт ссд можно будет напихать в обычный системник (в идеале реалистично в пределах 1500 баксов).
А зачем в обычный системник 100ТБ пихать? Обычному пользователю нужно видосики 4k хранить, зачем ему снапшоты, рефлинки, дискарды?
Видосики в 4к (да даже с нормальным качеством) занимают все 100 тб довольно быстро и без снапшотов. Понадобится где-то 3 месяца на плохом интернете. На типичном среднем 5-гигабитном линке что-то около 2 суток.
Ого, 3 месяца непрерывной записи? Мне лень считать, верю на слово.
А сколько человеко-месяцев нужно на просмотр? Дети не сильно видят разницы между 4к/720, они основные потребители стриминга. Сколько % было прочитано хотя бы 2-3 раза?
Разница между 720 и 1080 очень ощутима, мыльное мыло плохо сказывается на психическом здоровье. 4к намного лучше картинку даёт. Никогда не знаешь, какой контент потребуется несколько раз. К тому же, локальный поиск намного эффективнее. Мой рекорд что-то порядка 20 часов просмотра стримов в день, 1 стрим там был 12 часов правда. Спать тоже нужно. Было весело. А если это кинофильмы? 2 часа где-то 50 гб уже.
Ну, что сказать, "Мой рекорд что-то порядка 20 часов просмотра стримов в день", каким боком здесь?
Если зарабытваешь на стриминге и не умеешь в хранилку, страдай. Уверен, тебе продадут :)
Ну, ты спросил сколько человеко-месяцев нужно на просмотр, учитывая среднее количество потребляемого контента от 10 до 20 часов в сутки и зная битрейт, можно посчитать. Тому, кто стримит, или вообще создаёт контент, понятно нужно куда больше места для файлов.
можно ли назвать комп того кто стримит обычным?
Что-то не понимаю. Что нельзя назвать обычным на компе того, кто стримит? Плату захвата с кодировщиком и внешнюю звуковую карту? Может быть, микрофон за 100 баксов? Или айфон? Да не, вроде тоже обычное, к тому же всё довольно опционально. Железо далеко не главное, а софт уже много лет поставляется прямо с видеодрайвером и теперь с операционкой (я не проверял). Куда уж обычнее.
> Мой рекорд что-то порядка 20 часов просмотра стримов в день, 1 стрим там был 12 часов правдаИзвините, а это по работе, или это такое хобби?
Это по учёбе, очевидно же. Где ещё практиковать японский язык?
> Это по учёбе, очевидно же. Где ещё практиковать японский язык?Ну прямо вообще, очевидней некуда.
И вот 20 часов подряд, иначе никак?Ну и если это не троллинг про хентай, то наверное можно догадаться что запрос не совсем типовой :)
А как давно у вас 100Тб хдд стали стоить дешевле 1500 баксов?
Какой рейд при этом использовали?
А то, что хранят на больших дисках, как раз от фрагментации практически не страдает. Там как не пиши - у тебя многомегабайтные чанки получаются,и алгоритмы ФС с ними прекрасно умеют разбираться.
Достаточно иметь 1 дописываемый файл чтобы он оказался размазанным равномерным слоем по всем пластинам, какая разница, какие там чанки? Ощутимая фрагментация начнётся когда старые данные понадобится удалять. Венда так особенно мастер 1 мегабайт кэша браузера разбить на 100000 фрагментов.
Нормальноhttps://www.hanselman.com/blog/the-real-and-complete-story-d...
> Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled. This is by design and necessary due to slow volsnap copy on write performance on fragmented SSD volumes. It’s also somewhat of a misconception that fragmentation is not a problem on SSDs. If an SSD gets too fragmented you can hit maximum file fragmentation (when the metadata can’t represent any more file fragments) which will result in errors when you try to write/extend a file. Furthermore, more file fragments means more metadata to process while reading/writing a file, which can lead to slower performance.
Нормальный мир — это не какой-то абсолютизм. И на SSD, и на ОЗУ даже не значит, что ты можешь хранить данные как хочешь, и это не будет влиять на производительность.
> Говорить про фрагментацию в эпоху SSD это прям трэш какой-то.а ты вообще не задумывался почему мелкоблочное чтение для SSD и последовательное отличается на несколько порядков?
но речь не о том, ты считаешь, что у HDD нет на сегодняшний день применения?
у меня есть рейд массив который хранит медиатеку и другие блобы, устоявшаяся последовательная скорость чтения/записи быстрее большинства одиночных NVMe на рынке
стоимость хранения по сравнению с SSD меньше в ПЯТЬ раз
мамкин хакер поставил себе 2 тб в ноутбук и загоняет пургу
даже если я сделаю 25x2TB SATA SSD - это будет всего 50 TB, но с космическим ценником
для кровавого энтепрайза сойдет, но для таких товарищей уже есть NVMe решения, притом со своими файловыми системами и зонированием
а для Nearline или для вместительного домашнего хранилища HDD все еще актуально
Поддержка reflink в XFS — существенное преимущество, т. к. дает возможность создавать быстрые снимки (клоны) файлов и выполнять дедупликацию. Ext4 лучше только тем, что позволяет уменьшать раздел без переформатирования.
Эх, молодость :) А когда reflink в xfs появился?
Появился в ядре 4.9, стал юзабельным по факту где-то в 4.13, объявлен стабильным в 4.16.
Ну, т.е. на проектах длиной чуть больше, чем "сегодня пишем, завтра продаем" не особо применимо.
sudo xfs_info /dev/mapper/pg01-db
meta-data=/dev/mapper/pg01-db isize=256 agcount=128, agsize=33554432 blks
= sectsz=512 attr=2, projid32bit=0
= crc=0 finobt=0, sparse=0, rmapbt=0
= reflink=0
data = bsize=4096 blocks=4294967296, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=0
log =internal log bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
"выполнять дедупликацию" неа, так как длина экстента переменная.
JFS рулед.
> Никаких преимуществ поверх ext4 практически нетА пониз? 😊
Просто рeшeто какое-то...
146% это было сделано чтобы оно меньше тормозило, это же нужно байтики зачищать и тратить на это такты.
Уровень эксперта впопеннета не позволил ему даже понять, что нет, не такты, а вполне себе реальные физические перемещения голов диска, выполняемые на два порядка дольше. (причем если нам нужны ГАРАНТИИ что враг не доберется до с-ка нужной и важной мусорной информации в произвольном секторе диска, что само по себе бред собачий - то еще и синхронные)Да, во времена sgi это было очень дорогой операцией (могли ли эксперты подумать и было ли им чем?). А околонулевая вероятность, что в 4095м байте найдется пароль от всего пентагона, вменяемых людей вообще не беспокоила - они знали что такие файлы не удаляют просто так, а вайпают несколько раз подряд.
Сейчас времена, конечно, изменились. Разумеется, в пентагоне точно такие же девляпсы положат пароль от всего ровно так. А потом "троянец, троянец!"
ну да бэкдор с 1991 года
> wget http://lib.ru/SHAKESPEARE/ENGL/hamlet_en.txt -O hamlet_en.txtКак мило. Роскомнадзору только не показывайте.
Наследники Шекспира в Мосгорсуде засудят?
Легко. Или кто-то будет сильно разбираться?
Обладатели 42-х хромосом засудят,когда им бананов в клетку подкинут. Правда получится как с tor.eff.org
За свободное цитирование произведений, являющихся общественным достоянием, например, таких, как Конституция РФ
Любая файловая система в линукс имеет кучу уязвимостей, потому что линукс делают трое студентов за бесплатно. NTFS не имеет ни одного недостатка перед линуксовыми файловыми системами, смотрите тесты производительности
>Любая файловая система в линуксРеализация NTFS есть в Линукс. Это не значит, что в ней нет уязвимостей.
>потому что линукс делают трое студентов за бесплатно
А Windows делают корпоративные специально обученные сотрудники. Платят ли им именно за отсутствие уязвимостей - вопрос открытый.
>три студента забесплатноВинду "разрабатывают" только майки, и бог знает что они туда накодили. Линукс и кучу софта, которое адекватно работает только на нём, разрабатывают в том числе компании, указанные в Linux Foundation. А тесты производительности - это тесты конкретной реализации. Кто знает, может там тоже отключали зануление памяти, чтобы такты сохранить. Да и мои глаза мне говорят, что производительность одинаково хорошая/плохая.
"Есть в Линукс"? Вы, макаки, русский язык не знаете? "В Линуксе", а не "в Линукс".
При отсутствии предваряющих нарицательных склонение наименований (брендов, марок,...) требуется!!!Прафессар, опыннет, пилят.
> потому что линукс делают трое студентов за бесплатноПрочитал, как будто снова в нулевые попал. Кто-то из криокамеры похоже только что вылез.
Слишком толсто, толще даже клоуна Карманова.
Попробуй потоньше
> NTFS не имеет ни одного недостатка перед линуксовыми файловыми системами, смотрите тестыNTFS умирает при работе с сотнями тысяч мелких файлов - так что не всё так однозначно.
По части надёжности - да, ничего в Linux рядом не валялось.
// b.
Я не видел таких регулярно рассыпающихся и теряющих файлы фс как нтфс в линуксе, может быть, зфс -- не знаю того что не использовал.
Ну так-то сравнивать NTFS в Windows и NTFS на Линуксе некорректно, разная реализация и даже уровень экспертизы при реализации. Под Виндоус тоже можно поставить Ext2FSD и пользовать EXT2 почти как нативную ФС, вот только гарантий само собой никаких.
Я сравниваю с линуксовыми фс. И венда вроде на бтрфс ставится, слышал много восторженных отзывов. Всяко лучше нтфс будет.
Зачем в Линуксе использовать NTFS? Разве что для обмена данными с Виндой, но тут имхо есть варианты и получше.
Только пару лет назад исправили очередной баг где нтфс в венде рассыпалась, но меня не затрагивало в этот раз потому что сжатие/шифрование/квоты это просто сразу нет, уже давно понятно.
Не затруднит привести статистику по багам в месяц на нтфс и на линуховые фс? Или просто рассказы - а у них там негров линчуют? Использую в куче мест нтфс с дедуп. Проблем как не было так и нет. А екстфс несколько раз разваливалась.
Съели, линуксоиды?
Друк мой, общественность настаивает на деклассификации эксперимента, снимайте гриф секретности уже, мы заждались Ж) Информейншн маст би фри!!!
Нтфс исключительно плохо с мелкими файлами работает. Я имею в виду, еът4 с миллиардом файлов в 1 каталоге тоже не шик, но нтфс это прям дно-дно, что можно наблюдать ежедневно. Не говоря про фрагментацию.
В еът4 (читаеся как еЙт4, кстати) млрд. файлов в одной директории - это вызов. Точно проверяли?
Да, мне мне очень понравилась база cddb, тут больше вопросов к софту чем к ядру даже. У меня есть ещё несколько таких архивов текстовых файлов под пол терабайта и коллекция пожатых сканов на несколько терабайт.
Там ещё где-то рядом архив с нотами валяется, не помню сколько терабайт, но тоже много файлов в 1 каталоге. С большими файлами намного лучше ситуация, когда 1000 файлов лежат одной кучей и занимают 10 терабайт это ничего страшного.
настолько жырно, что нужно тереть без объяснения причин
А оно похоже старенькое.
Нинужно. Есть божественный ext2, самый быстрый и самый безпроблемный. Хотя, с массовым переходом на SSD, вообще стоило бы отказаться от такого рудимента, как файловая система.
И как же вы тогда предлагаете хранить файлы? В БД которая будет лежать на сыром блок-девайсе?
> В БД которая будет лежать на сыром блок-девайсе?* Firebird
* Oracle
* MySQL/InnoDB
* MSSQL
* IBM DB2Пять штук хватит?
// b.
БД это же медленнее, чем файлы на ФС.
> БД это же медленнее, чем файлы на ФС.Бабушка надвое сказала.
Если у вас таблица с записями строго определенного размера, то добавление новых записей в неё будет настолько быстрым насколько позволяет storage.
ФС придётся писать данные, метаданные, что-то там обновлять, проверять и прочее.
// b.
> Если у вас таблица с записями строго определенного размера, то добавление новых записей в неё будет настолько быстрым насколько позволяет storage.Лицо на фотографии должно быть квадратным, а все файлы должны быть одного размера с одинаковой длины названиями.
Ну, когда-то можно было фс использовать как БД.
> а все файлы должны быть одного размера с одинаковой длины названиями.просто с одинаковыми названиями. Так можно сэкономить дофига байтов!
ФС и есть база данных.
А современные ФС вроде всяких ZFS так вот конкретно к классическим БД самое прямое отношение имеют.Проблема всех ФС в том, что база эта идиотская.
Древовидная структура папочки и файлы, картотека пыльного офиса из 60х годов прошлого столетия.
"Исправление вошло в версию 5.16, а также в обновления ядер 5.15.14, 5.10.91, 5.4.171, 4.19.225 и т.д."Паршивенько то, что в Убунте 21.10 ядрышко 5.13
21.10 это экспериментальная с полгодом поддержки, нужно использовать только LTS
Странно, а на сайте пишут что Stable
обмажут патчами
Ну да, линуксу далеко по стабильности BSD с UFS и ZFS.
XFS это ФС из Irix. ZFS из солярки. UFS - тормозное г*вно, к которому журнал привинчивали ХЗ сколько лет.С разморозкой.
// b.
> UFS - тормозное г*вно,
> // b.Ну, //b из под вендочки всяко виднее.
Шта?$ uname -a
Linux localhost.localdomain 5.15.14-az2 #1 SMP PREEMPT Wed Jan 12 00:29:24 2022 x86_64 x86_64 x86_64 GNU/Linux// b.
> Шта?
> $ uname -a
> Linux localhost.localdomain 5.15.14-az2 #1 SMP PREEMPT Wed Jan 12 00:29:24 2022 x86_64
> x86_64 x86_64 GNU/Linux
> // b.Я тебе страшный тайна открою - UFS в Linux ни разу не нативный. И скорее всего, не сможет нормально прочитать современный BSDшный UFS - ino64 в него, ЕМНИП, никто не завозил.
Comrade, я сижу под Линуксом больше лет, чем ты родился, если ты не знаешь кто я, во-вторых думаешь, что я сижу под Windows. Да, когда гамаю, запускаю Windows 10, но последний раз это было месяц с лишним назад. Увы, заниматься сексом с Линуксом (я про игры) желания нет. Под остальное - нехай.
Сижу под линуксом еще дольше тебя и играю под нем без каких либо проблем через протон. Window 10 запускаю только ради лайтрума и фотошопа.
А хрен ли ты вмешался, когда я не с тобой говорил?Photoshop CS2 под Wine отлично работает.
А вот терять FPS и не иметь никакого аналого NVIDIA Control Panel под Линукс желания нет (nvidia-settings - убогое говно по возможностям).
Кстати, насчёт дольше меня.Что прямо раньше 1997 года сидишь?
А если не врать?
Ты прям с 97-го? И на чём и как ты работал, скажем, года с 97-го под нулевые?
> Comrade, я сижу под Линуксом больше лет, чем ты родился,Ты точно сидишь под Линуксом с 1980 года?
> если ты не знаешь кто яКакое восхитительно раздутое ЧСВ!
Это же сам Анон, ты чего ! :)
Держу тор-ноду на линуксе со времен великой французской революции. Сосунки!
> UFS - тормозное г*вноСтранно. Инженеры Netflix (более 20% трафика планеты, на минутку) имеют диаметрально противоположное мнение, будучи уверенными, что UFS — единственная ФС на планете, позволяющая серверу отдавать шифрованное видео на скорости 400 Гб/с: https://people.freebsd.org/~gallatin/talks/euro2021.pdf
Но опеннетным экспертам по проперживанию диванов, разумеется, видней…
«Проблема цитат в интернете заключается в том, что люди безоговорочно верят в их подлинность» — сказал как-то Владимир Ленин, после чего залил на YouTube видео со штурмом Зимнего.В документе НОЛЬ упоминаний ufs. И, полагаю, она если вообще используется "инженеграми нетфликса" - то только для загрузки операционной системы.
А что инженегры нетфликса вынуждены исполнять бредовые требования и тратить терафлопсы (я уж молчу про пропихивание вредного и ненужного кода в ядро системы) на никому ненужное ШИФРОВАНИЕ УЖЕ _drm_protected_, блжад, видео которое без гуглоплагина вообще невозможно расшифровать - ну так раб ничего не решает, просто веслает. Они там хорошие рабы, веслают интенсивно. А что команды отдает не идиот - такого в списке требований не было.
> В документе НОЛЬ упоминаний ufs.В данной презентации UFS не упоминалась, зато упоминалась в обсуждении этой презентации: https://news.ycombinator.com/item?id=28584738
> И, полагаю, она если вообще используется "инженеграми нетфликса" - то только для загрузки операционной системы.
Юноша, пока вы полагаете, инженер Netflix располагает (ссылка на коммент из вышеуказанного обсуждения): https://news.ycombinator.com/item?id=28585528
— We use ZFS only for boot/root/logs, and UFS for content.
Ну то есть хз для чего на самом деле.Поскольку вообще не факт что раздающие пулы к которым имел отношение тот инженегр имеют хоть какое отношение к хранилке, а про архитектуру неизвестно ровно ничего.
Ч.т.д. - вы не в курсе и просто цитируете непонятно что вырванное из непонятного контекста, а для завязки разговора привели документ, который даже не читали, не имеющий ни малейшего отношения к делу вообще.
Ну и да, чтоб 2 раза не вставать.
Результаты нагрузочного тестирования ZFS vs UFS: https://savagedlight.me/2012/07/16/freebsd-filesystem-perfor.../
синтетический тест тестирующий вообще непонятно что и непонятно зачем? Ну ооок.Причем - 2012го года, когда zfs не имела ни м-цкого ABD, ни других привнесенных линуксами проблем - правда, зато умела съесть всю память и крэшнуться, если не озаботиться заранее костыликами и подпорочками.
И да, очень странно тестировать "raidZ" vs ufs вместо geom raid + ufs на том же железе.
P.S. единственное что в этом тесте интересно - это что он подтверждает умение zfs извлекать пользу из распределения блоков по разным дискам. Что, как показал опыт md raid, не всем удается с первой попытки, и с третьей тоже. Впрочем, опять же, это совсем не та zfs.
Что-то пролистал слайды, и ничего не увидел про UFS. На котором слайде там про UFS?
> Что-то пролистал слайды, и ничего не увидел про UFS.В данной презентации UFS не упоминалась, зато упоминалась в обсуждении этой презентации: https://news.ycombinator.com/item?id=28584738
Ссылка на уточняющий коммент из вышеуказанного обсуждения: https://news.ycombinator.com/item?id=28585528
— We use ZFS only for boot/root/logs, and UFS for content.
> тормозноеЯ тоже играю в NFS "газ в пол". Плохо, что еще рулить надо.
Да, но их измордовали, чтобы запихать в лайнокс.
> линуксу далеко по стабильности BSD с UFS и ZFS.вот это вот как-раз самое слабое место bsd
Однако!
Все технологии передаваемые линуксоидам можно считать похороненными заживо, вот только несколько примеров
- Xen от Citrix закопала Linux Foundation в угоду убогому KVM который успешно похоронил Docker
- VNC угробила красношляпа в угоду своему SPICE который успешно помер так и не родившмись(Double-kill че скажешь)
- XFS угроблена редгадом из-за жопоболи по причине невозможности стырить ZFS и каличной Btrfs, отчего XFS начала мутировать в сторону ZFS
- Lustre похоронена все тем же редгадом в силу прогресирующего NIH-синдрома в виде мерзкой и тормозной GlusterFS
Xen - та еще хрень, впрочем, ее за бапки продают, не? KVM чем прям убог?
VNC и SPICE сравнивать, как минимум, странно. А еще они оба хуже RDP в моменте. Citrix тоже срань. Да и RDP срань.
А можно про XFS поподробнее? Там ТП уже ничего про XFS не спрашивает? А то ходили слухи, что услышав про extX отказывали в тп.
Lustre -хз, поделИтесь.
>>VNC и SPICE сравнивать, как минимум, странно. А еще они оба хуже RDP в моменте. Citrix тоже срань. Да и RDP срань."Всё на свете г+вно, кроме мочи"..? :D
Да здравствует nvidia облачный гейминг
KVM:
1. Позволяет виртуализацию только 2-го типа (т.е., тормозную)
2. Под него нет вменяемого VMM (qemu - это совсем конченое поделие)
>KVM который успешно похоронил Dockerдокер труп, ага, а какая связь с xfs?
Docker похоронил KVM, что ага? Бугага
"Без измен!"© Д.Гайдук (запрещённый в России писатель)
* Xen — Успешно развивается, несмотря на титанические усилия RH по выпиливанию из своих сборок. Amazon всё ещё на xen, плюс нишевые решения. У меня поверх OEL-8 dom0 едут (может как-нибудь статью напишу, но не на opennet понятно), у коллег так вообще на debian.
* VNC — просто не развивается, но то скорее по причине "семи нянек". Так-то, в последних qemu vnc спокойно собирается и работает. Глюковатый модуль для Xorg — тоже вроде на месте. А кому нужно для вяленого гнома — ну, не знаю.
* XFS — наименее глючная в _современном_ ряду экстентных ФС. По моему опыту. Правда, есть нюанс: xfs я пока наблюдаю сотни хостов, а "исторически сложившихся" ext4 — с десяток тысяч.
* Люстра — это скорее про IBM, и там говорят всё хорошо (если есть много денег). Серверная часть наглухо пропиетартая и шансы получить "на шару" как с zfs — околонулевые. Все остальные (а это скорее не Gluster а Ceph) — "хочу чтобы как люстра, но за так".
Не вижу в списке jfs, попавшей туда из условно живого aix (либо из 20 лет как мертвой полуоси)
> Поскольку ioctl(XFS_IOC_ALLOCSP) и ioctl(XFS_IOC_FREESP) по функциональности практически не отличаются от стандартного fallocate(), и единственным их отличием является утечка данных, их наличие похоже на бекдор.SGI c Irix бекдоры портируют.
> читать данные неиспользуемых блоковА зачем читать неиспользуемые блоки?
Как?!! Вы храните мегасекурную информацию, top-secret-home-porno-cats.mp4 и фоточки жратвы,
но не юзаете шифрование, обнуление/рандомизацию при удалении???
Ну хотя бы 'shred -fuz top-secret-home-porno-cats.mp4' пытались?
до кучи - все это делать надо еще и на мультиюзерской системе, где реально существует риск что кто-то что-то запишет в ручном режиме (а не через десять прослоек) и правда сможет что-то прочитать, принадлежавшее до этого не ему же самому.В общем, как обычно, ужасные страшные бэкдоры существуют только в воображении местных фантастов.
Кто переживает за утечку данных, у тех провод на 220В излучает магнитное поле не дальше 2 мм.
А, открою страшную тайну, в неиспользуемые блоки ещё и писать можно.
Шалунишка!
В обход фс? А если оно молча и не понимая ничего что-то запишет и данные потеряются?
Переведу на русскай, новые данные пишутся только в неиспользуемые блоки. ))Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
потом уже законно считывать и грепать там старую инфу.
> Переведу на русскай, новые данные пишутся только в неиспользуемые блоки.
> ))
> Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
> потом уже законно считывать и грепать там старую инфу.Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним байтом, без затирания последующих?
>Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним байтом, без затирания последующих?В этом собственно и заключается уязвимость, что XFS такую возможность предоставляет
>> Переведу на русскай, новые данные пишутся только в неиспользуемые блоки.
>> ))
>> Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
>> потом уже законно считывать и грепать там старую инфу.
> Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним
> байтом, без затирания последующих?Зачем тебе если такую примитивную фичу не можешь реализовать?
Больше дырок - хороших и разных
Афегеть. Как спорцмены могут разбератся во всех этих штуках? А тренеровке?