forum.opennet.ru - "Уязвимость в XFS, позволяющая читать сырые данные блочного устройства " (154)

"Уязвимость в XFS, позволяющая читать сырые данные блочного устройства "

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

"Уязвимость в XFS, позволяющая читать сырые данные блочного устройства "	+/–
Сообщение от opennews (ok), 14-Янв-22, 18:40
В коде файловой системы 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
Ответить \| Правка \| Cообщить модератору

Оглавление

А вот Линус считает что похоже на давно устаревший код, но никак не на бекдорUPD, макпыф (ok), 18:40 , 14-Янв-22, (1) +5

Да всё ядро можно устаревшим кодом назвать, столько мусора ещё никуда упихнуть н, Аноним (3), 18:43 , 14-Янв-22, (3) –8
Забыть занулить выделяемый непривилегированному блок с диска - похоже скорее на , Аноним (5), 18:45 , 14-Янв-22, (5) –2

возможно и так, макпыф (ok), 18:49 , 14-Янв-22, (6) –1

То есть никто не понимает, зачем mkfs xfs вызывается с ключем -K , Bx (ok), 02:00 , 15-Янв-22, (77)

Silicon Graphics её делала для Irix , Аноним (11), 19:21 , 14-Янв-22, (11)

Только в линукс вошла далеко не та реализация Во-первых весь этот код с новыми , Анонимленьлогиниться (?), 20:13 , 14-Янв-22, (20) +7

А XFS умел в убран менеджер томов , очень интересно Ого, перечислетите тех, кто, Bx (ok), 04:32 , 15-Янв-22, (98) –2

Интересные фичи вырезали чтобы врагам не достались Интересно вот ZFS угробят в к, Аноньимъ (ok), 05:18 , 15-Янв-22, (100) –3

zfs гробят сами враги , которым она, к сожалению, досталась От переписывания на, пох. (?), 07:21 , 15-Янв-22, (104) +1

Интересно, чем это ее гробят , Ващенаглухо (ok), 21:39 , 15-Янв-22, (146)

Хреновой реализацией и созданием проблем которые согласно бизнес модели спонсор, Аноньимъ (ok), 22:25 , 15-Янв-22, (148)

Нет Это сказка из серии страшных и ужасных бэкдоров в xfs Бизнесмодель спонсоро, . (?), 21:31 , 17-Янв-22, (161) –1

Умел, вырезали сказав что дублирование функций LVM не нужно Но тут невелика пот, Анонимленьлогиниться (?), 21:35 , 15-Янв-22, (145) +3

LVM хорош уже тем, что в pvmove умеет Понятия не имею, как это было было ли в , Bx (ok), 02:38 , 16-Янв-22, (150)

А можно поподробнее про размер стека Почему на ириксах это к проблемам не приво, Аноним (137), 18:46 , 15-Янв-22, (137)

Потому что архитектура процессора другая и ядро другое В реализации xfs много в, Анонимленьлогиниться (?), 21:44 , 15-Янв-22, (147) +1

Т е проблема не в рекурсивном спуске предположительно , а в релизации стэка Ну, Bx (ok), 02:49 , 16-Янв-22, (151)
Спасибо за информацию, изучу А в ириксе размер стека был больше, или параметры , Аноним (154), 23:14 , 16-Янв-22, (154)
Дело не в архитектуре провессора MIPS - это примитив полнейший, i386 продвинуте, A.N. Onimous (?), 02:29 , 30-Янв-22, (167)

Может идиот и понимает Но тру Си программисты далеко не идиоты , Аноньимъ (ok), 05:17 , 15-Янв-22, (99) –2

Знал я, что XFS - зло Никаких преимуществ поверх ext4 практически нет, зато бэк, Аноним (5), 18:41 , 14-Янв-22, (2) –22

У ext4 вообще никаких нет , hohax (?), 18:56 , 14-Янв-22, (9) –3

Ну как же нет Хотя бы отсутствие бэкдоров А ещё распространённость, даже дефол, Аноним (15), 19:37 , 14-Янв-22, (15)

Ну да code STORAGE initandlisten WARNING Using the XFS filesystem is s, hohax (?), 20:04 , 14-Янв-22, (17) –1

Они знали про бекдор Это сговор , Аноним (21), 20:26 , 14-Янв-22, (21)
Какую-то фигню написал про поддержку софтом, а на другие агрументы вообще ответа, Аноним (15), 02:49 , 15-Янв-22, (89) –1

Никто не спорит у ext4 нет никаких преимуществ перед ext4 , К.О. (?), 20:31 , 14-Янв-22, (22) +2
она быстрее на больших файлах, сильно быстрее, раньше использовал XFS, отказался, penetrator (?), 21:50 , 14-Янв-22, (35) –1

А главное она эти большие файлы куда быстрее чем EXT3 удаляет Вот уж проблема б, Kuromi (ok), 22:29 , 14-Янв-22, (51) +1

По сравнению с extX, любая ФС с динамическими нодами - преимущество , Аноним (11), 19:23 , 14-Янв-22, (13) +8

NTFS лучше всего, Аноним (32), 21:41 , 14-Янв-22, (32) –2

неимоверно быстро фрагментируется тварь, penetrator (?), 21:52 , 14-Янв-22, (37) +4

Это косяк ntfs sys, а не файловой системы Diskeeper продаёт FS filter поверх NTF, Аноним (52), 22:33 , 14-Янв-22, (52) –2

Оно уже давно не Diskeeper, аDymaxIO by Condusiv, Аноним (52), 00:28 , 15-Янв-22, (69)

Можно подумать, brtfs и прочие не имеют этой проблемы В линуксе нет нормально д, Аноним (32), 23:01 , 14-Янв-22, (59) –2

У лялиха сильно больше 2 5 фс виндовых, поэтому дефрагментатор - задача сильно ф, Bx (ok), 02:09 , 15-Янв-22, (79) –2

Куча ФС, и ни одной рабочей , A.N. Onimous (?), 03:32 , 30-Янв-22, (168)

e4defrag, GenuZ (ok), 16:17 , 18-Янв-22, (163) +1

Говорить про фрагментацию в эпоху SSD это прям трэш какой-то , Аноним (62), 23:44 , 14-Янв-22, (62)

У меня 7 летний HDD, причём с пониженной скоростью, 5400 об мин вместо стандартн, Аноним (32), 01:52 , 15-Янв-22, (76) –2
Возвращайся, когда 100 терабайт ссд можно будет напихать в обычный системник в , Аноним (78), 02:03 , 15-Янв-22, (78) +1

А зачем в обычный системник 100ТБ пихать Обычному пользователю нужно видосики 4, Bx (ok), 02:19 , 15-Янв-22, (81) –1

Видосики в 4к да даже с нормальным качеством занимают все 100 тб довольно быст, Аноним (78), 02:36 , 15-Янв-22, (85)

Ого, 3 месяца непрерывной записи Мне лень считать, верю на слово А сколько чело, Bx (ok), 03:04 , 15-Янв-22, (92) –1

Разница между 720 и 1080 очень ощутима, мыльное мыло плохо сказывается на психич, Аноним (78), 03:16 , 15-Янв-22, (95) –5

Ну, что сказать, Мой рекорд что-то порядка 20 часов просмотра стримов в день , , Bx (ok), 04:16 , 15-Янв-22, (96)

Ну, ты спросил сколько человеко-месяцев нужно на просмотр, учитывая среднее коли, Аноним (78), 04:27 , 15-Янв-22, (97)
можно ли назвать комп того кто стримит обычным , 1 (??), 11:20 , 15-Янв-22, (112)
Что-то не понимаю Что нельзя назвать обычным на компе того, кто стримит Плату , Аноним (78), 11:54 , 15-Янв-22, (114)

Извините, а это по работе, или это такое хобби , RomanCh (ok), 11:11 , 15-Янв-22, (109)

Это по учёбе, очевидно же Где ещё практиковать японский язык , Аноним (78), 11:13 , 15-Янв-22, (110)
Ну прямо вообще, очевидней некуда И вот 20 часов подряд, иначе никак Ну и если э, RomanCh (ok), 17:06 , 15-Янв-22, (132)

А как давно у вас 100Тб хдд стали стоить дешевле 1500 баксов Какой рейд при этом, DeerFriend (?), 12:12 , 15-Янв-22, (115) –3
А то, что хранят на больших дисках, как раз от фрагментации практически не страд, Crazy Alex (ok), 12:46 , 15-Янв-22, (117) –1

Достаточно иметь 1 дописываемый файл чтобы он оказался размазанным равномерным с, Аноним (78), 12:59 , 15-Янв-22, (120) –1

Нормальноhttps www hanselman com blog the-real-and-complete-story-does-windows, iPony129412 (?), 05:55 , 15-Янв-22, (102) –2
а ты вообще не задумывался почему мелкоблочное чтение для SSD и последовательное, penetrator (?), 18:22 , 15-Янв-22, (134)

Поддержка reflink в XFS 8212 существенное преимущество, т к дает возможност, Аноним (34), 21:50 , 14-Янв-22, (34) +4

Эх, молодость А когда reflink в xfs появился , Bx (ok), 02:13 , 15-Янв-22, (80)

Появился в ядре 4 9, стал юзабельным по факту где-то в 4 13, объявлен стабильным, Аноним (93), 03:04 , 15-Янв-22, (93)

Ну, т е на проектах длиной чуть больше, чем сегодня пишем, завтра продаем не , Bx (ok), 03:12 , 15-Янв-22, (94) –1

выполнять дедупликацию неа, так как длина экстента переменная , Аноним (103), 06:45 , 15-Янв-22, (103) +1

JFS рулед , DildoZilla (?), 00:48 , 15-Янв-22, (71) –2
А пониз 128522 , Аноним (164), 22:10 , 18-Янв-22, (164)

Просто рeшeто какое-то 146 это было сделано чтобы оно меньше тормозило, это , Аноним (4), 18:44 , 14-Янв-22, (4)

Уровень эксперта впопеннета не позволил ему даже понять, что нет, не такты, а вп, пох. (?), 13:27 , 15-Янв-22, (121)

ну да бэкдор с 1991 года, полураспад (?), 18:49 , 14-Янв-22, (7) +4
Как мило Роскомнадзору только не показывайте , hohax (?), 18:55 , 14-Янв-22, (8) –3

Наследники Шекспира в Мосгорсуде засудят , Аноним (12), 19:23 , 14-Янв-22, (12) +2

Легко Или кто-то будет сильно разбираться , hohax (?), 20:05 , 14-Янв-22, (18)
Обладатели 42-х хромосом засудят,когда им бананов в клетку подкинут Правда полу, Аноним (21), 20:32 , 14-Янв-22, (23)
За свободное цитирование произведений, являющихся общественным достоянием, напри, Аноним (-), 12:23 , 15-Янв-22, (116)

Скрыто модератором, Аноним (10), 19:00 , 14-Янв-22, (10) –25

Скрыто модератором, Аноним (12), 19:28 , 14-Янв-22, (14) +1
Скрыто модератором, Аноним (21), 20:42 , 14-Янв-22, (24) +1

Скрыто модератором, Здрасьте (?), 22:09 , 14-Янв-22, (43) +1

Скрыто модератором, pavlinux (ok), 16:59 , 15-Янв-22, (129)

Скрыто модератором, Аноним (28), 21:15 , 14-Янв-22, (28) +4
Скрыто модератором, Dzen Python (ok), 21:51 , 14-Янв-22, (36) –1
Скрыто модератором, Аноним (52), 22:03 , 14-Янв-22, (39) –1

Скрыто модератором, Аноним (78), 22:10 , 14-Янв-22, (44)

Скрыто модератором, Kuromi (ok), 22:26 , 14-Янв-22, (48)

Скрыто модератором, Аноним (78), 22:34 , 14-Янв-22, (53) +1

Скрыто модератором, Kuromi (ok), 23:47 , 14-Янв-22, (63) +1

Скрыто модератором, Аноним (78), 00:19 , 15-Янв-22, (68)

Скрыто модератором, Аноним (105), 10:10 , 15-Янв-22, (105)

Скрыто модератором, Bx (ok), 02:28 , 15-Янв-22, (82) –1

Скрыто модератором, Аноним (78), 22:08 , 14-Янв-22, (42) +2

Скрыто модератором, Bx (ok), 02:32 , 15-Янв-22, (83)

Скрыто модератором, Аноним (78), 02:42 , 15-Янв-22, (87)
Скрыто модератором, Аноним (78), 02:48 , 15-Янв-22, (88)

Скрыто модератором, уля (?), 22:41 , 14-Янв-22, (58)

А оно похоже старенькое , псевдонимус (?), 19:58 , 14-Янв-22, (16)
Нинужно Есть божественный ext2, самый быстрый и самый безпроблемный Хотя, с ма, Смузихлёб (?), 20:46 , 14-Янв-22, (25) –1

И как же вы тогда предлагаете хранить файлы В БД которая будет лежать на сыром , Kuromi (ok), 21:17 , 14-Янв-22, (29)

Firebird Oracle MySQL InnoDB MSSQL IBM DB2Пять штук хватит b , Аноним (52), 22:05 , 14-Янв-22, (40) –2

БД это же медленнее, чем файлы на ФС , Специалист (?), 22:22 , 14-Янв-22, (45) +3

Бабушка надвое сказала Если у вас таблица с записями строго определенного размер, Аноним (52), 22:36 , 14-Янв-22, (55)

Лицо на фотографии должно быть квадратным, а все файлы должны быть одного размер, Аноним (61), 23:16 , 14-Янв-22, (61) +5

Ну, когда-то можно было фс использовать как БД , Bx (ok), 02:34 , 15-Янв-22, (84)
просто с одинаковыми названиями Так можно сэкономить дофига байтов , пох. (?), 13:29 , 15-Янв-22, (122) –1

ФС и есть база данных А современные ФС вроде всяких ZFS так вот конкретно к клас, Аноньимъ (ok), 05:23 , 15-Янв-22, (101) +1

Исправление вошло в версию 5 16, а также в обновления ядер 5 15 14, 5 10 91, 5 , Kuromi (ok), 21:18 , 14-Янв-22, (30)

21 10 это экспериментальная с полгодом поддержки, нужно использовать только LTS, Аноним (32), 21:42 , 14-Янв-22, (33) –3

Странно, а на сайте пишут что Stable, Kuromi (ok), 22:24 , 14-Янв-22, (46) –2

обмажут патчами, макпыф (ok), 21:53 , 14-Янв-22, (38) +1

Ну да, линуксу далеко по стабильности BSD с UFS и ZFS , Аноним (31), 21:22 , 14-Янв-22, (31) –6

XFS это ФС из Irix ZFS из солярки UFS - тормозное г вно, к которому журнал при, Аноним (52), 22:08 , 14-Янв-22, (41) +1

Ну, b из под вендочки всяко виднее , Аноним (-), 22:27 , 14-Янв-22, (50) –1

Шта uname -aLinux localhost localdomain 5 15 14-az2 1 SMP PREEMPT Wed Jan 12 , Аноним (52), 22:37 , 14-Янв-22, (56) –1

Я тебе страшный тайна открою - UFS в Linux ни разу не нативный И скорее всего, , Аноним (-), 01:29 , 15-Янв-22, (73)

Comrade, я сижу под Линуксом больше лет, чем ты родился, если ты не знаешь кто я, Аноним (52), 22:40 , 14-Янв-22, (57) –2

Сижу под линуксом еще дольше тебя и играю под нем без каких либо проблем через п, another_one (ok), 23:12 , 14-Янв-22, (60) –2

А хрен ли ты вмешался, когда я не с тобой говорил Photoshop CS2 под Wine отлично, Аноним (52), 00:02 , 15-Янв-22, (66) –1
Кстати, насчёт дольше меня Что прямо раньше 1997 года сидишь А если не врать , Аноним (52), 00:03 , 15-Янв-22, (67)

Ты прям с 97-го И на чём и как ты работал, скажем, года с 97-го под нулевые , Аноним (-), 10:27 , 15-Янв-22, (108)

Ты точно сидишь под Линуксом с 1980 года Какое восхитительно раздутое ЧСВ , Аноним (-), 01:20 , 15-Янв-22, (72)

Это же сам Анон, ты чего , Аноним (-), 01:31 , 15-Янв-22, (74) +2

Держу тор-ноду на линуксе со времен великой французской революции Сосунки , Аноним (111), 11:18 , 15-Янв-22, (111) +1

Странно Инженеры Netflix более 20 трафика планеты, на минутку имеют диаметра, BSDhost (?), 11:35 , 15-Янв-22, (113) –1

171 Проблема цитат в интернете заключается в том, что люди безоговорочно верят, пох. (?), 13:35 , 15-Янв-22, (124) +1

В данной презентации UFS не упоминалась, зато упоминалась в обсуждении этой през, BSDhost (?), 20:03 , 15-Янв-22, (138) –1

Ну то есть хз для чего на самом деле Поскольку вообще не факт что раздающие пулы, пох. (?), 20:32 , 15-Янв-22, (142) –1

Ну и да, чтоб 2 раза не вставать Результаты нагрузочного тестирования ZFS vs UFS, BSDhost (?), 20:10 , 15-Янв-22, (141) –1

синтетический тест тестирующий вообще непонятно что и непонятно зачем Ну ооок П, пох. (?), 20:38 , 15-Янв-22, (143) –1

Что-то пролистал слайды, и ничего не увидел про UFS На котором слайде там про U, anonymous (??), 13:39 , 15-Янв-22, (125)

В данной презентации UFS не упоминалась, зато упоминалась в обсуждении этой през, BSDhost (?), 20:04 , 15-Янв-22, (139) –2

Я тоже играю в NFS газ в пол Плохо, что еще рулить надо , Аноним (-), 12:58 , 15-Янв-22, (119)
Да, но их измордовали, чтобы запихать в лайнокс , A.N. Onimous (?), 04:16 , 30-Янв-22, (169)

вот это вот как-раз самое слабое место bsd , Аноним (-), 22:26 , 14-Янв-22, (47)

Однако , Аноним (54), 22:36 , 14-Янв-22, (54)
Все технологии передаваемые линуксоидам можно считать похороненными заживо, вот , Анонка (?), 00:00 , 15-Янв-22, (65)

Xen - та еще хрень, впрочем, ее за бапки продают, не KVM чем прям убог VNC и SP, Bx (ok), 02:52 , 15-Янв-22, (90) –1

Всё на свете г вно, кроме мочи D, ryoken (ok), 10:13 , 15-Янв-22, (106) –1

Да здравствует nvidia облачный гейминг, Аноним (123), 13:32 , 15-Янв-22, (123) –1

KVM 1 Позволяет виртуализацию только 2-го типа т е , тормозную 2 Под него нет, A.N. Onimous (?), 04:25 , 30-Янв-22, (170)

докер труп, ага, а какая связь с xfs , Аноним (103), 18:36 , 15-Янв-22, (135)

Docker похоронил KVM, что ага Бугага, Анонка (?), 23:55 , 15-Янв-22, (149)

Без измен Д Гайдук запрещённый в России писатель Xen 8212 Успешно разв, PnD (??), 15:24 , 17-Янв-22, (156)
Не вижу в списке jfs, попавшей туда из условно живого aix либо из 20 лет как ме, Аноним (162), 03:36 , 18-Янв-22, (162)

SGI c Irix бекдоры портируют , Аноним (127), 15:02 , 15-Янв-22, (127)
А зачем читать неиспользуемые блоки Как Вы храните мегасекурную информацию, , pavlinux (ok), 17:04 , 15-Янв-22, (130)

до кучи - все это делать надо еще и на мультиюзерской системе, где реально сущес, пох. (?), 20:42 , 15-Янв-22, (144)

Кто переживает за утечку данных, у тех провод на 220В излучает магнитное поле не, pavlinux (ok), 15:50 , 17-Янв-22, (158)

А, открою страшную тайну, в неиспользуемые блоки ещё и писать можно , pavlinux (ok), 17:05 , 15-Янв-22, (131)

Шалунишка , Аноним (111), 18:36 , 15-Янв-22, (136)
В обход фс А если оно молча и не понимая ничего что-то запишет и данные потеряю, kusb (?), 10:29 , 16-Янв-22, (153)

Переведу на русскай, новые данные пишутся только в неиспользуемые блоки Исп, pavlinux (ok), 15:39 , 17-Янв-22, (157)

Расскажи поподробнее, как ты собрался переписать минимальный размер блока на за, Аноним (-), 19:53 , 17-Янв-22, (159)

В этом собственно и заключается уязвимость, что XFS такую возможность предоставл, Аноним (166), 15:23 , 26-Янв-22, (166)
Зачем тебе если такую примитивную фичу не можешь реализовать , pavlinux (ok), 03:41 , 10-Фев-22, (171)

Больше дырок - хороших и разных, Аноним12345 (?), 11:22 , 17-Янв-22, (155)
Афегеть Как спорцмены могут разбератся во всех этих штуках А тренеровке , Аноним (164), 22:28 , 18-Янв-22, (165)

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

1. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +5 +/–

Сообщение от макпыф (ok), 14-Янв-22, 18:40

> их наличие похоже на бекдор.
> 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: Ошибся, не Линус, а автор патча по удалению

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

3. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –8 +/–

Сообщение от Аноним (3), 14-Янв-22, 18:43

Да всё ядро можно устаревшим кодом назвать, столько мусора ещё никуда упихнуть не смогли. Постоянно находят уязвимости!

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

5. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (5), 14-Янв-22, 18:45

Забыть занулить выделяемый непривилегированному блок с диска - похоже скорее на диверсию, чем на легаси код и "неподумал". Даже идиот понимает, чем чревато отдавать куски памяти и блоки диска, которые могли прийти от одного приложения (SSH, например) в другое приложение. А учитывая, что вряд-ли кто-то считает, что XFS имплементили дурачки - то это именно на специально оставленную закладку и похоже

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

6. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от макпыф (ok), 14-Янв-22, 18:49

возможно и так

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

77. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 15-Янв-22, 02:00

То есть никто не понимает, зачем mkfs.xfs вызывается с ключем -K?

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

11. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (11), 14-Янв-22, 19:21

Silicon Graphics её делала для Irix.

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

20. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +7 +/–

Сообщение от Анонимленьлогиниться (?), 14-Янв-22, 20:13

Только в линукс вошла далеко не та реализация. Во-первых весь этот код с новыми ioctl был модифицирован для линукса, во-вторых было много изменений и упрощений - убран менеджер томов, убрана поддержка блоков > 4K (те создать можно, а использовать такую фс потом нет), убраны фичи типа Guaranteed-rate I/O и поддержка иерархии сторейджей и тп. Ну и если вспомнить сколько проблем было там со стэком (в оригинальном коде много вызовов функций, на SGI IRIX это было ок, а на x86 не хватало стэка и приходилось ядро собирать с поддержкой large stacks, что ломало некоторые другие вещи) и тп.

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

98. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Bx (ok), 15-Янв-22, 04:32

А XFS умел в "убран менеджер томов", очень интересно.
Ого, перечислетите тех, кто умеет в "убрана поддержка блоков > 4K"
"фичи типа Guaranteed-rate I/O" - бред
"поддержка иерархии сторейджей" - офигеть, одна фс, один путь!

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

100. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –3 +/–

Сообщение от Аноньимъ (ok), 15-Янв-22, 05:18

Интересные фичи вырезали чтобы врагам не достались.
Интересно вот ZFS угробят в конец или таки пожалеют.

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

104. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от пох. (?), 15-Янв-22, 07:21

zfs гробят сами "враги", которым она, к сожалению, досталась.
От переписывания на криволинукс, не умеющий управлять памятью (хихи, еще и стековой тоже, оказывается? Я думал, там только кучей не умеют.) до полного отсутствия в 2k22 средств восстановления - не считая единственной закрытой коммерческой программы под угадайте какую ОС.
Поздно там уже жалеть, зак@пывайте - и кол, кол осиновый тащите, "это уже не Джонни!"
Скорее уж WD (обещала) перепишет нам нормально raid6 в btrfs, или рептилоиды открыто возьмут власть и начнут нас просто есть. (В порядке возрастания вероятности событий.)

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

146. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Ващенаглухо (ok), 15-Янв-22, 21:39

Интересно, чем это ее гробят?

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

148. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноньимъ (ok), 15-Янв-22, 22:25

Хреновой реализацией и созданием проблем которые согласно бизнес модели "спонсоров" должна решать их техподдержка по подписке.

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

161. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от . (?), 17-Янв-22, 21:31

Нет. Это сказка из серии страшных и ужасных бэкдоров в xfs.
Бизнесмодель спонсоров совершенно другая - продавать фри...тру...хренасы короче.
То есть китайской сборки компьютер с воткнутыми непригодными для zfs (привет, хрюнас из wd red) и вообще любого бизнес-использования дисками по очень вкусным скидочкам (им, разумеется, а не щисливым клиентам) с интуитивно-приятным веб-интерфейсиком. (И еще чтоб докер в докере под докером, конечно.) Ну и fs у них того же качества.
Потому что покупатели - хлебушки, и сами ничего собрать и настроить не могут. А на netapp у них нет бабосов и серверрумов с нормальным охлаждением (не говоря про звукоизоляцию).
Решать проблемы ЭТА техподдержка не могет. У нее ни квалификации, ни ресурсов, ни возможностей.
Те кто хотя бы частично пытался следовать твоей бизнесмодели - уже "out of business". https://omnios.org/about/about.html
А торговцы десктопным железом под видом серверного - вполне себе процветают.

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

145. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +3 +/–

Сообщение от Анонимленьлогиниться (?), 15-Янв-22, 21:35

> А 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 первого уровня, медленными второго, жесткими дисками третьего например довольно много где встречается, и когда ФС ее умеет решать, это неплохо. А внешними средствами эффективность совсем не та выходит.

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

150. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 16-Янв-22, 02:38

LVM хорош уже тем, что в pvmove умеет. Понятия не имею, как это было(было ли) в XFS реализовано.
Ну, btrfs тоже умеет в блоки >4k, вот только монтироваться не будет на amd64/x86_64. Кстати, очень удобно то, что btrfs умеет в разные уровни четности над блочными устройствами. Правда, я предпочитаю над lvm собирать, и только дома.
Я, вероятно, несколько поторопился с ответом(сколько раз давал зарок бухим не писать :)), RT на уровне ФС - штука весьма спорная, мы же не про rtdev говорим?
Позвольте не согласиться, я лучше ФС знаю, какие данные где хранить, bcache - не панацея, но штука работающая, пусть и не всегда так, как задумывалось :) Я бы с удовольствием посмотрел на фс с tiered storage levels, вот так с ходу в голову ничего не приходит, а было бы неплохо. Наверное. На данный момент я считаю, что фс не справится с задачей распределения данных.

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

137. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (137), 15-Янв-22, 18:46

А можно поподробнее про размер стека? Почему на ириксах это к проблемам не приводило?

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

147. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Анонимленьлогиниться (?), 15-Янв-22, 21:44

> А можно поподробнее про размер стека? Почему на ириксах это к проблемам
> не приводило?
Потому что архитектура процессора другая и ядро другое. В реализации xfs много вложенных вызовов и стэк вырастал больше того, которое ядро давало по умолчанию (все ж таки линукс для десктопов, нельзя просто так взять и выдать сразу всем кучу стэка, как на серверных ОС.. я утрирую но идея понятна :) А стэк нужно выдавать сразу всем процесам, тредам и тп)
В итоге под линуксом не один год вылезали проблемы типа такой https://access.redhat.com/solutions/54544
Тк в тредах ядра для экономии памяти использовали 4К стэк. В итоге пришлось убирать экономию и на десктопах тоже брать 8К стэк, а когда пришел x86-64, экономить и вовсе перестали. Но и в 8К стэк можно упереться, как оказалось, в итоге решили что придется 16к стэк брать...

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

151. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 16-Янв-22, 02:49

Т.е. проблема не в рекурсивном спуске(предположительно), а в релизации стэка? Ну, хрен знает, не в курсе проблемы, на вскидку по ссылке проблема с кэшем инодов.

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

154. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (154), 16-Янв-22, 23:14

Спасибо за информацию, изучу. А в ириксе размер стека был больше, или параметры передавались через регистры, или что? Почему там не было проблем?

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

167. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от A.N. Onimous (?), 30-Янв-22, 02:29

Дело не в архитектуре провессора (MIPS - это примитив полнейший, i386 продвинутее был), а в том, что в лайноксе управление памятью кривое. Там под стек выделяется страница либо их пара, а сделать по-человечески коран не позволяет.

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

99. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноньимъ (ok), 15-Янв-22, 05:17

Может идиот и понимает.
Но тру Си программисты далеко не идиоты.

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

2. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –22 +/–

Сообщение от Аноним (5), 14-Янв-22, 18:41

Знал я, что XFS - зло. Никаких преимуществ поверх ext4 практически нет, зато бэкдоры - пожалуйста.

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

9. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –3 +/–

Сообщение от hohax (?), 14-Янв-22, 18:56

У ext4 вообще никаких нет.

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

15. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (15), 14-Янв-22, 19:37

Ну как же нет. Хотя бы отсутствие бэкдоров. А ещё распространённость, даже дефолтовость; лучшая чем у xfs устойчивость при отключении питания, наличие драйвера для винды, да и вообще лучше поддержка всяким разным софтом, менеджерами разделов например.

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

17. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от hohax (?), 14-Янв-22, 20:04

>  да и вообще лучше поддержка всяким разным софтом,
Ну да..

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

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

21. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (21), 14-Янв-22, 20:26

Они знали про бекдор! Это сговор!

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

89. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (15), 15-Янв-22, 02:49

Какую-то фигню написал про поддержку софтом, а на другие агрументы вообще ответа нет. Слив защитан.

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

22. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +2 +/–

Сообщение от К.О. (?), 14-Янв-22, 20:31

Никто не  спорит: у ext4 нет никаких преимуществ перед ext4.

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

35. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от penetrator (?), 14-Янв-22, 21:50

она быстрее на больших файлах, сильно быстрее, раньше использовал XFS, отказался

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

51. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Kuromi (ok), 14-Янв-22, 22:29

А главное она эти большие файлы куда быстрее чем EXT3 удаляет. Вот уж проблема была...

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

13. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +8 +/–

Сообщение от Аноним (11), 14-Янв-22, 19:23

>Никаких преимуществ поверх ext4 практически нет
По сравнению с extX, любая ФС с динамическими нодами - преимущество.

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

32. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (32), 14-Янв-22, 21:41

NTFS лучше всего

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

37. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +4 +/–

Сообщение от penetrator (?), 14-Янв-22, 21:52

неимоверно быстро фрагментируется тварь

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

52. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:33

> неимоверно быстро фрагментируется тварь
Это косяк ntfs.sys, а не файловой системы.
Diskeeper продаёт FS filter поверх NTFS, который сводит фрагментацию к минимуму. Стоит крутых бабок, но он реально работает.
// b.

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

69. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (52), 15-Янв-22, 00:28

Оно уже давно не Diskeeper, а
DymaxIO by Condusiv

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

59. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (32), 14-Янв-22, 23:01

Можно подумать, brtfs и прочие не имеют этой проблемы. В линуксе нет нормально дефрагментатора, к сожалению. Только какой-то shake-fs, но это не совсем дефрагментатор, он просто копирует каждый файл в надежде, что копия будет менее фрагментированной. Да и то, эта утилита не обновлялась уже несколько лет

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

79. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Bx (ok), 15-Янв-22, 02:09

У лялиха сильно больше 2.5 фс виндовых, поэтому дефрагментатор - задача сильно фс-специфичная. Тот же btrfs умеет в defrag, для extX тоже были, сейчас не знаю. Проблема(надуманная) в VFS, нет там возможности писать в bdev куда захочешь, надо же :)

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

168. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от A.N. Onimous (?), 30-Янв-22, 03:32

Куча ФС, и ни одной рабочей.

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

163. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от GenuZ (ok), 18-Янв-22, 16:17

e4defrag

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

62. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (62), 14-Янв-22, 23:44

Говорить про фрагментацию в эпоху SSD это прям трэш какой-то.

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

76. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (32), 15-Янв-22, 01:52

У меня 7 летний HDD, причём с пониженной скоростью, 5400 об/мин вместо стандартных 7200, так что за всех не говори

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

78. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Аноним (78), 15-Янв-22, 02:03

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

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

81. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Bx (ok), 15-Янв-22, 02:19

А зачем в обычный системник 100ТБ пихать? Обычному пользователю нужно видосики 4k хранить, зачем ему снапшоты, рефлинки, дискарды?

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

85. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (78), 15-Янв-22, 02:36

Видосики в 4к (да даже с нормальным качеством) занимают все 100 тб довольно быстро и без снапшотов. Понадобится где-то 3 месяца на плохом интернете. На типичном среднем 5-гигабитном линке что-то около 2 суток.

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

92. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Bx (ok), 15-Янв-22, 03:04

Ого, 3 месяца непрерывной записи? Мне лень считать, верю на слово.
А сколько человеко-месяцев нужно на просмотр? Дети не сильно видят разницы между 4к/720, они основные потребители стриминга. Сколько % было прочитано хотя бы 2-3 раза?

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

95. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –5 +/–

Сообщение от Аноним (78), 15-Янв-22, 03:16

Разница между 720 и 1080 очень ощутима, мыльное мыло плохо сказывается на психическом здоровье. 4к намного лучше картинку даёт. Никогда не знаешь, какой контент потребуется несколько раз. К тому же, локальный поиск намного эффективнее. Мой рекорд что-то порядка 20 часов просмотра стримов в день, 1 стрим там был 12 часов правда. Спать тоже нужно. Было весело. А если это кинофильмы? 2 часа где-то 50 гб уже.

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

96. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 15-Янв-22, 04:16

Ну, что сказать, "Мой рекорд что-то порядка 20 часов просмотра стримов в день", каким боком здесь?
Если зарабытваешь на стриминге и не умеешь в хранилку, страдай. Уверен, тебе продадут :)

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

97. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (78), 15-Янв-22, 04:27

Ну, ты спросил сколько человеко-месяцев нужно на просмотр, учитывая среднее количество потребляемого контента от 10 до 20 часов в сутки и зная битрейт, можно посчитать. Тому, кто стримит, или вообще создаёт контент, понятно нужно куда больше места для файлов.

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

112. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от 1 (??), 15-Янв-22, 11:20

можно ли назвать комп того кто стримит обычным?

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

114. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (78), 15-Янв-22, 11:54

Что-то не понимаю. Что нельзя назвать обычным на компе того, кто стримит? Плату захвата с кодировщиком и внешнюю звуковую карту? Может быть, микрофон за 100 баксов? Или айфон? Да не, вроде тоже обычное, к тому же всё довольно опционально. Железо далеко не главное, а софт уже много лет поставляется прямо с видеодрайвером и теперь с операционкой (я не проверял). Куда уж обычнее.

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

109. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от RomanCh (ok), 15-Янв-22, 11:11

> Мой рекорд что-то порядка 20 часов просмотра стримов в день, 1 стрим там был 12 часов правда
Извините, а это по работе, или это такое хобби?

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

110. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (78), 15-Янв-22, 11:13

Это по учёбе, очевидно же. Где ещё практиковать японский язык?

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

132. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от RomanCh (ok), 15-Янв-22, 17:06

> Это по учёбе, очевидно же. Где ещё практиковать японский язык?
Ну прямо вообще, очевидней некуда.
И вот 20 часов подряд, иначе никак?
Ну и если это не троллинг про хентай, то наверное можно догадаться что запрос не совсем типовой :)

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

115. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –3 +/–

Сообщение от DeerFriend (?), 15-Янв-22, 12:12

А как давно у вас 100Тб хдд стали стоить дешевле 1500 баксов?
Какой рейд при этом использовали?

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

117. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Crazy Alex (ok), 15-Янв-22, 12:46

А то, что хранят на больших дисках, как раз от фрагментации практически не страдает. Там как не пиши - у тебя многомегабайтные чанки получаются,и алгоритмы ФС с ними прекрасно умеют разбираться.

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

120. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (78), 15-Янв-22, 12:59

Достаточно иметь 1 дописываемый файл чтобы он оказался размазанным равномерным слоем по всем пластинам, какая разница, какие там чанки? Ощутимая фрагментация начнётся когда старые данные понадобится удалять. Венда так особенно мастер 1 мегабайт кэша браузера разбить на 100000 фрагментов.

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

102. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от iPony129412 (?), 15-Янв-22, 05:55

Нормально
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, и на ОЗУ даже не значит, что ты можешь хранить данные как хочешь, и это не будет влиять на производительность.

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

134. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от penetrator (?), 15-Янв-22, 18:22

> Говорить про фрагментацию в эпоху SSD это прям трэш какой-то.
а ты вообще не задумывался почему мелкоблочное чтение для SSD и последовательное отличается на несколько порядков?
но речь не о том, ты считаешь, что у HDD нет на сегодняшний день применения?
у меня есть рейд массив который хранит медиатеку и другие блобы, устоявшаяся последовательная скорость чтения/записи быстрее большинства одиночных NVMe на рынке
стоимость хранения по сравнению с SSD меньше в ПЯТЬ раз
мамкин хакер поставил себе 2 тб в ноутбук и загоняет пургу
даже если я сделаю 25x2TB SATA SSD - это будет всего 50 TB, но с космическим ценником
для кровавого энтепрайза сойдет, но для таких товарищей уже есть NVMe решения, притом со своими файловыми системами и зонированием
а для Nearline или для вместительного домашнего хранилища HDD все еще актуально

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

34. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +4 +/–

Сообщение от Аноним (34), 14-Янв-22, 21:50

Поддержка reflink в XFS — существенное преимущество, т. к. дает возможность создавать быстрые снимки (клоны) файлов и выполнять дедупликацию. Ext4 лучше только тем, что позволяет уменьшать раздел без переформатирования.

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

80. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 15-Янв-22, 02:13

Эх, молодость :) А когда reflink в xfs появился?

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

93. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (93), 15-Янв-22, 03:04

Появился в ядре 4.9, стал юзабельным по факту где-то в 4.13, объявлен стабильным в 4.16.

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

94. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Bx (ok), 15-Янв-22, 03:12

Ну, т.е. на проектах длиной чуть больше, чем "сегодня пишем, завтра продаем" не особо применимо.
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

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

103. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Аноним (103), 15-Янв-22, 06:45

"выполнять дедупликацию" неа, так как длина экстента переменная.

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

71. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от DildoZilla (?), 15-Янв-22, 00:48

JFS рулед.

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

164. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (164), 18-Янв-22, 22:10

> Никаких преимуществ поверх ext4 практически нет
А пониз? 😊

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

4. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (4), 14-Янв-22, 18:44

Просто рeшeто какое-то...
146% это было сделано чтобы оно меньше тормозило, это же нужно байтики зачищать и тратить на это такты.

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

121. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от пох. (?), 15-Янв-22, 13:27

Уровень эксперта впопеннета не позволил ему даже понять, что нет, не такты, а вполне себе реальные физические перемещения голов диска, выполняемые на два порядка дольше. (причем если нам нужны ГАРАНТИИ что враг не доберется до с-ка нужной и важной мусорной информации в произвольном секторе диска, что само по себе бред собачий - то еще и синхронные)
Да, во времена sgi это было очень дорогой операцией (могли ли эксперты подумать и было ли им чем?). А околонулевая вероятность, что в 4095м байте найдется пароль от всего пентагона, вменяемых людей вообще не беспокоила - они знали что такие файлы не удаляют просто так, а вайпают несколько раз подряд.
Сейчас времена, конечно, изменились. Разумеется, в пентагоне точно такие же девляпсы положат пароль от всего ровно так. А потом "троянец, троянец!"

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

7. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +4 +/–

Сообщение от полураспад (?), 14-Янв-22, 18:49

ну да бэкдор с 1991 года

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

8. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –3 +/–

Сообщение от hohax (?), 14-Янв-22, 18:55

> wget http://lib.ru/SHAKESPEARE/ENGL/hamlet_en.txt -O hamlet_en.txt
Как мило. Роскомнадзору только не показывайте.

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

12. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +2 +/–

Сообщение от Аноним (12), 14-Янв-22, 19:23

Наследники Шекспира в Мосгорсуде засудят?

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

18. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от hohax (?), 14-Янв-22, 20:05

Легко. Или кто-то будет сильно разбираться?

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

23. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (21), 14-Янв-22, 20:32

Обладатели 42-х хромосом засудят,когда им бананов в клетку подкинут. Правда получится как с tor.eff.org

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

116. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 15-Янв-22, 12:23

За свободное цитирование произведений, являющихся общественным достоянием, например, таких, как Конституция РФ

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

10. Скрыто модератором –25 +/–

Сообщение от Аноним (10), 14-Янв-22, 19:00

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

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

14. Скрыто модератором +1 +/–

Сообщение от Аноним (12), 14-Янв-22, 19:28

>Любая файловая система в линукс
Реализация NTFS есть в Линукс. Это не значит, что в ней нет уязвимостей.
>потому что линукс делают трое студентов за бесплатно
А Windows делают корпоративные специально обученные сотрудники. Платят ли им именно за отсутствие уязвимостей - вопрос открытый.

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

24. Скрыто модератором +1 +/–

Сообщение от Аноним (21), 14-Янв-22, 20:42

>три студента забесплатно
Винду "разрабатывают" только майки, и бог знает что они туда накодили. Линукс и кучу софта, которое адекватно работает только на нём, разрабатывают в том числе компании, указанные в Linux Foundation. А тесты производительности - это тесты конкретной реализации. Кто знает, может там тоже отключали зануление памяти, чтобы такты сохранить. Да и мои глаза мне говорят, что производительность одинаково хорошая/плохая.

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

43. Скрыто модератором +1 +/–

Сообщение от Здрасьте (?), 14-Янв-22, 22:09

"Есть в Линукс"? Вы, макаки, русский язык не знаете? "В Линуксе", а не "в Линукс".

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

129. Скрыто модератором +/–

Сообщение от pavlinux (ok), 15-Янв-22, 16:59

При отсутствии предваряющих нарицательных склонение наименований (брендов, марок,...) требуется!!!
Прафессар, опыннет, пилят.

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

28. Скрыто модератором +4 +/–

Сообщение от Аноним (28), 14-Янв-22, 21:15

> потому что линукс делают трое студентов за бесплатно
Прочитал, как будто снова в нулевые попал. Кто-то из криокамеры похоже только что вылез.

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

36. Скрыто модератором –1 +/–

Сообщение от Dzen Python (ok), 14-Янв-22, 21:51

Слишком толсто, толще даже клоуна Карманова.
Попробуй потоньше

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

39. Скрыто модератором –1 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:03

> NTFS не имеет ни одного недостатка перед линуксовыми файловыми системами, смотрите тесты
NTFS умирает при работе с сотнями тысяч мелких файлов - так что не всё так однозначно.
По части надёжности - да, ничего в Linux рядом не валялось.
// b.

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

44. Скрыто модератором +/–

Сообщение от Аноним (78), 14-Янв-22, 22:10

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

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

48. Скрыто модератором +/–

Сообщение от Kuromi (ok), 14-Янв-22, 22:26

Ну так-то сравнивать NTFS в Windows и NTFS на Линуксе некорректно, разная реализация и даже уровень экспертизы при реализации. Под Виндоус тоже можно поставить Ext2FSD и пользовать EXT2 почти как нативную ФС, вот только гарантий само собой никаких.

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

53. Скрыто модератором +1 +/–

Сообщение от Аноним (78), 14-Янв-22, 22:34

Я сравниваю с линуксовыми фс. И венда вроде на бтрфс ставится, слышал много восторженных отзывов. Всяко лучше нтфс будет.

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

63. Скрыто модератором +1 +/–

Сообщение от Kuromi (ok), 14-Янв-22, 23:47

Зачем в Линуксе использовать NTFS? Разве что для обмена данными с Виндой, но тут имхо есть варианты и получше.

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

68. Скрыто модератором +/–

Сообщение от Аноним (78), 15-Янв-22, 00:19

Только пару лет назад исправили очередной баг где нтфс в венде рассыпалась, но меня не затрагивало в этот раз потому что сжатие/шифрование/квоты это просто сразу нет, уже давно понятно.

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

105. Скрыто модератором +/–

Сообщение от Аноним (105), 15-Янв-22, 10:10

Не затруднит привести статистику по багам в месяц на нтфс и на линуховые фс? Или просто рассказы - а у них там негров линчуют? Использую в куче мест нтфс с дедуп. Проблем как не было так и нет. А екстфс несколько раз разваливалась.

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

82. Скрыто модератором –1 +/–

Сообщение от Bx (ok), 15-Янв-22, 02:28

Съели, линуксоиды?
Друк мой, общественность настаивает на деклассификации эксперимента, снимайте гриф секретности уже, мы заждались Ж) Информейншн маст би фри!!!

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

42. Скрыто модератором +2 +/–

Сообщение от Аноним (78), 14-Янв-22, 22:08

Нтфс исключительно плохо с мелкими файлами работает. Я имею в виду, еът4 с миллиардом файлов в 1 каталоге тоже не шик, но нтфс это прям дно-дно, что можно наблюдать ежедневно. Не говоря про фрагментацию.

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

83. Скрыто модератором +/–

Сообщение от Bx (ok), 15-Янв-22, 02:32

В еът4 (читаеся как еЙт4, кстати) млрд. файлов в одной директории - это вызов. Точно проверяли?

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

87. Скрыто модератором +/–

Сообщение от Аноним (78), 15-Янв-22, 02:42

Да, мне мне очень понравилась база cddb, тут больше вопросов к софту чем к ядру даже. У меня есть ещё несколько таких архивов текстовых файлов под пол терабайта и коллекция пожатых сканов на несколько терабайт.

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

88. Скрыто модератором +/–

Сообщение от Аноним (78), 15-Янв-22, 02:48

Там ещё где-то рядом архив с нотами валяется, не помню сколько терабайт, но тоже много файлов в 1 каталоге. С большими файлами намного лучше ситуация, когда 1000 файлов лежат одной кучей и занимают 10 терабайт это ничего страшного.

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

58. Скрыто модератором +/–

Сообщение от уля (?), 14-Янв-22, 22:41

настолько жырно, что нужно тереть без объяснения причин

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

16. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от псевдонимус (?), 14-Янв-22, 19:58

А оно похоже старенькое.

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

25. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Смузихлёб (?), 14-Янв-22, 20:46

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

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

29. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Kuromi (ok), 14-Янв-22, 21:17

И как же вы тогда предлагаете хранить файлы? В БД которая будет лежать на сыром блок-девайсе?

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

40. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:05

> В БД которая будет лежать на сыром блок-девайсе?
* Firebird
* Oracle
* MySQL/InnoDB
* MSSQL
* IBM DB2
Пять штук хватит?
// b.

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

45. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +3 +/–

Сообщение от Специалист (?), 14-Янв-22, 22:22

БД это же медленнее, чем файлы на ФС.

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

55. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (52), 14-Янв-22, 22:36

> БД это же медленнее, чем файлы на ФС.
Бабушка надвое сказала.
Если у вас таблица с записями строго определенного размера, то добавление новых записей в неё будет настолько быстрым насколько позволяет storage.
ФС придётся писать данные, метаданные, что-то там обновлять, проверять и прочее.
// b.

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

61. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +5 +/–

Сообщение от Аноним (61), 14-Янв-22, 23:16

> Если у вас таблица с записями строго определенного размера, то добавление новых записей в неё будет настолько быстрым насколько позволяет storage.
Лицо на фотографии должно быть квадратным, а все файлы должны быть одного размера с одинаковой длины названиями.

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

84. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Bx (ok), 15-Янв-22, 02:34

Ну, когда-то можно было фс использовать как БД.

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

122. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от пох. (?), 15-Янв-22, 13:29

> а все файлы должны быть одного размера с одинаковой длины названиями.
просто с одинаковыми названиями. Так можно сэкономить дофига байтов!

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

101. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Аноньимъ (ok), 15-Янв-22, 05:23

ФС и есть база данных.
А современные ФС вроде всяких ZFS так вот конкретно к классическим БД самое прямое отношение имеют.
Проблема всех ФС в том, что база эта идиотская.
Древовидная структура папочки и файлы, картотека пыльного офиса из 60х годов прошлого столетия.

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

30. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Kuromi (ok), 14-Янв-22, 21:18

"Исправление вошло в версию 5.16, а также в обновления ядер 5.15.14, 5.10.91, 5.4.171, 4.19.225 и т.д."
Паршивенько то, что в Убунте 21.10 ядрышко 5.13

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

33. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –3 +/–

Сообщение от Аноним (32), 14-Янв-22, 21:42

21.10 это экспериментальная с полгодом поддержки, нужно использовать только LTS

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

46. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Kuromi (ok), 14-Янв-22, 22:24

Странно, а на сайте пишут что Stable

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

38. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от макпыф (ok), 14-Янв-22, 21:53

обмажут патчами

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

31. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –6 +/–

Сообщение от Аноним (31), 14-Янв-22, 21:22

Ну да, линуксу далеко по стабильности BSD с UFS и ZFS.

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

41. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:08

XFS это ФС из Irix. ZFS из солярки. UFS - тормозное г*вно, к которому журнал привинчивали ХЗ сколько лет.
С разморозкой.
// b.

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

50. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (-), 14-Янв-22, 22:27

> UFS - тормозное г*вно,
> // b.
Ну, //b из под вендочки всяко виднее.

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

56. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:37

Шта?
$ 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.

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

73. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 15-Янв-22, 01:29

> Шта?
> $ 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 в него, ЕМНИП, никто не завозил.

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

57. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от Аноним (52), 14-Янв-22, 22:40

Comrade, я сижу под Линуксом больше лет, чем ты родился, если ты не знаешь кто я, во-вторых думаешь, что я сижу под Windows. Да, когда гамаю, запускаю Windows 10, но последний раз это было месяц с лишним назад. Увы, заниматься сексом с Линуксом (я про игры) желания нет. Под остальное - нехай.

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

60. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от another_one (ok), 14-Янв-22, 23:12

Сижу под линуксом еще дольше тебя и играю под нем без каких либо проблем через протон. Window 10 запускаю только ради лайтрума и фотошопа.

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

66. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (52), 15-Янв-22, 00:02

А хрен ли ты вмешался, когда я не с тобой говорил?
Photoshop CS2 под Wine отлично работает.
А вот терять FPS и не иметь никакого аналого NVIDIA Control Panel под Линукс желания нет (nvidia-settings - убогое говно по возможностям).

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

67. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (52), 15-Янв-22, 00:03

Кстати, насчёт дольше меня.
Что прямо раньше 1997 года сидишь?
А если не врать?

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

108. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 15-Янв-22, 10:27

Ты прям с 97-го? И на чём и как ты работал, скажем, года с 97-го под нулевые?

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

72. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 15-Янв-22, 01:20

> Comrade, я сижу под Линуксом больше лет, чем ты родился,
Ты точно сидишь под Линуксом с 1980 года?
> если ты  не знаешь кто я
Какое восхитительно раздутое ЧСВ!

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

74. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +2 +/–

Сообщение от Аноним (-), 15-Янв-22, 01:31

Это же сам Анон, ты чего ! :)

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

111. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от Аноним (111), 15-Янв-22, 11:18

Держу тор-ноду на линуксе со времен великой французской революции. Сосунки!

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

113. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от BSDhost (?), 15-Янв-22, 11:35

> UFS - тормозное г*вно
Странно. Инженеры Netflix (более 20% трафика планеты, на минутку) имеют диаметрально противоположное мнение, будучи уверенными, что UFS — единственная ФС на планете, позволяющая серверу отдавать шифрованное видео на скорости 400 Гб/с: https://people.freebsd.org/~gallatin/talks/euro2021.pdf
Но опеннетным экспертам по проперживанию диванов, разумеется, видней…

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

124. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +1 +/–

Сообщение от пох. (?), 15-Янв-22, 13:35

«Проблема цитат в интернете заключается в том, что люди безоговорочно верят в их подлинность» — сказал как-то Владимир Ленин, после чего залил на YouTube видео со штурмом Зимнего.
В документе НОЛЬ упоминаний ufs. И, полагаю, она если вообще используется "инженеграми нетфликса" - то только для загрузки операционной системы.
А что инженегры нетфликса вынуждены исполнять бредовые требования и тратить терафлопсы (я уж молчу про пропихивание вредного и ненужного кода в ядро системы) на никому ненужное ШИФРОВАНИЕ УЖЕ _drm_protected_, блжад, видео которое без гуглоплагина вообще невозможно расшифровать - ну так раб ничего не решает, просто веслает.  Они там хорошие рабы, веслают интенсивно. А что команды отдает не идиот - такого в списке требований не было.

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

138. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от BSDhost (?), 15-Янв-22, 20:03

> В документе НОЛЬ упоминаний 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.

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

142. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от пох. (?), 15-Янв-22, 20:32

Ну то есть хз для чего на самом деле.
Поскольку вообще не факт что раздающие пулы к которым имел отношение тот инженегр имеют хоть какое отношение к хранилке, а про архитектуру неизвестно ровно ничего.
Ч.т.д. - вы не в курсе и просто цитируете непонятно что вырванное из непонятного контекста, а для завязки разговора привели документ, который даже не читали, не имеющий ни малейшего отношения к делу вообще.

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

141. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от BSDhost (?), 15-Янв-22, 20:10

Ну и да, чтоб 2 раза не вставать.
Результаты нагрузочного тестирования ZFS vs UFS: https://savagedlight.me/2012/07/16/freebsd-filesystem-perfor.../

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

143. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от пох. (?), 15-Янв-22, 20:38

синтетический тест тестирующий вообще непонятно что и непонятно зачем? Ну ооок.
Причем - 2012го года, когда zfs не имела ни м-цкого ABD, ни других привнесенных линуксами проблем - правда, зато умела съесть всю память и крэшнуться, если не озаботиться заранее костыликами и подпорочками.
И да, очень странно тестировать "raidZ" vs ufs вместо geom raid + ufs на том же железе.
P.S. единственное что в этом тесте интересно - это что он подтверждает умение zfs извлекать пользу из распределения блоков по разным дискам. Что, как показал опыт md raid, не всем удается с первой попытки, и с третьей тоже. Впрочем, опять же, это совсем не та zfs.

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

125. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от anonymous (??), 15-Янв-22, 13:39

Что-то пролистал слайды, и ничего не увидел про UFS. На котором слайде там про UFS?

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

139. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –2 +/–

Сообщение от BSDhost (?), 15-Янв-22, 20:04

> Что-то пролистал слайды, и ничего не увидел про 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.

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

119. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 15-Янв-22, 12:58

> тормозное
Я тоже играю в NFS "газ в пол". Плохо, что еще рулить надо.

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

169. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от A.N. Onimous (?), 30-Янв-22, 04:16

Да, но их измордовали, чтобы запихать в лайнокс.

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

47. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 14-Янв-22, 22:26

> линуксу далеко по стабильности BSD с UFS и ZFS.
вот это вот как-раз самое слабое место bsd

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

54. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (54), 14-Янв-22, 22:36

Однако!

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

65. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Анонка (?), 15-Янв-22, 00:00

Все технологии передаваемые линуксоидам можно считать похороненными заживо, вот только несколько примеров
- Xen от Citrix закопала Linux Foundation в угоду убогому KVM который успешно похоронил Docker
- VNC угробила красношляпа в угоду своему SPICE который успешно помер так и не родившмись(Double-kill че скажешь)
- XFS угроблена редгадом из-за жопоболи по причине невозможности стырить ZFS и каличной Btrfs, отчего XFS начала мутировать в сторону ZFS
- Lustre похоронена все тем же редгадом в силу прогресирующего NIH-синдрома в виде мерзкой и тормозной GlusterFS

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

90. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Bx (ok), 15-Янв-22, 02:52

Xen - та еще хрень, впрочем, ее за бапки продают, не? KVM чем прям убог?
VNC и SPICE сравнивать, как минимум, странно. А еще они оба хуже RDP в моменте. Citrix тоже срань. Да и RDP срань.
А можно про XFS поподробнее? Там ТП уже ничего про XFS не спрашивает? А то ходили слухи, что услышав про extX отказывали в тп.
Lustre -хз, поделИтесь.

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

106. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от ryoken (ok), 15-Янв-22, 10:13

>>VNC и SPICE сравнивать, как минимум, странно. А еще они оба хуже RDP в моменте. Citrix тоже срань. Да и RDP срань.
"Всё на свете г+вно, кроме мочи"..? :D

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

123. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." –1 +/–

Сообщение от Аноним (123), 15-Янв-22, 13:32

Да здравствует nvidia облачный гейминг

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

170. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от A.N. Onimous (?), 30-Янв-22, 04:25

KVM:
1. Позволяет виртуализацию только 2-го типа (т.е., тормозную)
2. Под него нет вменяемого VMM (qemu - это совсем конченое поделие)

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

135. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (103), 15-Янв-22, 18:36

>KVM который успешно похоронил Docker
докер труп, ага, а какая связь с xfs?

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

149. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Анонка (?), 15-Янв-22, 23:55

Docker похоронил KVM, что ага? Бугага

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

156. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от PnD (??), 17-Янв-22, 15:24

"Без измен!"© Д.Гайдук (запрещённый в России писатель)
* Xen — Успешно развивается, несмотря на титанические усилия RH по выпиливанию из своих сборок. Amazon всё ещё на xen, плюс нишевые решения. У меня поверх OEL-8 dom0 едут (может как-нибудь статью напишу, но не на opennet понятно), у коллег так вообще на debian.
* VNC — просто не развивается, но то скорее по причине "семи нянек". Так-то, в последних qemu vnc спокойно собирается и работает. Глюковатый модуль для Xorg — тоже вроде на месте. А кому нужно для вяленого гнома — ну, не знаю.
* XFS — наименее глючная в _современном_ ряду экстентных ФС. По моему опыту. Правда, есть нюанс: xfs я пока наблюдаю сотни хостов, а "исторически сложившихся" ext4 — с десяток тысяч.
* Люстра — это скорее про IBM, и там говорят всё хорошо (если есть много денег). Серверная часть наглухо пропиетартая и шансы получить "на шару" как с zfs — околонулевые. Все остальные (а это скорее не Gluster а Ceph) — "хочу чтобы как люстра, но за так".

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

162. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (162), 18-Янв-22, 03:36

Не вижу в списке jfs, попавшей туда из условно живого aix (либо из 20 лет как мертвой полуоси)

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

127. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (127), 15-Янв-22, 15:02

> Поскольку ioctl(XFS_IOC_ALLOCSP) и ioctl(XFS_IOC_FREESP) по функциональности практически не отличаются от стандартного fallocate(), и единственным их отличием является утечка данных, их наличие похоже на бекдор.
SGI c Irix бекдоры портируют.

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

130. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от pavlinux (ok), 15-Янв-22, 17:04

> читать данные неиспользуемых блоков
А зачем читать неиспользуемые блоки?
Как?!! Вы храните мегасекурную информацию, top-secret-home-porno-cats.mp4 и фоточки жратвы,
но не юзаете шифрование, обнуление/рандомизацию при удалении???

Ну хотя бы 'shred -fuz top-secret-home-porno-cats.mp4'   пытались?

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

144. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от пох. (?), 15-Янв-22, 20:42

до кучи - все это делать надо еще и на мультиюзерской системе, где реально существует риск что кто-то что-то запишет в ручном режиме (а не через десять прослоек) и правда сможет что-то прочитать, принадлежавшее до этого не ему же самому.
В общем, как обычно, ужасные страшные бэкдоры существуют только в воображении местных фантастов.

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

158. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от pavlinux (ok), 17-Янв-22, 15:50

Кто переживает за утечку данных, у тех провод на 220В излучает магнитное поле не дальше 2 мм.

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

131. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от pavlinux (ok), 15-Янв-22, 17:05

А, открою страшную тайну, в  неиспользуемые блоки ещё и писать можно.

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

136. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (111), 15-Янв-22, 18:36

Шалунишка!

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

153. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от kusb (?), 16-Янв-22, 10:29

В обход фс? А если оно молча и не понимая ничего что-то запишет и данные потеряются?

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

157. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от pavlinux (ok), 17-Янв-22, 15:39

Переведу на русскай,  новые данные пишутся только в неиспользуемые блоки.  ))
Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
потом уже законно считывать и грепать там старую инфу.

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

159. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (-), 17-Янв-22, 19:53

> Переведу на русскай,  новые данные пишутся только в неиспользуемые блоки.
> ))
> Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
> потом уже законно считывать и грепать там старую инфу.
Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним байтом, без затирания последующих?

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

166. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (166), 26-Янв-22, 15:23

>Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним байтом, без затирания последующих?
В этом собственно и заключается уязвимость, что XFS такую возможность предоставляет

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

171. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от pavlinux (ok), 10-Фев-22, 03:41

>> Переведу на русскай,  новые данные пишутся только в неиспользуемые блоки.
>> ))
>> Используя эту мегафичу, ты можешь писать только 1 байт в блок размером 4096,
>> потом уже законно считывать и грепать там старую инфу.
> Расскажи поподробнее, как ты собрался переписать <минимальный размер блока на запись> одним
> байтом, без затирания последующих?
Зачем тебе если такую примитивную фичу не можешь реализовать?

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

155. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним12345 (?), 17-Янв-22, 11:22

Больше дырок - хороших и разных

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

165. "Уязвимость в XFS, позволяющая читать сырые данные  блочного ..." +/–

Сообщение от Аноним (164), 18-Янв-22, 22:28

Афегеть. Как спорцмены могут разбератся во всех этих штуках? А тренеровке?

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+5 +/–
Сообщение от макпыф (ok), 14-Янв-22, 18:40
> их наличие похоже на бекдор. > 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: Ошибся, не Линус, а автор патча по удалению
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–8 +/–
	Сообщение от Аноним (3), 14-Янв-22, 18:43
	Да всё ядро можно устаревшим кодом назвать, столько мусора ещё никуда упихнуть не смогли. Постоянно находят уязвимости!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–2 +/–
	Сообщение от Аноним (5), 14-Янв-22, 18:45
	Забыть занулить выделяемый непривилегированному блок с диска - похоже скорее на диверсию, чем на легаси код и "неподумал". Даже идиот понимает, чем чревато отдавать куски памяти и блоки диска, которые могли прийти от одного приложения (SSH, например) в другое приложение. А учитывая, что вряд-ли кто-то считает, что XFS имплементили дурачки - то это именно на специально оставленную закладку и похоже
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	6. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–1 +/–
	Сообщение от макпыф (ok), 14-Янв-22, 18:49
	возможно и так
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Bx (ok), 15-Янв-22, 02:00
	То есть никто не понимает, зачем mkfs.xfs вызывается с ключем -K?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноним (11), 14-Янв-22, 19:21
	Silicon Graphics её делала для Irix.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	20. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+7 +/–
	Сообщение от Анонимленьлогиниться (?), 14-Янв-22, 20:13
	Только в линукс вошла далеко не та реализация. Во-первых весь этот код с новыми ioctl был модифицирован для линукса, во-вторых было много изменений и упрощений - убран менеджер томов, убрана поддержка блоков > 4K (те создать можно, а использовать такую фс потом нет), убраны фичи типа Guaranteed-rate I/O и поддержка иерархии сторейджей и тп. Ну и если вспомнить сколько проблем было там со стэком (в оригинальном коде много вызовов функций, на SGI IRIX это было ок, а на x86 не хватало стэка и приходилось ядро собирать с поддержкой large stacks, что ломало некоторые другие вещи) и тп.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–2 +/–
	Сообщение от Bx (ok), 15-Янв-22, 04:32
	А XFS умел в "убран менеджер томов", очень интересно. Ого, перечислетите тех, кто умеет в "убрана поддержка блоков > 4K" "фичи типа Guaranteed-rate I/O" - бред "поддержка иерархии сторейджей" - офигеть, одна фс, один путь!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–3 +/–
	Сообщение от Аноньимъ (ok), 15-Янв-22, 05:18
	Интересные фичи вырезали чтобы врагам не достались. Интересно вот ZFS угробят в конец или таки пожалеют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+1 +/–
	Сообщение от пох. (?), 15-Янв-22, 07:21
	zfs гробят сами "враги", которым она, к сожалению, досталась. От переписывания на криволинукс, не умеющий управлять памятью (хихи, еще и стековой тоже, оказывается? Я думал, там только кучей не умеют.) до полного отсутствия в 2k22 средств восстановления - не считая единственной закрытой коммерческой программы под угадайте какую ОС. Поздно там уже жалеть, зак@пывайте - и кол, кол осиновый тащите, "это уже не Джонни!" Скорее уж WD (обещала) перепишет нам нормально raid6 в btrfs, или рептилоиды открыто возьмут власть и начнут нас просто есть. (В порядке возрастания вероятности событий.)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	146. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Ващенаглухо (ok), 15-Янв-22, 21:39
	Интересно, чем это ее гробят?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	148. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноньимъ (ok), 15-Янв-22, 22:25
	Хреновой реализацией и созданием проблем которые согласно бизнес модели "спонсоров" должна решать их техподдержка по подписке.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	161. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–1 +/–
	Сообщение от . (?), 17-Янв-22, 21:31
	Нет. Это сказка из серии страшных и ужасных бэкдоров в xfs. Бизнесмодель спонсоров совершенно другая - продавать фри...тру...хренасы короче. То есть китайской сборки компьютер с воткнутыми непригодными для zfs (привет, хрюнас из wd red) и вообще любого бизнес-использования дисками по очень вкусным скидочкам (им, разумеется, а не щисливым клиентам) с интуитивно-приятным веб-интерфейсиком. (И еще чтоб докер в докере под докером, конечно.) Ну и fs у них того же качества. Потому что покупатели - хлебушки, и сами ничего собрать и настроить не могут. А на netapp у них нет бабосов и серверрумов с нормальным охлаждением (не говоря про звукоизоляцию). Решать проблемы ЭТА техподдержка не могет. У нее ни квалификации, ни ресурсов, ни возможностей. Те кто хотя бы частично пытался следовать твоей бизнесмодели - уже "out of business". https://omnios.org/about/about.html А торговцы десктопным железом под видом серверного - вполне себе процветают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	145. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+3 +/–
	Сообщение от Анонимленьлогиниться (?), 15-Янв-22, 21:35
	> А 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 первого уровня, медленными второго, жесткими дисками третьего например довольно много где встречается, и когда ФС ее умеет решать, это неплохо. А внешними средствами эффективность совсем не та выходит.
	Ответить \| Правка \| К родителю #98 \| Наверх \| Cообщить модератору


	150. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Bx (ok), 16-Янв-22, 02:38
	LVM хорош уже тем, что в pvmove умеет. Понятия не имею, как это было(было ли) в XFS реализовано. Ну, btrfs тоже умеет в блоки >4k, вот только монтироваться не будет на amd64/x86_64. Кстати, очень удобно то, что btrfs умеет в разные уровни четности над блочными устройствами. Правда, я предпочитаю над lvm собирать, и только дома. Я, вероятно, несколько поторопился с ответом(сколько раз давал зарок бухим не писать :)), RT на уровне ФС - штука весьма спорная, мы же не про rtdev говорим? Позвольте не согласиться, я лучше ФС знаю, какие данные где хранить, bcache - не панацея, но штука работающая, пусть и не всегда так, как задумывалось :) Я бы с удовольствием посмотрел на фс с tiered storage levels, вот так с ходу в голову ничего не приходит, а было бы неплохо. Наверное. На данный момент я считаю, что фс не справится с задачей распределения данных.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	137. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноним (137), 15-Янв-22, 18:46
	А можно поподробнее про размер стека? Почему на ириксах это к проблемам не приводило?
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	147. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+1 +/–
	Сообщение от Анонимленьлогиниться (?), 15-Янв-22, 21:44
	> А можно поподробнее про размер стека? Почему на ириксах это к проблемам > не приводило? Потому что архитектура процессора другая и ядро другое. В реализации xfs много вложенных вызовов и стэк вырастал больше того, которое ядро давало по умолчанию (все ж таки линукс для десктопов, нельзя просто так взять и выдать сразу всем кучу стэка, как на серверных ОС.. я утрирую но идея понятна :) А стэк нужно выдавать сразу всем процесам, тредам и тп) В итоге под линуксом не один год вылезали проблемы типа такой https://access.redhat.com/solutions/54544 Тк в тредах ядра для экономии памяти использовали 4К стэк. В итоге пришлось убирать экономию и на десктопах тоже брать 8К стэк, а когда пришел x86-64, экономить и вовсе перестали. Но и в 8К стэк можно упереться, как оказалось, в итоге решили что придется 16к стэк брать...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	151. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Bx (ok), 16-Янв-22, 02:49
	Т.е. проблема не в рекурсивном спуске(предположительно), а в релизации стэка? Ну, хрен знает, не в курсе проблемы, на вскидку по ссылке проблема с кэшем инодов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	154. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноним (154), 16-Янв-22, 23:14
	Спасибо за информацию, изучу. А в ириксе размер стека был больше, или параметры передавались через регистры, или что? Почему там не было проблем?
	Ответить \| Правка \| К родителю #147 \| Наверх \| Cообщить модератору


	167. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от A.N. Onimous (?), 30-Янв-22, 02:29
	Дело не в архитектуре провессора (MIPS - это примитив полнейший, i386 продвинутее был), а в том, что в лайноксе управление памятью кривое. Там под стек выделяется страница либо их пара, а сделать по-человечески коран не позволяет.
	Ответить \| Правка \| К родителю #147 \| Наверх \| Cообщить модератору


	99. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–2 +/–
	Сообщение от Аноньимъ (ok), 15-Янв-22, 05:17
	Может идиот и понимает. Но тру Си программисты далеко не идиоты.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору

2. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–22 +/–
Сообщение от Аноним (5), 14-Янв-22, 18:41
Знал я, что XFS - зло. Никаких преимуществ поверх ext4 практически нет, зато бэкдоры - пожалуйста.
Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–3 +/–
	Сообщение от hohax (?), 14-Янв-22, 18:56
	У ext4 вообще никаких нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноним (15), 14-Янв-22, 19:37
	Ну как же нет. Хотя бы отсутствие бэкдоров. А ещё распространённость, даже дефолтовость; лучшая чем у xfs устойчивость при отключении питания, наличие драйвера для винды, да и вообще лучше поддержка всяким разным софтом, менеджерами разделов например.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–1 +/–
	Сообщение от hohax (?), 14-Янв-22, 20:04
	> да и вообще лучше поддержка всяким разным софтом, Ну да.. 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
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+/–
	Сообщение от Аноним (21), 14-Янв-22, 20:26
	Они знали про бекдор! Это сговор!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–1 +/–
	Сообщение от Аноним (15), 15-Янв-22, 02:49
	Какую-то фигню написал про поддержку софтом, а на другие агрументы вообще ответа нет. Слив защитан.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	22. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+2 +/–
	Сообщение от К.О. (?), 14-Янв-22, 20:31
	Никто не спорит: у ext4 нет никаких преимуществ перед ext4.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	35. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	–1 +/–
	Сообщение от penetrator (?), 14-Янв-22, 21:50
	она быстрее на больших файлах, сильно быстрее, раньше использовал XFS, отказался
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	51. "Уязвимость в XFS, позволяющая читать сырые данные блочного ..."	+1 +/–
	Сообщение от Kuromi (ok), 14-Янв-22, 22:29
	А главное она эти большие файлы куда быстрее чем EXT3 удаляет. Вот уж проблема была...
	Ответить \| Правка \| Наверх \| Cообщить модератору