forum.opennet.ru

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

Оглавление

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews (??), 26-Май-23, (0) [смотреть все]

Такое ощущение, что все эти xfs, btrfs и прочие 8211 лишь игрушки Ждём норма, Аноним (1), 23:36 , 26-Май-23, (1) –5 //

В ней-то точно багов не будет, ага, лох (?), 23:40 , 26-Май-23, (2) +9
Баг в ядре, чукча xfs наверно единственная годная из всего зоопарка помимо ext , Аноним (3), 23:42 , 26-Май-23, (3) +10 //

И в чём её годность заключается , Аноним (4), 23:48 , 26-Май-23, (4) –2 //

Она довольно надежная и производительная , Аноним (3), 00:01 , 27-Май-23, (5) +1

Довольно , да , Аноним (6), 00:05 , 27-Май-23, (6) +5

Деградирует xfs куда больше ext4 У ext4 основная проблема фрагментация свободно, Аноним (8), 00:19 , 27-Май-23, (8) –8

Из розетки часто дергал Умирающий хард-убожка Перегревающийся полуразбитый ноу, Аноним (3), 00:22 , 27-Май-23, (9) –5

Я давным давно работал в компании, где backup сервер крутился под RHEL 5 с XFS В, birdie (ok), 00:38 , 27-Май-23, (13) +6

Страшилка интересная Не иначе космическое излучение Во времена RHEL 5 xfs была, Аноним (3), 01:02 , 27-Май-23, (18) –4

интересно, стабильна потому-что стабильна, чел сверху хоть рассказал свою истори, Гиря (?), 08:18 , 27-Май-23, (48) +7

а какая может быть история, если у него, предположим, не было ни одного факапа , Аноним (184), 21:43 , 27-Май-23, (184) +1

Сосайтник, дай конкретные и объективные измеримые критерии стабильности ФС И пр, DEF (?), 11:19 , 27-Май-23, (91) –1
Особенно затирание файлов нулями Это почти мировая константа Я думал что к 2 6, Аноним (-), 01:48 , 30-Май-23, (294)

это какой год я плотно использую xfs с 2002, причём на довольно больших от еден, gleb (?), 08:09 , 27-Май-23, (45) +1

Про время и обнуление файлов на ХФС подтверждаю Но в те времена Шапка еще не до, Sergey (??), 09:22 , 27-Май-23, (56)

Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая система , Аноним (97), 11:40 , 27-Май-23, (97)

Он использовал xfs_db и другие утилиты для отладки , birdie (ok), 11:57 , 27-Май-23, (104)

2004Очень похоже на наш case , birdie (ok), 11:56 , 27-Май-23, (103)

сервер без ups , Аноним (230), 16:50 , 28-Май-23, (230) +1

А вот у вас система никогда в кору не падала Например, из-за сбоя железа, или о, Омоним (?), 20:38 , 28-Май-23, (251) +1

Души убитых процессов мстят , kilua (?), 08:33 , 27-Май-23, (49) +2
XFS не журналирует данные, только метаданные Эта ФС годна только для файлопомое, DEF (?), 11:35 , 27-Май-23, (95) +1

ext3-4 во всех режимах кроме одного тоже а с ним превращается в помойку по ско, лютый арчешкольник (?), 15:05 , 27-Май-23, (144) +3

Тут очень хорошо написано за что некоторые из нас любят BTRFS Его логика эквива, Аноним (-), 19:09 , 30-Май-23, (318) +1

У меня раздел ext4 1GB уже 9 лет живёт, я начинаю тихо охреневать от фрагментаци, Ананоним (?), 01:48 , 27-Май-23, (25)

Это не фрагментация Ext4 умеет на ходу увеличивать размер структур на диске, в , totem (?), 04:45 , 27-Май-23, (33) +1

e2fsck не решает эту проблему посредством опции optimize_extents , Виктор Федорович Полторищенко (?), 14:03 , 27-Май-23, (127)

Посмотри ls -ld в плохой директорииИ в хорошей , totem (?), 04:47 , 27-Май-23, (34)
anyfs-tools, ZloySergant (ok), 14:16 , 27-Май-23, (132) +1

mkfs ext4, Аноним (168), 19:20 , 27-Май-23, (168)

е4defrag - штатная программа Не знали Правда есть недостаток-иноды плохо дефр, maximnik0 (?), 20:43 , 27-Май-23, (178)

Подозреваю, что для больших каталогов подойдёт включение опции dir_index, Амаяк Акопян (?), 03:36 , 27-Май-23, (31)
xfs не деградирует Проблемы со скоростью доступа начинаются только на очень сил, gleb (?), 08:03 , 27-Май-23, (43)

10 от 100тб это 10тб если что, ещё можно минимум пару файлов впихнуть Сколько , Аноним (8), 10:36 , 27-Май-23, (67)
Стереть на нем торент без преаллокации никогда не видали файло на 4 7 гига с, Аноним (-), 01:40 , 29-Май-23, (262)

xfs на нескольких десятках серверов работает в данный момент, с десяток разделов, Всем Анонимам Аноним (?), 16:30 , 27-Май-23, (150)

Конечно, веселье начинается, когда паника или power outage прилетает Но, судя п, Аноним (8), 16:47 , 27-Май-23, (152)
Кстати о повреждениях ты узнаешь сильно постфактум, скорее всего, когда исправны, Аноним (8), 16:49 , 27-Май-23, (153) +1

ФС, которая молча хавает битые данные, не имея чексумм на данные и метаданные - , DEF (?), 01:46 , 27-Май-23, (24) –1

https wiki archlinux org title XFS Checksumming, Аноним (28), 02:28 , 27-Май-23, (28)

Чексуммы только на метаданные и только с убогим алгоритмом crc32 На сами данные, DEF (?), 05:11 , 27-Май-23, (35) +2

Есть, только аппаратные,самого жёсткого диска, и уже давно Сейчас уже выжали с ж, maximnik0 (?), 20:57 , 27-Май-23, (181)

Там вообще-то не чексуммы а FEC - но вот там если он не выдюжил, вариантов обычн, Аноним (-), 01:56 , 29-Май-23, (263) +1

Это как Я не беру в качестве примера ниже 5 рэйд Там же Рида-Соломона коды кор, maximnik0 (?), 07:47 , 29-Май-23, (272)

Ну вот так RAID1 читаем обе копии по одному смещению Опа, они разные И чего , Аноним (-), 01:42 , 30-Май-23, (292) +1

Вы рассматриваете устаревшие схемы раид Сейчас эффективность и надёжность поднял, maximnik0 (?), 06:36 , 30-Май-23, (305)
Устаревший - относительное понятие Если скажем всего 2 диска есть в энной систе, Аноним (-), 19:48 , 30-Май-23, (319)
Это я про книгу одного из бывших министров промышленности,он покаялся в 15 год, maximnik0 (?), 09:22 , 31-Май-23, (331)
Это слишиом экзотичный референс чтобы на него универсально ссылаться без пояснен, Аноним (-), 20:34 , 31-Май-23, (341)

Чувствуется опыт у человека, Аноним (324), 01:43 , 31-Май-23, (324)

А там и НЕ НУЖНО более извращенные алгоритмы 90 Метаданных в XFS занимают ста, maximnik0 (?), 11:26 , 31-Май-23, (335)

Чексуммы _данных_ верифицируют работу оборудования end to end И ловят множество, Аноним (-), 02:20 , 01-Июн-23, (348)

Эх,байки времен V3 5 В 3 6 это починили -единственное исключение chroot для вир, maximnik0 (?), 09:09 , 01-Июн-23, (362)

Нормальное исключение, в переводе с кодерского на человеческий мы не паримся ва, Аноним (373), 19:22 , 01-Июн-23, (373)

Эта проблема решаема на другом уровне через dm-integrity , Rootlexx (?), 11:04 , 27-Май-23, (78) +1

Это должно решаться на уровне ФС, которая для этого и предназначена - гарантиров, DEF (?), 12:07 , 27-Май-23, (107)
Проблема в том что получается сложное, стремное месиво, которое при нужде переко, Аноним (-), 02:24 , 01-Июн-23, (349)

Вы так говорите как будто бы ZFS и BTRFS были всегда, а вот дураки разработчки e, Kuromi (ok), 22:40 , 27-Май-23, (189)

Бугага Переполнения LVM раздера переводит ее в RO и нарушению митаданных, спаса, Аноним (252), 21:28 , 28-Май-23, (252)
Ее легендарную надежность с протиранием ненужных файлов нолями для безопасност, Аноним (-), 00:08 , 29-Май-23, (258)

Скажу от себя её основная годность - более эффективная поддержка гигантских дис, Виталий (??), 00:40 , 27-Май-23, (14) +1

все ext начисто сливают при конкурентной работе , gleb (?), 08:04 , 27-Май-23, (44) –1

Всех сливают Ну да На самом деле, по производительности и фичам ext4 уступает , Аноним (8), 14:08 , 27-Май-23, (130) –2

вот сейчас SGI неистово завертелась в гробу Нет, конечно же, те 600мегабайтники , пох. (?), 10:01 , 27-Май-23, (62) +3

Торент качни, хотя-бы гигов на 200, лучше на забитый диск и без преаллокации, чт, Аноним (-), 00:13 , 29-Май-23, (259)

zfs норм, Аноним (11), 00:32 , 27-Май-23, (11) +1 //

Капризная и жрущая много ресурсов для своей работы ФС На BSD иногда есть смысл , Аноним (3), 00:49 , 27-Май-23, (16) +1

В линуксе ее функциональность составляется использованием Btrfs , DEF (?), 01:42 , 27-Май-23, (23) +1

С той разницей, что я заливал командой dd 2 гигабайта на один из накопителей в Z, n00by (ok), 06:45 , 27-Май-23, (36) –2

btrfs нельзя восстанавливать через dd, если в системе есть ещё хоть одно устро, gleb (?), 07:57 , 27-Май-23, (40) +2

А где у меня написано, что я ВОССТАНАВЛИВАЛ btrfs Но намёк по поводу аршинных бу, n00by (ok), 09:07 , 27-Май-23, (54) –1

а делал ЧТО, если лил данные через dd , gleb (?), 10:45 , 27-Май-23, (69)

В каком месте Вам не понятно заливал командой dd 2 гигабайта на один из накопит, n00by (ok), 11:19 , 27-Май-23, (90) –3

Другими словами, человек _специально_ _портил_ данные на одном из элементов RAID, мшефд (?), 09:46 , 27-Май-23, (59) +2

Нуб, диски клонировать нужно через send receive, а не dd , DEF (?), 08:55 , 27-Май-23, (51) +1

Прежде чем оставлять своё особо ценное мнение, хорошо бы научиться читать Даю ещ, n00by (ok), 09:06 , 27-Май-23, (53) –3

ой, ёёёй запись произвольных данных на один из элементов raid, тем более raid0 , gleb (?), 10:50 , 27-Май-23, (70)

Да Гарантий вообще никто не даст, читайте AS IS в лицензии Потому проверять сл, n00by (ok), 11:17 , 27-Май-23, (89) –2

удивительное -- не то слово, я бы применил идиотское без обид, просто потому,, gleb (?), 12:34 , 27-Май-23, (111) +1

Пожалуй, не буду спорить Если опыт не ставить, но утверждать о неких его резуль, n00by (ok), 14:05 , 27-Май-23, (128) –1
эксперимент должен планироваться так, чтобы давать повторяемые результаты, иначе, gleb (?), 14:58 , 27-Май-23, (143)
Вы ведь не пробовали повторить, но утверждаете, что результаты не повторятся И в, n00by (ok), 16:05 , 27-Май-23, (148) –1
Делают,делают Для видиопотоков Там с жестких выжали все что можно-но и требовани, maximnik0 (?), 09:25 , 29-Май-23, (275)
После этого нубика и поперли из росы не заплатив и дав повод для многолетних рыд, Аноним (168), 19:24 , 27-Май-23, (170)
После этого работники Росы принялись анонимно клеветать, что меня откуда-то попё, n00by (ok), 08:43 , 28-Май-23, (214) –1

Читайте статью Как разработчики сидели в Петербурге и тихо ели грибы, а потом н, maximnik0 (?), 22:26 , 28-Май-23, (255)

В btrfs метаданные тоже дублируются Режим DUP назвыается , DEF (?), 11:02 , 27-Май-23, (75)

Это называется подмена предмета обсуждения и является довольно унылым приёмом , n00by (ok), 11:13 , 27-Май-23, (85) –1

Ну так не демагогствуй Свою кривую память протести на битроты и контроллеры на , DEF (?), 11:39 , 27-Май-23, (96)

Я не составлял багрепорт о том случае с BtrFS, мне не до того было Ты судишь на, n00by (ok), 14:07 , 27-Май-23, (129) –1
Ну окей, тогда я буду вместо него И скажу что поймал в btrfs пару жирных багов , Аноним (-), 02:09 , 29-Май-23, (264)
Порадуете ссылочкой на багзиллу Если захотите сослаться на боязнь деанона, расск, n00by (ok), 07:52 , 30-Май-23, (306) –1
Титул даденый мне вами тому не способствует В моих случаях не требовалось я как, Аноним (-), 20:08 , 01-Июн-23, (376)
Так мне и не надо, поскольку мне не нужна BtrFS как таковая скрипт Шишкина до с, n00by (ok), 08:59 , 02-Июн-23, (387)
Тут как бы дело хозяйское, но когда из вас не удается выжать даже точное сообщен, Аноним (-), 09:18 , 03-Июн-23, (392)
Похоже, тут один фанат автономной ОС устроил дудос жалобами, и бот всё подряд чи, n00by (ok), 17:15 , 03-Июн-23, (396)
Да, бот тут иногда жесткарит, меня правда обычно не полностью выпиливает а скоре, Аноним (-), 01:30 , 04-Июн-23, (412)
Тот персонаж, который заявлял про открутку электросчётчика цена вопроса за одно, n00by (ok), 08:04 , 04-Июн-23, (415)
меня репортнул модерам ботам наверное раз 5-10 и это даже потерли Я прикинул , Аноним (418), 02:43 , 05-Июн-23, (418)
Гипотетически здесь три модератора, а практически у Максима нет времени во всем , n00by (ok), 09:07 , 05-Июн-23, (420)
Мир не идеальный Я под его неидеальности стараюсь адаптироваться Если какое-то, Аноним (425), 00:18 , 06-Июн-23, (425)

Нельзя ли конкретнее 1 Какие были конфигурации ФС 2 Что конкретно было сделано, Аноним (-), 01:23 , 29-Май-23, (260)

Набираю в поисковике восстановление zfs пула , читаю по второй ссылке документа, n00by (ok), 08:17 , 30-Май-23, (307) –1

Я наверное непонятно выразился, пардон Мой апстрим - майнлайн, мне интересно чт, Аноним (-), 04:31 , 31-Май-23, (328)

Я поступил ровно так же, как в случае с ZFS Набрал в поисковике восстановление, n00by (ok), 15:35 , 31-Май-23, (336) –1

Я бы не назвал идею что-то делать с фс по советам из интернета от хз кого удачно, Аноним (-), 22:39 , 31-Май-23, (343)

Это как раз один из критериев, почему BtrFS непригодна для дома По ZFS имеется д, n00by (ok), 08:41 , 01-Июн-23, (361) –1
На мой вкус так я и еще эн продвинутых юзерей пользуемся этим всем - в том числе, Аноним (-), 03:24 , 02-Июн-23, (382)
Вместо денег в ходу монета с чеканкой сделай бисект , n00by (ok), 09:04 , 02-Июн-23, (388)
Вообще - вы в чем-то правы Паразитизм и потребццтво в более-менее живом и успеш, Аноним (-), 09:33 , 03-Июн-23, (393)

Спасибо, кэп Собственно zfs так и появилась С дедубликацией по сути всего 3 ФС , Аноним (11), 10:35 , 27-Май-23, (66) +2
thin lvm, потому что иначе снапшоты будут ни разу непохожие на те что у zfs А э, пох. (?), 14:44 , 27-Май-23, (138)

Сложная в освоении и память жрет побольше некоторых , Аноним (47), 08:17 , 27-Май-23, (47)

знаешь, если две команды zfs и zpool тебе сложно - я боюсь представить что тебя , пох. (?), 14:46 , 27-Май-23, (139) +2

Меня ждет btrfs , Аноним (47), 15:15 , 27-Май-23, (145) –1

если тебе даже zfs сложно оказалось осилить - она тебя не дождется , пох. (?), 16:49 , 27-Май-23, (154) –1

Чего там ждать mkfs btrfs и все Никаких zpool и прочего не нужно , Аноним (47), 18:17 , 27-Май-23, (166) +1

о ужас, набрать zpool вместо mkfs В общем, степень адекватности опеннетчиков у, пох. (?), 10:06 , 29-Май-23, (278)

Это называется когнитивная ригидность в психологии и синдром утенка у местны, n00by (ok), 08:24 , 30-Май-23, (308)

Скрыто модератором, Аноним (-), 03:26 , 02-Июн-23, (383)

Btrfs заметно проще, приятнее и дружественнее в управлении Однако чтобы с btrfs, Аноним (-), 01:28 , 29-Май-23, (261)

Покажите пальцем, в каком месте Что именно вам сложно и неприятно в банальном уп, пох. (?), 10:05 , 29-Май-23, (277)

Добавление, замена, изъятие девайсов, рестрайп на ходу, все такое Можно просто , Аноним (295), 02:12 , 30-Май-23, (295)

Скрыто модератором, Аноним (-), 01:09 , 30-Май-23, (291)

Для тех, кто не понимает суть, объясняю XFS - это файловая система, предназначен, Виталий (??), 00:49 , 27-Май-23, (17) –4 //

xfs - Файловая система, производительность которой не зависит от количества и ра, Аноним (3), 01:06 , 27-Май-23, (19) –1 //

Экспертное мнение от диванного эксперта подъехало Надо же, а Facebook, Synology, DEF (?), 01:31 , 27-Май-23, (21)

Red Hat плотно сидит на XFS, Аноним (38), 07:32 , 27-Май-23, (38) +1

А ей просто не на чем больше Разработчики остальных и блочного уровня побегли, Аноним (265), 02:28 , 29-Май-23, (265)

Советую почитать форум синолоджи, а также кучу тем а проф форумах, где люди теря, Олег (??), 13:08 , 27-Май-23, (119) +3

Лучше поотвисать в рассылках и чатах с разработчиками ФС И узнаете что такое сл, Аноним (265), 02:29 , 29-Май-23, (266)

xfs, прежде всего, надёжное хранилище, хорошо работающее при конкурентном доступ, gleb (?), 08:00 , 27-Май-23, (41) +1

А ext4 для ssd разве не подойдёт , Xo (?), 02:41 , 27-Май-23, (29) //

Подойдёт, главное настроить правильно подключение в etc fstab Я о том, что BTR, Виталий (??), 02:48 , 27-Май-23, (30)

btrfs весьма приятна, но вот по поводу ssd к сожалению, усиление записи никто , gleb (?), 08:01 , 27-Май-23, (42) +1

Амплификация в данном контексте это не усиление , правильнее переводить как , n00by (ok), 09:41 , 27-Май-23, (58)

что в лоб, что по лбу и не чрезмерная запись, а именно лавинообразное увеличение, gleb (?), 10:53 , 27-Май-23, (71)

Сила там в амперах, надо полагать , n00by (ok), 11:27 , 27-Май-23, (93)

в секторах на байт , gleb (?), 12:36 , 27-Май-23, (112)

Вообще-то в школе учат, что в случае электронных устройств сила измеряется в амп, n00by (ok), 14:14 , 27-Май-23, (131)

да неужели и да, усиление в амперах нормальные люди ну никак не измеряют хотя, gleb (?), 14:51 , 27-Май-23, (141)

Высшая школа тоже школа Но вроде закон Ома изучают и в обычной на уроках физике, n00by (ok), 15:56 , 27-Май-23, (146)
А при чем тут закон Ома Вообще-то, сила измеряется в Ньютонах А вот сила то, Аноним (28), 23:19 , 27-Май-23, (193) +1
Почитайте внимательно самое первое предложение в цитате - там и про электронные , n00by (ok), 07:52 , 28-Май-23, (210)
Тут пришел другой аноним и ему интересно 1 А как вы именно больше _тока_ вгонял, Аноним (-), 03:33 , 29-Май-23, (267)
Ну я ж написал в надежде в т ч что не потребуется объяснять про нелинейнос, n00by (ok), 08:41 , 30-Май-23, (309)
Я другой аноним имхо нежели тот кто начал этот субтред Про вах полевиков я в ку, Аноним (-), 04:40 , 31-Май-23, (329)
Опять же, все эти замечательные аббревиатеры имеют отношение к сабжу не больше, , Аноним (28), 00:07 , 20-Июн-23, (429)
Возьмите за привычку добавлять по моему мнению , а лучше сразу формулируйте я , n00by (ok), 06:26 , 20-Июн-23, (430)

ext4 с коэф записи 4 на коэф записи 1 для smr_hdd, сравниваем сbtrfs с коэф за, Аноним (57), 09:40 , 27-Май-23, (57) +2

Еще ни разу не видел чтобы у SSD закончился ресурс если это не баг конечно Оди, Аноним (11), 10:42 , 27-Май-23, (68)

У меня из двух Тошиб 2010 года одна померла, стояли в массиве Но я там гонял Ros, n00by (ok), 11:31 , 27-Май-23, (94) –1

минутку, с этого места подробнее у меня alt, причём Сизиф Там тоже rpm Время , gleb (?), 12:50 , 27-Май-23, (116)

В Альте rpm4, а не rpm5, и там такой проблемы не было и нет Если интересно, ищи, n00by (ok), 14:19 , 27-Май-23, (133)

1 Btrfs еще и развивается и оптимизируется И если что, в свежих ядрах fdatasyn, Аноним (-), 02:30 , 30-Май-23, (296)

Вот первое сообщение той темы, это писал не я на тот момент у меня была ZFS и н, n00by (ok), 14:21 , 27-Май-23, (134)

в 2020 купил пару apacer panther нв 256 Один работает до сих пор без нареканий,, gleb (?), 13:00 , 27-Май-23, (117)

А это вообще вероятностный процесс Если для вон того чипа заявлено 1000 циклов , Аноним (-), 22:46 , 31-Май-23, (345)

ну, давно уже не 26, но неприятно, конечно , gleb (?), 10:54 , 27-Май-23, (72)
Это для каких нагрузок такое соотношение, интересно На обычных десктопах и серв, Аноним (-), 03:36 , 29-Май-23, (268)

и кстати, не тормозит Только, если возможно, надо бы поставить commit побольше д, gleb (?), 13:04 , 27-Май-23, (118)
Не особо тормозит,но балансировка и дефрагментацию при домашнем применение как в, maximnik0 (?), 09:36 , 29-Май-23, (276)

На системном SSD допустим оно вообще не сдалось Ему на фрагментацию в разумных , Аноним (-), 02:35 , 30-Май-23, (297)

А почистить метаданные Не забывайте что мелкие файлы могут писаться в блок ме, maximnik0 (?), 09:38 , 31-Май-23, (332)

Смотря что иметь в виду под очисткой Обычно под них выделяется 1 или несколько , Аноним (346), 23:08 , 31-Май-23, (346)

Btrfs стабильна и надежна как скала Скоро в RHEL ее завезут, не зря же ее 2 год, DEF (?), 01:36 , 27-Май-23, (22) //

Если компьютер не включать , Аноним (3), 02:12 , 27-Май-23, (26) +2 //

Если, как в твоем случае, не включать мозг , DEF (?), 02:26 , 27-Май-23, (27) +3

Лет через 10, Аноним (38), 07:33 , 27-Май-23, (39)
In August 2017, Red Hat announced in the release notes for Red Hat Enterprise Li, Аноним (52), 09:01 , 27-Май-23, (52) +2 //

Правильно, потому что энерпрайзу негоже забавляться с сырой косячной ФСА вот обк, Аноним (73), 10:57 , 27-Май-23, (73)
Все давно решено - Btrfs скоро будет в RHEL В XFS коровы и чексуммы на данные т, DEF (?), 11:15 , 27-Май-23, (87)

Не будет её в RHEL Она была в technical preview и не прошла его Вопрос закрыт , Аноним (187), 22:14 , 27-Май-23, (187)

Закрытых вопросов в ИТ не бывает , DEF (?), 00:03 , 28-Май-23, (195)

Ну, может быть Когда её снова в превью поместят - вот тогда и порассуждаем не т, Аноним (187), 17:44 , 28-Май-23, (238)

Учитывая что IBM стоял у ее истоков, и IBM пожрал RH - и к тому же btrfs и отбаг, Аноним (-), 03:42 , 29-Май-23, (269)

у Меня тут выключали свет ежедневно Половину года Дак вот btrfs - при пропад, Аноним (60), 09:57 , 27-Май-23, (60) //

В таком эксперименте важно, что в момент отказа происходит Когда читаете Опенне, n00by (ok), 11:06 , 27-Май-23, (79)

Я более 1000 раз делал хард-ресет при интенсивной записи в БД - ФС и данные ни р, DEF (?), 12:18 , 27-Май-23, (108)

А я изучал метрологию и понимаю, что эта цифра придумана только что Ты напрасно , n00by (ok), 14:30 , 27-Май-23, (135)

Т е в возможность создания автотеста файлух вы принципиально не верите, или что, Аноним (-), 03:53 , 29-Май-23, (270)

Я уверен, что DEF ничего не считал, и тесты не проводил Иначе он бы и написал , n00by (ok), 08:46 , 30-Май-23, (310)

А я немного отличаю этот ник от ноля и по накопленному опыту он вроде в ФС и око, Аноним (-), 05:02 , 31-Май-23, (330)

Потому что он где-то что-то прочёл и эту инфу разносит Инфа необязательно невер, n00by (ok), 15:48 , 31-Май-23, (337)

Мне почему-то кажется что он для себя этим пользуется, иначе врядли бы знал неко, Аноним (-), 02:50 , 01-Июн-23, (350)

Не работают только parity-raid ы, а mirror-raid ы - работают , DEF (?), 11:17 , 27-Май-23, (88)

Более того, поскольку там у метаданных и данных могут быть разные схемы хранения, Аноним (-), 03:38 , 30-Май-23, (304)

Живу на btrfs, все работает отлично Что я делаю не так , Отражение луны (ok), 10:34 , 27-Май-23, (65) //

Сидел на btrfs, все покорраптилось Постоянно проблемы у разных компаний и людей, Да (?), 11:43 , 27-Май-23, (99) //

Насколько давно это было , Отражение луны (ok), 11:45 , 27-Май-23, (101)

Я бы спросил - с какими ядрами Использовать какой-нибудь 2 6 32 можно и в 2023 , Аноним (-), 03:55 , 29-Май-23, (271)

Ничего, что XFS не новомодная игрушка, а достаточно пожилая файловая система при, Getfor (?), 11:25 , 27-Май-23, (92) //

Критерии стабильности в студию , DEF (?), 12:38 , 27-Май-23, (113) //

крэшится очень стабильно - с 2009го года наблюдаю Но это на bare metal На вирт, пох. (?), 14:48 , 27-Май-23, (140) +2

riser5 же, ну , Аноним (149), 16:30 , 27-Май-23, (149) //

Если только самому собирать kernel и добовлять пач чтобы работал riser5, а это в, Аноним (425), 20:23 , 27-Май-23, (176)
кстати пусть разработчик 5 версии подарит нашему невте газ прому файловую систем, Аноним (425), 20:53 , 27-Май-23, (179) –1 //

или ещё кому, зелёный есть , Аноним (425), 20:55 , 27-Май-23, (180)
или продать наверно уже бы продал еслибы был спрос , Аноним (425), 20:57 , 27-Май-23, (182)
Как бы у нефтегазпрома и так имущества больше, чем у разработчика-энтузиаста, кт, n00by (ok), 08:13 , 28-Май-23, (211)

или продать наверно уже бы продал если бы был спрос Я это всё писал в основно, Аноним (-), 17:54 , 29-Май-23, (288)

Про продать появилось только в третьем сообщении Дело тут не в спросе Нефтег, n00by (ok), 08:55 , 30-Май-23, (311)

Проще тогда напишу свой посыл или точнее Смысл моих слов в том, чтобы отдать фа, Аноним (352), 05:51 , 01-Июн-23, (352)

И отдать или продать тому у кого есть желание или заинтересованность и ресурс эт, Аноним (352), 05:55 , 01-Июн-23, (353)
Эдуард Шишкин и хочет, и развивает свою ФС, когда находит на то время И даже в , n00by (ok), 08:36 , 01-Июн-23, (360)

Сам собери Kernel с патчем для работы Reser5 вариант не устраивающий многих, так, Аноним (378), 20:43 , 01-Июн-23, (378)
Когда он на btrfs плевался - его общий decision making зарекомендовал себя сильн, Аноним (-), 03:37 , 02-Июн-23, (384)

ФС и не должна быть большим проектом Программисты на баш и мастера копипасты та, n00by (ok), 09:08 , 02-Июн-23, (389)

Теоретически, да все мы хотим маленький, шустрый, стабильный, фичастый дизайн к, Аноним (-), 18:57 , 03-Июн-23, (397)

Ext2 и jfs я не шучу , Аноним (425), 20:18 , 27-Май-23, (174) //

на всякий случай jfs2, а так их две версии jfs1 и jfs2 jfs2 обозначают как jfs , Аноним (425), 20:39 , 27-Май-23, (177) +1
Не точно написано Надо так Ext2 и jfs Я не шучу , Аноним (-), 00:10 , 30-Май-23, (290)
Рассматривать ещё надо как исправляется файловая система Как я вижу для jfs пос, Аноним (-), 19:33 , 01-Июн-23, (374) //

Я имел ввиду качество проверки , Аноним (-), 19:37 , 01-Июн-23, (375)

Пользуюсь btrfs как основной для корня уже около 4х лет, работает без проблем М, Андрей (??), 14:18 , 28-Май-23, (227) //

Но, может быть так видимых проблем нет, а проверяя на ошибки раздел диска прове, Аноним (-), 18:27 , 29-Май-23, (289) //

В этом случае нехило бы указать как минимум сообщение об ошибке При том желател, Аноним (-), 20:24 , 31-Май-23, (340)

Было показано и найдено такой вид поведения в интернете С компьютером порядок , Аноним (352), 06:10 , 01-Июн-23, (354)

визуализация виртуализация, Аноним (352), 06:11 , 01-Июн-23, (355)
Варианты Поискать, что с этим делать - ответа не нашёл Тогда или оставить как , Аноним (346), 06:29 , 01-Июн-23, (356)

Или званого установить файловую систему - то есть формат и установка операционно, Аноним (346), 06:30 , 01-Июн-23, (357)

Снимай копию с раздела это если не виртуальный диск, а так скорее всего достаточ, Аноним (359), 07:05 , 01-Июн-23, (359)

Лучше man btrfs-send на тему --no-data, так оно очень сильно меньше будет, а для, Аноним (-), 03:41 , 02-Июн-23, (385)

Не спрашивайте, что было написано Не помню Запомнил еслибы к этому серьёзднее , Аноним (-), 06:43 , 01-Июн-23, (358)

Ошибка в багзилле шляпы Возможно, напатчили лишнего эти шляпники, Аноним (7), 00:05 , 27-Май-23, (7) +3 //

Количество собственных патчей в Fedora сведено к абсолютному минимуму за последн, birdie (ok), 00:28 , 27-Май-23, (10) +1 //

Сведено, но далеко не нулевое, патчей много все равно И не факт, что проблема н, Аноним (7), 00:32 , 27-Май-23, (12) +2 //

Я не понял при чём тут ярлыки Навешивал их тот, кто обвинял априори Fedora в , birdie (ok), 00:42 , 27-Май-23, (15) –1

Главное, при цитировании вырезать возможно , тогда цитата будет действительно п, n00by (ok), 06:52 , 27-Май-23, (37) +2
Расследование закончилось - ошибка в самом ядре, патч уже есть Патчи Fedora, как, birdie (ok), 12:57 , 28-Май-23, (224) –1

Ошибка в самам ядре самостоятельно материализовалась Или, может быть, ее туда, Аноним (244), 18:26 , 28-Май-23, (244)
Смотри, кто автор бажного патча https git kernel org pub scm linux kernel git , Аноним (244), 18:39 , 28-Май-23, (247)

RedHat - один из основных разрабов ядра, systemd, glibc, gnome, gtk и wayland Чт, birdie (ok), 19:23 , 28-Май-23, (249)

в том и дело подгадили не только себе, но и всем вообще , Аноним (244), 22:16 , 28-Май-23, (253) +1

Только анонимы в рунете могут даже предположить, что сотрудники redhat гадят Я н, Аноним (256), 22:51 , 28-Май-23, (256) –1

Не имеет значения, где именно разместили бажный патч, не протестировав как следу, Аноним (244), 22:26 , 28-Май-23, (254)

Аноним заявил, что1 Ядро в Федоре жутко патченное - ложь, фиксов там минимум, б, Аноним (256), 11:01 , 29-Май-23, (281)

А вот известные разработчики блочного уровня и ФС оттуда почему-то слиняли Так,, Аноним (-), 02:41 , 30-Май-23, (299)

потому что редхату не нужны их разработки, а нужна работающая xfs Кто не соглас, пох. (?), 17:28 , 01-Июн-23, (370)

Хуже от этого как видим становится в основном редхату и их кастомерам, которым т, Аноним (-), 19:26 , 03-Июн-23, (398)

От места размещения бажного патча результат не меняется Кто автор изменений, ко, Аноним (7), 08:31 , 28-Май-23, (212)

Если верить Phoronix у, то проблема с xfs наблюдается и на Debian при использова, dalco (ok), 04:05 , 27-Май-23, (32) //

Виноваты авторы тех изменений в ядре, что привели к этой ситуации И это, вероят, Аноним (7), 08:38 , 28-Май-23, (213) //

Потому что ты не умеешь кодить Приходится делать это кому-то другому , пох. (?), 18:01 , 28-Май-23, (242)

К чему это тут Если сам не умеешь, не думай, что остальные такие же , Аноним (244), 18:27 , 28-Май-23, (246)

xfs зло,файлы с недокаченого торрента исчезали когда пользовался ей в позапрошло, Аноним (47), 08:13 , 27-Май-23, (46) –3 //

Btrfs этот то единственное чтоне дает мне поставить RHEL на комп У меня на ней , Аноним (60), 10:01 , 27-Май-23, (61) //

Ну так сам собери, keydon (ok), 10:20 , 27-Май-23, (63)
Ставь Федору - там btrfs по-умолчанию Через пару лет и в RHEL станет также, как, DEF (?), 11:12 , 27-Май-23, (84) +3 //

Шапка от BTRFS отказалась и вовсю патчит XFS наверняка баги оттуда же , уже даж, Kuromi (ok), 23:10 , 27-Май-23, (192)

Если попробовать сратис и btrfs device add remove ну ты понял , Аноним (-), 02:42 , 30-Май-23, (300)
Никакого COW в XFS не добавлено и не добавят Поддержка коров требует поломку об, DEF (?), 21:28 , 30-Май-23, (320) –2

Разве там уже не чуть ли пятая версия формата данных на диске , Kuromi (ok), 22:40 , 30-Май-23, (323) +3

И чо Где обещанные коровы и чексуммы Их нет и не будет Даже если и будут, то , DEF (?), 11:29 , 02-Июн-23, (390)

а оно надо на высокопроизводительной фс завезли reflink, пока хватит, наверное , gleb (?), 12:40 , 02-Июн-23, (391)

Как мне кажется вон тот Кент им ща покажет что можно и коров научить бегать быст, Аноним (-), 19:30 , 03-Июн-23, (399)

OEL UEK поставь, там ффсё есть , Tron is Whistling (?), 22:31 , 27-Май-23, (188)

исчезали -- это как что конкретно происходило держать файлы типа торрентов на b, gleb (?), 11:02 , 27-Май-23, (76) //

Если например xmonad закрыть по shift alt q во время скачивания торрента,то несм, Аноним (47), 17:43 , 27-Май-23, (161) //

Комп вроде потом тоже выключал В общем с торрентами так было несколько раз и я , Аноним (47), 17:50 , 27-Май-23, (162) –1
не воспроизводится 4 9 384 14 555 4 915 10 665 15 87, gleb (?), 19:42 , 27-Май-23, (171) –1

Ядро точно 4 9 было я его долго юзал Когда дропнули поддержку тогда только пер, Аноним (47), 20:08 , 27-Май-23, (172) –1

RT патчи , Аноним (47), 20:21 , 27-Май-23, (175)
ну вот я проверил на 5и разных ядрах проблемы не вижу , gleb (?), 06:57 , 28-Май-23, (208)

Рад за ваш успех,мне так не повезло Теперь считаю xfs какашкой btrfs норм Есл, Аноним (47), 09:23 , 28-Май-23, (215)

Дело в том, что ни Ваше, ни моё мнение, по большому счёту, ничего не решает и ни, gleb (?), 09:31 , 28-Май-23, (217) –1

На убогую ext мне вообще плевать Я пробовал их все и имею свое мнение о них М, Аноним (47), 09:53 , 28-Май-23, (218) +1

А разве файлы, скачанные с торрентов часто и быстро меняются Допустим файлы кач, Аноним (239), 17:47 , 28-Май-23, (239) //

они пишутся в произвольные места, обычно, разряжённого файла на btrfs каждое из, gleb (?), 14:50 , 29-Май-23, (286)

А если преаллоцировать место или скачивать последовательно, это решит проблему , Аноним (239), 02:40 , 30-Май-23, (298)

достаточно отключить cow для этих файлов и или папок но производительность всё р, gleb (?), 08:59 , 30-Май-23, (312)
и да, торрент-качалки обычно и так заранее выделеяют место, создавая разрежённый, gleb (?), 09:02 , 30-Май-23, (313)

XFS как раньше затирал файлы, так и сейчас продолжает, стабильность ага Вот дум, Аноним (50), 08:38 , 27-Май-23, (50) –2 //

можно продемонстрировать повторюсь, у меня с 2002 г активно юзается в 4 разных , gleb (?), 10:57 , 27-Май-23, (74) //

Попробуйте его с ceph ом поиспользовать да, я знаю что официально не рекомендуе, Аноним (324), 01:47 , 31-Май-23, (325) //

так проблема-то, чья , gleb (?), 16:56 , 31-Май-23, (339)

fs, разумеется - ceph в этом режиме работает как обычная user space программа П, пох. (?), 17:32 , 01-Июн-23, (371)

вообще-то, для ceph именно xfs считается нормальной фс так что вопрос остаётся , gleb (?), 20:43 , 01-Июн-23, (377)

для ceph нормальной fs является raw partition, на котором формат хранения менялс, пох. (?), 21:42 , 01-Июн-23, (380)

я спорить не буду, но нагугливаемая документация так не считает ох, сей мёд бы, gleb (?), 05:23 , 02-Июн-23, (386)

И какие же там проблемы , DEF (?), 11:43 , 27-Май-23, (100)

Не знаю что там про надёжность и стабильность xfs и работу с большими объёмами Н, Аноним (55), 09:07 , 27-Май-23, (55) +3 //

в фарш все разделы и потом постепенно нарастающие ошибки а тут точно xfs винова, gleb (?), 11:04 , 27-Май-23, (77) //

После этого переразвернул сервер на ext4 8 лет, до сих пор работает Весь регион , Аноним (183), 21:12 , 27-Май-23, (183) //

Это разные анонимы пишут И да, 8 лет назад proxmox backup server не было , Аноним (203), 01:50 , 28-Май-23, (203)

В данном случае речь шла про Oracle Linux 7 1 И речь там больше про то что после, Аноним (183), 11:35 , 28-Май-23, (220)

не очевидно, что это не аргумент надо разбираться и тестировать в противном слу, gleb (?), 06:55 , 28-Май-23, (207)

Вот прямо сейчас ядро 6 3 3 превращает в фарш разделы с xfs Это факт За ext4 так, Аноним (183), 11:40 , 28-Май-23, (221) –1

тобой - незамечено, потому что ты старательно смотришь в другую сторону Гуглить , пох. (?), 17:34 , 01-Июн-23, (372)

Да, ПЦ - стабилен Особенно с версиями кернелов в сабже Но зачем тебе ПЦ Неужт, Аноним (-), 01:41 , 04-Июн-23, (413)

XFS не журналит данные, только метаданные Поэтому ее лучше юзать для файлопомое, DEF (?), 11:41 , 27-Май-23, (98) //

Эта протухшая пропатченная дрянь и есть бэкпорты всего нового с современных к, thhh (?), 20:18 , 27-Май-23, (173) //

По какой-то неведомой причине эти бэкпорты глючные и менее стабильные, чем свежи, DEF (?), 00:06 , 28-Май-23, (198)

На 4 19 прекрасно себя чухает Нет проблем,проста и надежна , Аноним (47), 09:26 , 28-Май-23, (216)

Законы Мерфи гласят что если вам кажется что дела идут хорошо, вы просто не зам, Аноним (-), 01:02 , 04-Июн-23, (409)

Прочитал обсуждение Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо П, beck (??), 10:31 , 27-Май-23, (64) +6 //

Да, EXT4 стабильнее всех работает, а те кто про неё пишут гадости, подсосы бутер, Аноним (73), 11:06 , 27-Май-23, (80) +4 //

Сосайтник, бутерфс от оракла , DEF (?), 11:09 , 27-Май-23, (82) //

Ой извините подсосы бутерфс от оракцле , Аноним (109), 12:30 , 27-Май-23, (109)

Вот это рили дерьмо Конечно есть - Btrfs , DEF (?), 11:08 , 27-Май-23, (81) –1 //

Подтверждаю - рекаверил убиты в хлам нтфсы юзерам у которых все прекрасно работа, Аноним (-), 01:04 , 04-Июн-23, (410)

На zfs не каждый местный эксперт сможет установить систему, так что это их экспе, n00by (ok), 11:10 , 27-Май-23, (83) +3
Сейчас придут и расскажут и почему NTFS тоже дерьмо А IMHO - вся беда в том, , Читатель сайта (?), 11:15 , 27-Май-23, (86) +1
Используется на более чем 2х миллиардов Android телефонах и сотнях тысяч серв, birdie (ok), 11:52 , 27-Май-23, (102) //

И чо У одного только Фейсбука, btrfs юзается в хвост и в гриву на более миллион, DEF (?), 11:58 , 27-Май-23, (105) –2 //

Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum Проблема, birdie (ok), 12:39 , 27-Май-23, (114)

Это не решения, а днищенские костыли Гарантия целостности данных должна обеспеч, DEF (?), 13:45 , 27-Май-23, (124) +2

Кто это решил Я использую файлы с checksums более 20 лет Проблем не было Кроме, birdie (ok), 13:58 , 27-Май-23, (126)

копий данных на современных fs может быть, внезапно, не одна И даже носителей т, пох. (?), 00:20 , 28-Май-23, (201) +2

И какой копии доверять Как доказать целостность Где гарантии, что копии целые , Sw00p aka Jerom (?), 10:34 , 28-Май-23, (219) –3

Тебе ж написали контрольные суммы , Прохожий (??), 11:01 , 29-Май-23, (280)

а где храним эти контрольные суммы и в каком количестве , Sw00p aka Jerom (?), 11:36 , 29-Май-23, (282)

Ну вот в файлухе например можно, если это не блочный а файловый дизайн был В , Аноним (400), 19:38 , 03-Июн-23, (400)

откуда знаем как понять чек-сумма битая или блок данных разве не на том же уст, Sw00p aka Jerom (?), 21:26 , 03-Июн-23, (404)
ИМХО пофиг если не совпадает - проблемная копия, просто берем из другой И как, Аноним (411), 01:15 , 04-Июн-23, (411)

Это решили логика и здравый смысл Никого не интересует твой опыт использования , DEF (?), 00:52 , 28-Май-23, (202) –1

ля, стыдно всё это читать Если у вас есть RAID, куча копий данных, да на кой хр, birdie (ok), 12:56 , 28-Май-23, (223) –2

Начните уже думать, а не только троллить RAID защищает немножко от другого Куча, dasd (?), 17:34 , 28-Май-23, (237)
Мда С тобой все ясно Таблетки не забывай принимать вовремя, которые тебе назна, DEF (?), 17:10 , 30-Май-23, (317)
А откуда мы знаем которая из копий на райде правильная когда на отличия налетели, Аноним (-), 19:53 , 03-Июн-23, (401)

мне китайский переходник SATA-USB наделал в ссд кучу Uncorrectable ошибок и даже, onanim (?), 08:45 , 04-Июн-23, (417)

Именно поэтому Гугль потихоньку переводит Андроид на f2fs для RW хотя тут неточ, Kuromi (ok), 23:07 , 27-Май-23, (191) +1
Математика не нужна Миллионы школьников не могут ошибаться , Аноним (324), 01:59 , 31-Май-23, (327)

При форматировании флешки или внешнего HDD в NTFS проблемы с потерями данных я в, ptr (??), 12:06 , 27-Май-23, (106) //

NTFS игрушечная ФС , Аноним (109), 12:33 , 27-Май-23, (110) //

NTFS просто старенькая и глючная, слишком много напихали поэтому регулярно наход, Аноним (8), 21:53 , 27-Май-23, (185)

Практически всё в этом ответе - наглая ложь, и непонимание работы куча мелких , birdie (ok), 13:01 , 28-Май-23, (225)

Хорошо, давай вместо твоего пустословия я приведу самый надёжный способ её уничт, Аноним (8), 13:28 , 28-Май-23, (226)

VirtualBox поставить и записать видео - делов на полчаса Увы, не верю ни слову,, birdie (ok), 16:57 , 28-Май-23, (232)

Ну нет, тебе надо, ты и экперементируй Лет 5 назад в очередной раз пофиксили Е, Аноним (8), 17:22 , 28-Май-23, (235)

gt оверквотинг удален Вы сделали громкое заявление о кривизне NTFS The burden, birdie (ok), 17:57 , 28-Май-23, (241)

ну почему-же Если хозяин балуется монтажом видео, например, то наилучший Да и , gleb (?), 12:44 , 27-Май-23, (115) //

В этом случае различия между xfs и ext4 он просто не заметит Зачем они тому же P, ptr (??), 13:09 , 27-Май-23, (120)

проверено -- заметит особенно, если паралелльно сборки проекта не ждать и плева, gleb (?), 13:19 , 27-Май-23, (121)

Понял Мы с разных планет На моей, остановка БД - чрезвычайное событие, гранича, ptr (??), 13:29 , 27-Май-23, (122)

это тоже понятно но когда остановка -- снэпшот -- перезапуск посгресса занимает, gleb (?), 13:33 , 27-Май-23, (123)

А если юзер ждет завершения обучения модели, которое длится уже часов 30 На мое, ptr (??), 13:49 , 27-Май-23, (125)

Просто у тебя реальный мир, а у него мир смузихлёбов с докером в проде, где пара, Аноним (8), 14:39 , 27-Май-23, (136) +1
никак и тем не менее, технология имеет право на жизнь в своих граничных услови, gleb (?), 14:44 , 27-Май-23, (137)

Если хозяин балуется монтажем видео ему надо в сторону SSD смотреть, может даже , Kuromi (ok), 23:04 , 27-Май-23, (190) +1

спасибо, кэп но вот у мне, например, в голову не придёт покупать ссд большого об, gleb (?), 06:50 , 28-Май-23, (206)

Ну на самом деле обычно всякие топовые NVME с 3-7 гигабайта в секунду записи , Kuromi (ok), 17:06 , 28-Май-23, (234)

У f2fs была проблема с GRUB Если создать ФС с опцией -O extra_attr, загрузчик н, n00by (ok), 09:05 , 30-Май-23, (314)

Есть такая проблема, да , Kuromi (ok), 15:48 , 30-Май-23, (315)
Такие проблемы бывают с много чем С btrfs или zfs на это тоже можно нарваться , Аноним (-), 20:15 , 03-Июн-23, (402)

Ну я пользуюсь, просто работает, брат жив Но обратите внимание, нюанс ntfs-3gЕс, пох. (?), 14:52 , 27-Май-23, (142)
Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных Да так чт, Аноним (-), 02:46 , 30-Май-23, (301) //

gt оверквотинг удален NTFS конечно ФС старая и на сегодняшний день не предлага, Kuromi (ok), 16:42 , 30-Май-23, (316) //

Экстенты Откуда HTFS взяться экстентам,будь они там она не была такой тормоз, maximnik0 (?), 22:26 , 31-Май-23, (342) –1

Чтож, закапываться в спеки лень, но условная Википедия да простят меня боги ув, Kuromi (ok), 22:41 , 31-Май-23, (344)

В журнале Системный администратор приводилась статья по устройству ntfs, достато, maximnik0 (?), 23:21 , 31-Май-23, (347)

У них вроде изначально свободное место битмапом аллокации маркировалось и потом , Аноним (414), 01:49 , 04-Июн-23, (414)

Ну и получается объединенная группа кластеров - это не экстент В лучшем случае э, maximnik0 (?), 22:20 , 05-Июн-23, (424)

Зато инструментов для вытаскивания данных до хрена и больше,а если еще и образ б, maximnik0 (?), 10:27 , 31-Май-23, (333)

Нтфс говорите Это которая гибнет после каждого третьего выключения света Где П, Аноним (324), 01:55 , 31-Май-23, (326) –1 //

Сейчас с 64 мгб кэша на жестких любая фс при резком выключение может сказать -да, maximnik0 (?), 10:50 , 31-Май-23, (334) +1 //

Вообще-то нет Там есть команды для предсказуемой работы с кешированием и информ, Аноним (-), 20:30 , 03-Июн-23, (403)

То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать 1,5 , maximnik0 (?), 22:02 , 05-Июн-23, (423)

Да, вы знаете, фирмвары у девайсов бывают забагованые и кривые Но это баг и нар, Аноним (-), 00:42 , 06-Июн-23, (426)

Не знаю как в 10,не пробывал,а в старых версиях офтопика в настройках управления, maximnik0 (?), 13:45 , 06-Июн-23, (428)

Вы путаете ФС и ОС В NTFS это разные директории В NTFS даже 0 байт значения 0, n00by (ok), 16:02 , 31-Май-23, (338) //

Зато удачи там создать файл с именем С CON , как минимум через WinAPI А в лин, Аноним (373), 00:01 , 04-Июн-23, (405)

Вы новость вообще читали Chris Caudle 2023-05-19 14 00 28 UTCUpdated to kernel 6, Аноним (147), 16:02 , 27-Май-23, (147) //

А вы Человек загрузился в 6 3 3 и у него все прахом пошло И дальше у пачки други, Аноним (256), 21:55 , 27-Май-23, (186)

о, я смотрю тут специалисты по XFS сидят подскажите, что вот это за фигня http, onanim (?), 16:41 , 27-Май-23, (151) +1 //

а ну и в dmesg никаких ошибок, в SMART у хардов всё шикарно, никаких внезапных о, onanim (?), 16:49 , 27-Май-23, (155) //

а это на экране что по-твоему В логах - естественно никаких ошибок, ты ж их сло, пох. (?), 16:56 , 27-Май-23, (157) +1 //

Ты ведь на самом деле хотел сказать вернуть ext4 и убрать xfs , Аноним (109), 17:17 , 27-Май-23, (159) +1

вот я к этому же решению и склоняюсь за 15 лет прыщеводства ни разу не сталкив, onanim (?), 18:05 , 27-Май-23, (163)

э ну короче, у меня для тебя плохие новости - тебе просто везло Или может, пох. (?), 00:03 , 28-Май-23, (196)
я бы склонялся к гипотезе, что проблема где-то ближе к железу Просто на ext не, gleb (?), 06:44 , 28-Май-23, (205)

слабоумие и отвага или слабоумие и слабоумие , пох. (?), 16:53 , 27-Май-23, (156) –1 //

я понимаю, что у вас в кровавом ынтырпрайзе на хранилища объёмом менее чем 1 пет, onanim (?), 18:09 , 27-Май-23, (165) //

Наоборот, у нас полка не позволяет создать один том больше 18 терабайт Вообще , пох. (?), 00:00 , 28-Май-23, (194)

Фэйсбук с базой сносившей когда-то крышу btrfs где-то на примерно 20-м терабайте, Аноним (346), 00:07 , 04-Июн-23, (406)

Я не раб фейсбука, и мне совершенно наплевать что они там у себя нах евертили , пох. (?), 11:47 , 05-Июн-23, (422)

Проблема не в сервере и не ос, а в том что у тебя поисковый кретинизм, легко ищу, Аноним (109), 17:16 , 27-Май-23, (158) //

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., onanim (?), 18:07 , 27-Май-23, (164)
ипать, иксперт опеннета - нашел таки гуглем - тадам - исходник с этой строчкой З, пох. (?), 00:05 , 28-Май-23, (197) +1

насколько я понимаю, это переполнение при транзакции и ненормльно надо бы в тех, gleb (?), 17:27 , 27-Май-23, (160) //

это правда был несчастный случай - Случай, когда человеку в спину попадает стр, пох. (?), 00:07 , 28-Май-23, (199) +1 //

а кто спорит Конечно, ненормально Но ниже Вы сами сказали о большом нечто Сл, gleb (?), 06:40 , 28-Май-23, (204)
и да, про техподдержку не очень смешно как минимум, они должны убедитьтся, что , gleb (?), 07:05 , 28-Май-23, (209)

Это ж каким кретином нужно быть, чтобы на CentOS 7 воткнуть неродное для CentOS , Анннннно (?), 19:42 , 28-Май-23, (250) //

а кто тогда ты, если не знаешь про свежие ядра в родных репозиториях ред хата , onanim (?), 12:49 , 29-Май-23, (283) –1 //

Ссылку на официальное ядро 6 2 8 от RedHat для CentOS-7 , или ты п абол , Анннннно (?), 22:18 , 30-Май-23, (322)

Все эти исправления больше похожи на танцы с бубном Терминам похоже , вроде б, Аноним (167), 18:40 , 27-Май-23, (167) //

Линукс это давно уже сборник шаманских практик а не инженерия Никто не знает точ, пох. (?), 00:12 , 28-Май-23, (200) +4 //

Баг закрыли, потому что туда посыпался спам - я не про комментарии, я про обычны, birdie (ok), 12:49 , 28-Май-23, (222) +1 //

ну полно сказочки-то рассказывать Баг не просто закрыли, страницу багзилы сдела, пох. (?), 17:25 , 28-Май-23, (236)

1 Bugzilla открыта для new bug reports - you re welcome2 Reproducible test cas, birdie (ok), 17:55 , 28-Май-23, (240)

в момент появления бага их было полно Не было желания Не у нас, сам понимаешь , пох. (?), 18:22 , 28-Май-23, (243) +2

gt оверквотинг удален Ждём-с , birdie (ok), 19:18 , 28-Май-23, (248)

Пох такой себе фанат опенсорса, который назло бабушке уши отмораживает и винду р, Аноним (-), 02:52 , 30-Май-23, (302)

12309 у меня до сих пор бывает при копировании крупных файлов, на NVMe диске, хо, onanim (?), 16:50 , 28-Май-23, (231) //

Версия ядра Вывод free Вывод vmstat 1 5 , birdie (ok), 17:01 , 28-Май-23, (233)

gt оверквотинг удален разные дистрибутивы, разные относительно свежие LTS ядра, onanim (?), 12:51 , 29-Май-23, (284) +1

А ядра то надеюсь десктопные, low latency Т е как минимум preempt_dynamic p, Аноним (-), 02:56 , 30-Май-23, (303)

Сколько раз пробовал ставить лоу латенси ядра - никакого эффекта нигде не ощутил, Неуклюжий танцор (?), 21:02 , 01-Июн-23, (379)

Это в основном под нагрузкой ощущается Под тяжелым IO и тому подобным Если вы , Аноним (373), 00:20 , 04-Июн-23, (407)

сервер, перестающий обрабатывать запросы потому что очень занят сбросом буферов , пох. (?), 21:51 , 01-Июн-23, (381)

Да как тебе сказать Если сервак протупит 500 мс с запросом по HTTP ты можешь ос, Аноним (414), 00:28 , 04-Июн-23, (408)

увы, у меня не финтех переводящий ресурсы в ненужные криптозакорючки, с бесконеч, пох. (?), 11:32 , 05-Июн-23, (421)

И все же если ты мониторил когданить под нагрузкой это добро то знаешь что есть , Аноним (-), 00:58 , 06-Июн-23, (427)

https www opennet ru openforum vsluhforumID3 130607 html 322Ссылку на официал, Анннннно (?), 15:29 , 03-Июн-23, (395) –1

Я в домашней лабе Центоси уже обновился, так что отчаиваться поздно Все бэкапны, Kirikekeks (ok), 08:01 , 29-Май-23, (273)
Предложен патч, исправляющий проблему- args- fsbno ap- blkno args- alignmen, Анонус (?), 16:05 , 29-Май-23, (287) +1
Сегодня подленько так прилетело обновление ядра в Федорку - 6 3 4, DEF (?), 10:05 , 01-Июн-23, (363)

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

4. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –2 +/–

Сообщение от Аноним (4), 26-Май-23, 23:48

И в чём её годность заключается?

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

5. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (3), 27-Май-23, 00:01

Она довольно надежная и производительная.

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

6. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +5 +/–

Сообщение от Аноним (6), 27-Май-23, 00:05

"Довольно", да.

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

8. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –8 +/–

Сообщение от Аноним (8), 27-Май-23, 00:19

Деградирует xfs куда больше ext4. У ext4 основная проблема фрагментация свободного пространства которая эээ может быть весьма значительной. Ну и время доступа к большим каталогам какое-то не здоровое (фрагментация опять же), но это вроде у всех. У меня xfs только и делала, что портила файлы всю свою историю, пока пытался использовать, поэтому теперь только оправданные эксперименты. Вроде f2fs, но её тоже бездумно пихать нельзя и слишком уж много ограничений.

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

9. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –5 +/–

Сообщение от Аноним (3), 27-Май-23, 00:22

Из розетки часто дергал? Умирающий хард-убожка? Перегревающийся полуразбитый ноут?

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

13. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +6 +/–

Сообщение от birdie (ok), 27-Май-23, 00:38

Я давным давно работал в компании, где backup сервер крутился под RHEL 5 с XFS.
В один день, придя на работу, мы не досчитались 200GB backup'ов, которые тупо исчезли.
Я дал доступ по SSH с root одному из разрабов - он больше часа ковырялся и ... ничего не нашёл. Каталог с десятками файлов по несколько гигабайт просто исчез. Следов удалённых файлов не было в метаданных, как будто исчез (или обнулился) целый блок инод. Ах, да, и место освободилось. Ошибок XFS в dmesg не было.
Нет, это не было взломом или insider work - почему я это знаю, потому что modification time и какие-то метаданные (размер? не помню уже) у головной директории был таким, какими они должны были бы быть, если бы подкаталоги не были удалены, если бы они вообще никогда не существовали. Это вручную было сделать невозможно (кроме как dd if=/dev/zero of=/dev/partition_with_xfs) - так сказал разработчик.
После этого мы переехали на ext3, потом ext4 и не имели ни одной проблемы.
Ситуация с тех пор улучшилась, XFS стала default FS для RHEL7, но осадок остался.

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

18. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –4 +/–

Сообщение от Аноним (3), 27-Май-23, 01:02

Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно.

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

48. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +7 +/–

Сообщение от Гиря (?), 27-Май-23, 08:18

>Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно.
интересно, стабильна потому-что стабильна, чел сверху хоть рассказал свою историю успеха, а у вас какое-то словоблудие.

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

184. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (184), 27-Май-23, 21:43

а какая может быть история, если у него, предположим, не было ни одного факапа? Типа, " - Cлушайте мой случай: За 20 лет использования ничего не потеряли" - так, что ли? Случившаяся "история успеха" - это когда что-то произошло. Это отдаленно напоминает ситуацию с хорошим и плохим админом - окружающие всегда видят как с ж.пой в мыле работает плохой админ (" - Молодец, трудяга, не зря зарплату получает - вон, постоянно что-то ремонтирует то тут то там! Пообедать некогда.") и совсем не знают что такого делает хороший админ (" - Дармоед! Ведь всё и так работает и не ломается. Даже не знаю в каком кабинете он сидит и что там делает, но зарплату, нахлебник, получает!". Т.е. твой собеседник не может тебе ничего рассказать "за работу хорошего админа", если у него всё работало, работает и ни разу не возникали проблемы.

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

91. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –1 +/–

Сообщение от DEF (?), 27-Май-23, 11:19

Сосайтник, дай конкретные и объективные измеримые критерии стабильности ФС. И пруфани, что XFS - стабильная ФС.

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

294. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 30-Май-23, 01:48

> Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была
> вполне стабильной. На уровне ext3 уж точно.
Особенно затирание файлов нулями. Это почти мировая константа. Я думал что к 2.6.28 это, наконец, починили. Примерно 10 лет спустя от момента как проблема заявила о себе. Но нет, потом еще дочинивали ЭТО дополнительно. Представляете?! Мушкетеры, i++ лет спустя.

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

45. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от gleb (?), 27-Май-23, 08:09

это какой год?
я плотно использую xfs с 2002, причём на довольно больших (от едениц Тб в 2002 по десятки Тб в настоящее время).
В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов при внезапном пропадании питания).
Других потерь занных не было никогда.
Я бы всё-таки пошукал-бы, не было ли в этой ситуации человеческого фактора. Или отказа/сбоя, если метаданные хранились на другом устройстве.

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

56. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Sergey (??), 27-Май-23, 09:22

Про время и обнуление файлов на ХФС подтверждаю. Но в те времена Шапка еще не допилиа ХФС и не рекомендовала ее юзать.
Что касается того рассказа, я после слов : дал доступ по SSH разрабу, читать перестал.
Они откуда знают как работает ФС и что это такое. Они даже маке толком осилить не могут.

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

97. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (97), 27-Май-23, 11:40

Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая система;))(

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

104. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от birdie (ok), 27-Май-23, 11:57

> Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая
> система;))(
Он использовал xfs_db и другие утилиты для отладки.

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

103. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от birdie (ok), 27-Май-23, 11:56

> это какой год?
~ 2004
> В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов
> при внезапном пропадании питания).
Очень похоже на наш case.

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

230. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (230), 28-Май-23, 16:50

сервер без ups?

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

251. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Омоним (?), 28-Май-23, 20:38

А вот у вас система никогда в кору не падала? Например, из-за сбоя железа, или ошибки в драйвере?  меня вот бывало. И знаете, UPS при этом не помогает совершенно никак.

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

49. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +2 +/–

Сообщение от kilua (?), 27-Май-23, 08:33

Души убитых процессов мстят...

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

95. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от DEF (?), 27-Май-23, 11:35

XFS не журналирует данные, только метаданные. Эта ФС годна только для файлопомоек, которые не жалко обнулить.

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

144. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +3 +/–

Сообщение от лютый арчешкольник (?), 27-Май-23, 15:05

>Эта ФС годна только для файлопомоек, которые не жалко обнулить.
ext3-4 во всех режимах кроме одного тоже ) а с ним превращается в помойку по скорости

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

318. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (-), 30-Май-23, 19:09

>>Эта ФС годна только для файлопомоек, которые не жалко обнулить.
> ext3-4 во всех режимах кроме одного тоже ) а с ним превращается
> в помойку по скорости
Тут очень хорошо написано за что некоторые из нас любят BTRFS. Его логика эквивалентна полному журналированию - но без вот этого вот пеналти по скорости работы. Это одно из ключевых достоинств технологий на основе COW. За это воздается странноватыми свойствами, но вот этот вот момент оно обыгрывает безупречно. На самом деле идея простая: если всю площадь ФС сделать подобием журнала, записывать дважды уже не придется.

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

25. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Ананоним (?), 27-Май-23, 01:48

У меня раздел ext4 1GB уже 9 лет живёт, я начинаю тихо охреневать от фрагментации. Нужна программа дефрагментации. Некоторые директории открываются 30 секунд.

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

33. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от totem (?), 27-Май-23, 04:45

Это не фрагментация.
"Ext4 умеет на ходу увеличивать размер структур на диске, в которых хранится список файлов и директорий в ней, но не умеет уменьшать. Поэтому если создать в директории много файлов, а потом удалить, она останется большой. При доступе к такой директории приходится читать эти фрагменты, которые ещё и оказываются разбросаны по диску там и сям. Это медленно."
Создай новую директорию и перенеси файлы туда. При этом блоки данных этих файлов на диске останутся на своих местах.

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

127. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Виктор Федорович Полторищенко (?), 27-Май-23, 14:03

e2fsck не решает эту проблему посредством опции optimize_extents?

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

34. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от totem (?), 27-Май-23, 04:47

Посмотри ls -ld . в "плохой" директории
И в хорошей.

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

132. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от ZloySergant (ok), 27-Май-23, 14:16

>Нужна программа дефрагментации.
anyfs-tools

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

168. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (168), 27-Май-23, 19:20

mkfs.ext4

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

178. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 27-Май-23, 20:43

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

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

31. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Амаяк Акопян (?), 27-Май-23, 03:36

Подозреваю, что для больших каталогов подойдёт включение опции dir_index

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

43. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от gleb (?), 27-Май-23, 08:03

xfs не деградирует. Проблемы со скоростью доступа начинаются только на очень сильно забитых больших разделах. Если осталось процентов 10 свободного места, тогда да, торимоза станут вполне заметны.

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

67. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (8), 27-Май-23, 10:36

10% от 100тб это 10тб если что, ещё можно минимум пару файлов впихнуть. Сколько миллиардов файлов считается "очень сильно забитым" и почему ext4 норм, лишь бы не в 1 каталоге? Да и тогда вполне предсказуемо.

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

262. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 29-Май-23, 01:40

> xfs не деградирует. Проблемы со скоростью доступа начинаются только на очень сильно
> забитых больших разделах. Если осталось процентов 10 свободного места, тогда да,
> торимоза станут вполне заметны.
Стереть на нем торент без преаллокации... никогда не видали файло на 4.7 гига (стандартный DVD) стираемый 2 минуты? Тот неловкий момент когда удалять файлы чуть ли не дольше чем скачивать :)

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

150. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Всем Анонимам Аноним (?), 27-Май-23, 16:30

xfs на нескольких десятках серверов работает в данный момент, с десяток разделов на каждом с постоянными изменениями. все работает таким образом уже не знаю сколько лет на Ubuntu, больше 8 точно.

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

152. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (8), 27-Май-23, 16:47

Конечно, веселье начинается, когда паника или power outage прилетает. Но, судя по успехам xfs, достаточно и перезагрузки. Десятки серверов иногда всё же необходимо перезагружать для обновления, хотя бы раз в сезон, то что они у тебя больше 32 сезонов отпахали без обновлений тоже ничего хорошего (железо столько не живёт кстати)

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

153. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (8), 27-Май-23, 16:49

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

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

24. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –1 +/–

Сообщение от DEF (?), 27-Май-23, 01:46

ФС, которая молча хавает битые данные, не имея чексумм на данные и метаданные - не может быть надежной.Btrfs, ZFS - надежные ФС. XFS, ext4 - нет.

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

28. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (28), 27-Май-23, 02:28

https://wiki.archlinux.org/title/XFS#Checksumming

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

35. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +2 +/–

Сообщение от DEF (?), 27-Май-23, 05:11

Чексуммы только на метаданные и только с убогим алгоритмом crc32. На сами данные никаких чексум нет, что у ext4, что у XFS.

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

181. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 27-Май-23, 20:57

>На сами данные никаких чексум нет, что у ext4, что у XFS.
Есть, только аппаратные,самого жёсткого диска, и уже давно.Сейчас уже выжали с жёстких все что можно,особенно с учётом черепичной записи.Это страшно,но уже используется алгоритмы по зашумленному сигналу предсказывающие вероятно идеальный сигнал.Есть поэтому у некоторых производителей серверные жёсткие с усиленной контрольной суммой,там до 3 байт ошибок на 4 мгб ченить могут на аппаратном уровне.

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

263. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (-), 29-Май-23, 01:56

> Есть, только аппаратные,самого жёсткого диска, и уже давно.
Там вообще-то не чексуммы а FEC - но вот там если он не выдюжил, вариантов обычно два. Оно либо отдаст наверх IO error - UNC, либо отдаст сектор "как вышло" после FEC. В зависимости от дури фирмвари железки.
Со стороны ФС и райдов проблема в том что они в результате зачастую не знают какая копия верная. Штуки типа btrfs получают очевидный плюс: на какой копии данных чексум сошелся, та и правильная. Обычный RAID вообще может вытворять что угодно если вместо полной кончины девайсы стали допустим битые данные выгружать. Дальнейшее unspecified - и если чексум данных не было вы можете довольно долго не замечать это, пока в ФС что-то не развалится фатальным образом.
Как показал опыт с btrfs - пойти не так может совершенно все.
- Может глючить RAM и в конечном итоге это тоже проблема.
- Может глючить CPU и это тоже ведет к проблемам.
- Может глючить чипсет или контроллер RAID и их фирмвар (где применимо).
- Может быть глючный провод от диска до контроллера (SATA/SAS/etc).
- Фирмвари девайсов могут вытворять все что угодно и даже больше.
Иногда это превосходит самые дикие допущения ФСов. Скажем потерять большой регион в 16-64 мега при внезапном слете питания? Всего лишь SSD кантовал RMW/GC а тут питание слетело или сглючила фирмварь. Некоторые конфигурации типа Btrfs @ RAID1 даже имеют шансы. А вот просто RAID1 совсем не готов что 2 копии будт, как живые, только - уже вот несимметричные, и догадайтесь какая из 2 верная.
А как об этом всем узнать? А вот запустить файлуху с чексуммами в эксплуатацию. И сразу столько открытий чудных, на тему глючного железа, которое как живое, но раз в час/день/месяц/год пару битиков загаживает.
> Сейчас уже выжали с жёстких все что можно,особенно с учётом черепичной записи.
Zoned в btrfs приветы передавал. Правда это для host-managed актуально.
> производителей серверные жёсткие с усиленной контрольной суммой,там до 3 байт ошибок
> на 4 мгб ченить могут на аппаратном уровне.
У почти всех заметно более мощный FEC. Типа эн байтов на каждые 4096 сектор. Собственно с 512 на 4096 перешли чтобы улучшить соотношение data/FEC. Но наружу это если и лезет то только как UNC или как мусор вместо данных если фирмварь решила вместо UNC отдать "уж что вышло". Это однако совсем не аналог чексум ФС, потому что end-to-end проверки корректности работы железа не получается и вооон то можно прошляпить.
А с btrfs вон там глючный чипсет заметили, тут глючный шнурок, там глючная RAM, а там и вообще проц кривой был, а там девайс не сообщал UNC но отдавал труху. Коллекция глюкастиков основательно пополнилась. Хорошо когда чексуммы данных есть.

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

272. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 29-Май-23, 07:47

>Со стороны ФС и райдов проблема в том что они в результате зачастую не знают какая копия верная.
Это как ? Я не беру в качестве примера ниже 5 рэйд.Там же Рида-Соломона коды корректировки,если код не совпадает значит диск дегрейд...Так уже есть рэйды где 3 диска может развалиться и данные не потеряться.

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

292. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Аноним (-), 30-Май-23, 01:42

>> не знают какая копия верная.
> Это как ? Я не беру в качестве примера ниже 5 рэйд.
Ну вот так. RAID1: читаем обе копии по одному смещению. Опа, они разные! И чего теперь? Мы знаем что в этом месте проблема, но понятия не имеем какая из копий правильная. В случае чексум данных все упрощается: если есть копия с неверной и копия с верной чексумой, ок, вычислили гонщика. Так можно определить проблемный накопитель/контроллер/канал/провод...
> Там же Рида-Соломона коды корректировки,
В именно RAID 5 так то всего лишь XOR. Если взять 3 девайса, и 2 блока, b1 и b2, это пишется как b1, b2, b1^b2 (XOR b1 с b2). XOR интересен тем что при вылете b1 или b2 он восстанавливается всего лишь XOR второго блока с parity. Это просто, быстро, оверхед 1/3 при 3 девайсах, меньше если девайсов больше, но - переживает только отказ 1 девайса. Если нужно больше, это уже RAID6 и вот там дополнительный parity уже будет рид соломоном. Это позволяет починить вылет и 2 устройств за раз.
> если код не совпадает значит диск дегрейд...
Для RAID5 это не сработает: мы видим что b1 ^ b2 != parity но понятия не имеем который из них неверен. Для RAID6 это уже можно попробовать. Но это ценой 2 полноразмерных блоков четности. Т.е. минимум 4 стоража, при этом оверхед 50%. Как RAID1 только тормознее и хуже. В случае например btrfs на RAID1 (и даже DUP на 1 стораже) видит какая из копий неверная и фиксит из правильной. Для большего числа дисков RAID6 может уже иметь смысл а RAID5 становится опаснее т.к. за время ребилда не должен скончаться ни 1 стораж.
У btrfs там кстати плюс есть: знает что аллоцировано а что нет. И на полупустом пуле оно ребилдить будет сильно меньше - только реально занятые блоки, сколько уж их там на проблемном девайсе было. В зависимости от - так ребилд может быть сильно резвее.
Это же касается изъятия/замены девайсов, scrub, смены схемы хранения, уменьшения ФС и т.п.. Это и есть смысл терпеть те неудобства. Безгеморное управление, можно решения переиграть, они не высечены в камне. Не нравится тот уровень RAID - конвертим в другой, лишь бы места в новом фоормате хватало для фактически записанных данных. Можно даже "мягкую" конверсию: старые блоки останутся как есть, а новые с новой схемой. Вполне валидно для той механики. А на обычном RAID такие вещи лучше даже не пытаться... как угодно но это next gen технологий хранения.
> Так уже есть рэйды где 3 диска может развалиться и данные не потеряться.
Ну да. Triple parity raid. Правда, взамен придется хранить ТРИ набора блоков parity и это не менее чем 5 девайсов, иначе бессмысленно. В принципе соотношение DATA/FEC ничем таким не ограничено, даже в RAID1 если сделать 10 копий блока то до 9 можно потерять. Проблема только в том что эффективность схемы == 1/10. Нужно ли оно такое? Врядли. Потому что не спасает от сбоев проца, рам и проч например, все 10 могут оказаться испорченными и оверхед того не стоил.

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

305. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 30-Май-23, 06:36

Вы рассматриваете устаревшие схемы раид.Сейчас эффективность и надёжность подняли, в качестве примера
читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных". Там для коррекции сбоя в отдельной области применили страйпы,т.е очень быстрая локализация ошибок. Вообще очень передовая разработка была- работает система при развале 3!!! дисков из 7 в массиве. Очень показательно что разработку этой компании в наглячку стали обходить-всплыли заявки на патенты за полгода (как в Японии в 80 х), появились в других странах аналогичные !! патенты и т.д.

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

319. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 30-Май-23, 19:48

> Вы рассматриваете устаревшие схемы раид.
Устаревший - относительное понятие. Если скажем всего 2 диска есть в энной системе, то чего кроме RAID 1 там будет такой уж смысл иметь? И чем это будет лучше? Особенно если с чексумами, так что мы видим на какой из 2 копий был сбой и можно осмысленно фиксить сбои. Чексуммы не так много места занимают зато улучшают свойства схемы хранения. А в случае btrfs можно еще и при душняке с местом просто добавить, просто +1 девайс. Любой. Какой был. И будет 3-девайсовый RAID1.
> Сейчас эффективность и надёжность подняли,
Кто, где, КАК ЭТО ПОЮЗАТЬ НА МОИХ СИСТЕМАХ? Сферические сказки про супербатарейки "где-то там" уже несколько надоели, извините. Я вот хочу нормальные технологии у себя на компах, ноуте, одноплатниках и проч. А не "где-то там".
> в качестве примера читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели
> грибы, а потом написали ОС для систем хранения данных".
Проблема в том что поедатели грибоа - где-то там. И операционкой у меня Linux везде. А RAID может быть не центром вселенной а 1 из фич, повышающей надеженость, до кучи. Just because I can. В этом случае меня парит чтобы менеджмент был ненапряжный, дурацких требований и допушений - минимум, а чексуммы, вот, еще и диагностируемость повышают, хайлайтя при случае проблемный хардвар. В ряде случаев это early warning вообще, когда я конечно играю в рулетку, но в режиме когда теорвер уже за меня а не против меня. В мире хлипкого железа где народ хочет емко, быстро и за копейки - это сильный аргумент. Потому что расплатой за это является текучесть, сыпучесть, глюкавость, минимальные margins, ... и по другому это можно и не заметить. А потом пожалеть когда данные - в хлам.
> Там для коррекции сбоя в отдельной области применили страйпы,т.е очень быстрая
> локализация ошибок.
Ох да, мне в btrfs примерно то же самое тоже очень нравится. Разок как-то на ноуте бэд вылез, да еще под метаданными. Очень приятно при этом "csum error, corrected" получить а не разлет системы в хлам. Только вот этот хайтек - у меня на ноуте. В повседневной работе. А не у каких-то мужиков из питера с кастомной операционкой где-то там. И вот что б вы мне имели предложить лучше? Ваш EXT4 который от такого под метаданными рассыпался бы вдрызг и я бы ос переставлял? Ну спасибо, только это - не хайтек и не апгрейд. Ну да, там 1 диск и DUP как схема. И - вот - конкретный пример почему оно так. Без всяких хабр.
> Вообще очень передовая разработка была- работает система при развале 3!!! дисков
> из 7 в массиве.
И чего? Почитайте теорию - и поймете что в принципе FEC может исправлять любой процент ошибок. Вопрос в объеме оверхеда на хранение FEC и вычислений. Ну и осмысленности полученной схемы для тех или иных задач. А что если у меня дисков всего 2-3? Там очевидно тот номер не пройдет. Более того - а у этих мужиков можно как в btrfs, просто подоткнуть 8-й диск, если 7 стало мало? И чтоб без жесткого рестрайпа всей штуки вотпрямща?
> Очень показательно что разработку этой компании в наглячку стали обходить-всплыли
> заявки на патенты за полгода (как в Японии в 80 х),
Японские патенты 80х должны бы уже истечь. На патенты обычно 25 лет срок.
> появились в других странах аналогичные !! патенты и т.д.
Большая часть патентов на технологии FEC либо истекла либо будет вышиблена prior art при ближайшем рассмотрении. И вы все это рассказываете тому кто умеет строить схемы избыточности под любые нужды. Но мы же про линуха и то что в майнлайне.
В свое время там летали забавные патчи - весьма забавный, если не ошибаюсь, ридсоломон с конфигуряемым объемом избыточности и соответственно соотношением емкости. Но столько счастья видимо народу не требовалось и тема заглохла. А вон те разговоры в пользу бедных... мне они зачем? И как это все поможет актуальные мне конфиги улучшить по свойствам? Никак? Ну тогда "let it float by itself, f...g piece of iron".

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

331. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 31-Май-23, 09:22

>Японские патенты 80х должны бы уже истечь. На патенты обычно 25 лет срок.
Это я про  книгу одного из бывших  министров промышленности,он покаялся в 15 году.Он писал как химичили и тырили технологии где возможно.И было дано указание патентному бюро  тоже мошенничать- на интересную патентную заявку специально задними числами оформляли приоритет заявку на японскую фирму.
Потом  Американцам это дело надоело- и поймали специально неправильно описанными  патентами на воровстве,ВТО не хило Японию оштрафовало.....и куча японских фирм.

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

341. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 31-Май-23, 20:34

> Это я про  книгу одного из бывших  министров промышленности,он покаялся в 15 году.
Это слишиом экзотичный референс чтобы на него универсально ссылаться без пояснений.
> Он писал как химичили и тырили технологии где возможно.
Да вообще так все делают. Вопрос в легальном статусе. Скажем, переизобретать лампочку накаливания каждому в своей норке независимо было бы довольно неэффективно по ресурсам. С другой стороны и совсем уж фига изобретателю как-то неправильно. В этом смысле патенты несколько адекватнее копирайта, там еще и платить за продление надо - на память о чем есть такая чудная штука как Google Patents. Кроме всего прочего это кладезь годных идей, на половину из которых их авторы все же забили, не осилив коммерциализировать. Но это ж не значит что про них надо просто забыть? Expiry патента по причине "не оплачено" прозрачно намекает :)
> И было дано указание патентному бюро  тоже мошенничать- на интересную патентную
> заявку специально задними числами оформляли приоритет заявку на японскую фирму.
А интерес в этом какой? Да и патенты обычно сразу в эн юрисдикциях хреначат на что-то реально стоящее. Первым делом в штатах, у них рынок большой и денег много.
> Потом  Американцам это дело надоело- и поймали специально неправильно описанными
> патентами на воровстве,ВТО не хило Японию оштрафовало.....и куча японских фирм.
Заднее число имеет свойство вылезать - когда кто-то все же приперся в суд и/или нашел prior art. И если в россии объективный арбитраж штука спорная, то в большей части более-менее цивилизованных стран это чревато как минимум сливом судебного процесса с треском и неслабыми выплатами. Правда, даже в штатовских патентах - их оформляют совсем не гении и типовой клерк может сдуру выписать патент на что-то весьма общее и неконкретное. Правда, в суде это все же быстренько сливается.

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

324. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (324), 31-Май-23, 01:43

Чувствуется опыт у человека

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

335. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 31-Май-23, 11:26

> Чексуммы только на метаданные и только с убогим алгоритмом crc32. На сами
> данные никаких чексум нет, что у ext4, что у XFS.
А там и НЕ НУЖНО более извращенные алгоритмы.90% Метаданных  в  XFS занимают стандартный блок 64 кб и изобретать велосипед не надо,хватает перекрестной проверки  с веретификацией Log SequenceNumber.

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

348. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 01-Июн-23, 02:20

Чексуммы _данных_ верифицируют работу оборудования end to end. И ловят множество факапов которое вон то "should never happen" просто не заметит. А потом всякие кадры рассказывают страшилки про плохие файлухи рассыпающиеся "сами по себе". На поверку сейчас большая часть таких репортов оказывается связана с глюками железа выходящими далеко за допущения типовых файлух. Единственное известное исключение это рейзер где убиение тома fsck - "known issue" :)

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

362. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от maximnik0 (?), 01-Июн-23, 09:09

>Единственное известное исключение это рейзер где убиение тома fsck - "known issue" :)
Эх,байки времен V3.5 .В 3.6 это починили -единственное исключение chroot для виртуальных томов (виртуальные машины) ,там да,обнаружив по сигнатурам знакомые файлы fsck сносило голову. Мелкие ошибки fsck нормально ремонтировало,сколько reset я пережил не счесть.Но забросили эту фс :-( ,т.к ext4 более предсказуема вела,а вариант с очень мелкими файлами в гиганских кол-вах редко распрастранен.

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

373. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (373), 01-Июн-23, 19:22

> Эх,байки времен V3.5 .В 3.6 это починили -единственное исключение chroot для виртуальных
> томов (виртуальные машины)
Нормальное исключение, в переводе с кодерского на человеческий "мы не паримся валидацией найденого и втрамбовываем первое похожее на фс в вашу файлуху, так кодить проще!". Проверить что-то типа UUID - не судьба?
В современном мире это опасный факап. У лично меня образов других систем с тем же типом рутфс у есть. И если дев говорит что мой кейс ведет к разлету, чинить не бум, known issue, оок! Зачем мне такие технологии?
К тому же ядерные апи не мировая константа. С тех пор появились io_uring, folios (группы страниц, чтобы не колупать по 1 странице) и все такое. По причине появления сверхскоростного IO (что сеть, что сторажи) и нужды урезать оверхед по линии ядра соответственно. Более менее живые на это дело отрефакторились. Полутрупики на то и полутрупики и вечно держать для них легаси апи никто не будет. Выкинут вместе с дохляком.
> там да,обнаружив по сигнатурам знакомые файлы fsck сносило
> голову. Мелкие ошибки fsck нормально ремонтировало,сколько reset я пережил не счесть.
А у меня оно с высокой вероятностью вынесло бы ФС, по причине наличия файлов с rootfs, я системные образа собираю и виртуалки использую. И это как бы проблема класса showstopper.
> Но забросили эту фс :-( ,т.к ext4 более предсказуема вела,
Скорее, потому что технологически оно уже ничем таким не передовое, имеет ряд трудноустранимых проблем (да, в EXT4 fsck не склонен чужие файлухи вкатывать в починяемую), а разработчики самоустранились и пошли атаковать какие-то ветряные мельницы. С Reiser4/5. Не, сама идея редизайна ок, но если девы потом на майнтенанс положат не доведя до ума и не фикся баги, то такие файлухи мало кому надо, независимо от супер-технологий, извините. Роялит сочетание в целом и как оно с реальным миром и его задачами стыкуются, а не супертехнологии в 1 конкретном закутке.
> а вариант с очень мелкими файлами в гиганских кол-вах редко распрастранен.
Собсстно рейзер3 шустро работает с кучей мелочи вроде. Но по другим эксплуатационным параметрам не ахти. В частности known issue не от мира сего и разработчики которые где-то там, за денежку датарекавери предлагают, при этом понятное дело стимула чинить вон те факапы нет. Модель в стиле утят скруджа и бесплатных соленых крекеров, а если сушняк - рядом лимонад за бакс :)

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

78. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Rootlexx (?), 27-Май-23, 11:04

Эта проблема решаема на другом уровне через dm-integrity.

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

107. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от DEF (?), 27-Май-23, 12:07

Это должно решаться на уровне ФС, которая для этого и предназначена - гарантировать целостность данных.

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

349. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 01-Июн-23, 02:24

> Эта проблема решаема на другом уровне через dm-integrity.
Проблема в том что получается сложное, стремное месиво, которое при нужде переконфигурить - убиться можно. И когда вместо этого "btrfs device add -> +100500 места в пуле" вот извините но я хочу видеть управление сторажами вот так - а не тот кошмарик.
Со всеми этими dm, LVM и прочими получилось как в IPSec. Ну а btrfs сойдет за вайргад такой себе тогда. Хотя bcachefs на эту роль был бы еще убедительнее :)

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

189. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Kuromi (ok), 27-Май-23, 22:40

Вы так говорите как будто бы ZFS и BTRFS были всегда, а вот дураки разработчки ext* не догадались добавить чексуммы.
На самом деле что ext, что xfs или jfs (помните?) - очень старые файловые системы. И ext и xfs получили кучу модернизаций за прошедшие годы (нынешний xfs вообще мало похож на оригинальный), но их основа - довольно древняя, невозможно там навернуть таких новшеств как в "созданной с нуля" btrfs.
И ничего люди жили с незапамятных времен с ext и xfs.

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

252. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (252), 28-Май-23, 21:28

>  Она довольно надежная и производительная.
Бугага. Переполнения LVM раздера переводит ее в RO и нарушению митаданных, спасает только reboot.

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

258. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 29-Май-23, 00:08

> Она довольно надежная и производительная.
Ее легендарную надежность с протиранием "ненужных" файлов нолями для безопасности трудно забыть. И так цать лет к ряду. И все остальное не сильно лучше. Еще и тормозная что капец при работе с метаданными.
А вон то - это то что редхат получает разогнав всех спецов блочного уровня и заменив их на каких-то индусов. Если обратить внимание, все известные кадры вокруг ФС и блочного уровня из редхата ушли так или иначе. Последним был Bacik, после него там вообще ни 1 известного кадра не оталось, какие-то нонеймы известные хзчем.

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

14. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/–

Сообщение от Виталий (??), 27-Май-23, 00:40

Скажу от себя: её основная годность - более эффективная поддержка гигантских дисков объёмом больше 4х терабайт. Ext4 да, невероятно надёжная и хорошо зарекомендовавшая себя файловая система, НО, на дисках объёмом больше 4х терабайт могут всплывать различные ограничения и замедление производительности (сильно дольше будет отзываться). Что про файловую систему XFS, то она специально создана под гигантские диски, чтобы откликалась быстро не зависимо от того, как много файлов на ней навалено, и т.п. У меня на сервере диск 6 терабайт, работает на XFS. Если коротко - XFS первым делом нужна для гигантских файлопомоек. Для всего остального Ext4 за уши хватит.

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

44. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –1 +/–

Сообщение от gleb (?), 27-Май-23, 08:04

все ext* начисто сливают при конкурентной работе.

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

130. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." –2 +/–

Сообщение от Аноним (8), 27-Май-23, 14:08

Всех сливают? Ну да. На самом деле, по производительности и фичам ext4 уступает только ntfs, но ты и так прекрасно это знаешь. Зато вот по надёжности и фрагментируемости она куда лучше.

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

62. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +3 +/–

Сообщение от пох. (?), 27-Май-23, 10:01

> Что про файловую систему XFS, то она специально создана под гигантские диски
вот сейчас SGI неистово завертелась в гробу.
Нет, конечно же, те 600мегабайтники были "гигантские", чугуниевая хреновина в full size 5" слот выглядит довольно угрожающе, при ее включении корпуса из листовой стали (на ней тогда тоже не экономили) ощутимо подпрыгивали, но вот если про объемчик занимаемых данных, а не места в корпусе, то тот у них был немного маловат по нонешним меркам.

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

259. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/–

Сообщение от Аноним (-), 29-Май-23, 00:13

> вот сейчас SGI неистово завертелась в гробу.
Торент качни, хотя-бы гигов на 200, лучше на забитый диск и без преаллокации, чтоб фрагментировался уж точно хорошенько. А теперь попробуй его стереть... не забудь засечь сколько времени это займет.
У остальных ФС данное действо заканчивается за какие-то сильно более разумные врмена. Или на большие ФС большие файлы и тем более их фрагментация - не предполагаются? :)

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

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

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

Партнёры:

Хостинг:

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

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


	4. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от Аноним (4), 26-Май-23, 23:48
	И в чём её годность заключается?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (3), 27-Май-23, 00:01
	Она довольно надежная и производительная.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+5 +/–
	Сообщение от Аноним (6), 27-Май-23, 00:05
	"Довольно", да.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–8 +/–
	Сообщение от Аноним (8), 27-Май-23, 00:19
	Деградирует xfs куда больше ext4. У ext4 основная проблема фрагментация свободного пространства которая эээ может быть весьма значительной. Ну и время доступа к большим каталогам какое-то не здоровое (фрагментация опять же), но это вроде у всех. У меня xfs только и делала, что портила файлы всю свою историю, пока пытался использовать, поэтому теперь только оправданные эксперименты. Вроде f2fs, но её тоже бездумно пихать нельзя и слишком уж много ограничений.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–5 +/–
	Сообщение от Аноним (3), 27-Май-23, 00:22
	Из розетки часто дергал? Умирающий хард-убожка? Перегревающийся полуразбитый ноут?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+6 +/–
	Сообщение от birdie (ok), 27-Май-23, 00:38
	Я давным давно работал в компании, где backup сервер крутился под RHEL 5 с XFS. В один день, придя на работу, мы не досчитались 200GB backup'ов, которые тупо исчезли. Я дал доступ по SSH с root одному из разрабов - он больше часа ковырялся и ... ничего не нашёл. Каталог с десятками файлов по несколько гигабайт просто исчез. Следов удалённых файлов не было в метаданных, как будто исчез (или обнулился) целый блок инод. Ах, да, и место освободилось. Ошибок XFS в dmesg не было. Нет, это не было взломом или insider work - почему я это знаю, потому что modification time и какие-то метаданные (размер? не помню уже) у головной директории был таким, какими они должны были бы быть, если бы подкаталоги не были удалены, если бы они вообще никогда не существовали. Это вручную было сделать невозможно (кроме как dd if=/dev/zero of=/dev/partition_with_xfs) - так сказал разработчик. После этого мы переехали на ext3, потом ext4 и не имели ни одной проблемы. Ситуация с тех пор улучшилась, XFS стала default FS для RHEL7, но осадок остался.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–4 +/–
	Сообщение от Аноним (3), 27-Май-23, 01:02
	Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+7 +/–
	Сообщение от Гиря (?), 27-Май-23, 08:18
	>Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно. интересно, стабильна потому-что стабильна, чел сверху хоть рассказал свою историю успеха, а у вас какое-то словоблудие.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	184. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (184), 27-Май-23, 21:43
	а какая может быть история, если у него, предположим, не было ни одного факапа? Типа, " - Cлушайте мой случай: За 20 лет использования ничего не потеряли" - так, что ли? Случившаяся "история успеха" - это когда что-то произошло. Это отдаленно напоминает ситуацию с хорошим и плохим админом - окружающие всегда видят как с ж.пой в мыле работает плохой админ (" - Молодец, трудяга, не зря зарплату получает - вон, постоянно что-то ремонтирует то тут то там! Пообедать некогда.") и совсем не знают что такого делает хороший админ (" - Дармоед! Ведь всё и так работает и не ломается. Даже не знаю в каком кабинете он сидит и что там делает, но зарплату, нахлебник, получает!". Т.е. твой собеседник не может тебе ничего рассказать "за работу хорошего админа", если у него всё работало, работает и ни разу не возникали проблемы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:19
	Сосайтник, дай конкретные и объективные измеримые критерии стабильности ФС. И пруфани, что XFS - стабильная ФС.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	294. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 01:48
	> Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была > вполне стабильной. На уровне ext3 уж точно. Особенно затирание файлов нулями. Это почти мировая константа. Я думал что к 2.6.28 это, наконец, починили. Примерно 10 лет спустя от момента как проблема заявила о себе. Но нет, потом еще дочинивали ЭТО дополнительно. Представляете?! Мушкетеры, i++ лет спустя.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	45. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от gleb (?), 27-Май-23, 08:09
	это какой год? я плотно использую xfs с 2002, причём на довольно больших (от едениц Тб в 2002 по десятки Тб в настоящее время). В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов при внезапном пропадании питания). Других потерь занных не было никогда. Я бы всё-таки пошукал-бы, не было ли в этой ситуации человеческого фактора. Или отказа/сбоя, если метаданные хранились на другом устройстве.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	56. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sergey (??), 27-Май-23, 09:22
	Про время и обнуление файлов на ХФС подтверждаю. Но в те времена Шапка еще не допилиа ХФС и не рекомендовала ее юзать. Что касается того рассказа, я после слов : дал доступ по SSH разрабу, читать перестал. Они откуда знают как работает ФС и что это такое. Они даже маке толком осилить не могут.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	97. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (97), 27-Май-23, 11:40
	Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая система;))(
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:57
	> Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая > система;))( Он использовал xfs_db и другие утилиты для отладки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:56
	> это какой год? ~ 2004 > В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов > при внезапном пропадании питания). Очень похоже на наш case.
	Ответить \| Правка \| К родителю #45 \| Наверх \| Cообщить модератору


	230. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (230), 28-Май-23, 16:50
	сервер без ups?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	251. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Омоним (?), 28-Май-23, 20:38
	А вот у вас система никогда в кору не падала? Например, из-за сбоя железа, или ошибки в драйвере? меня вот бывало. И знаете, UPS при этом не помогает совершенно никак.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от kilua (?), 27-Май-23, 08:33
	Души убитых процессов мстят...
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	95. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:35
	XFS не журналирует данные, только метаданные. Эта ФС годна только для файлопомоек, которые не жалко обнулить.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	144. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от лютый арчешкольник (?), 27-Май-23, 15:05
	>Эта ФС годна только для файлопомоек, которые не жалко обнулить. ext3-4 во всех режимах кроме одного тоже ) а с ним превращается в помойку по скорости
	Ответить \| Правка \| Наверх \| Cообщить модератору


	318. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (-), 30-Май-23, 19:09
	>>Эта ФС годна только для файлопомоек, которые не жалко обнулить. > ext3-4 во всех режимах кроме одного тоже ) а с ним превращается > в помойку по скорости Тут очень хорошо написано за что некоторые из нас любят BTRFS. Его логика эквивалентна полному журналированию - но без вот этого вот пеналти по скорости работы. Это одно из ключевых достоинств технологий на основе COW. За это воздается странноватыми свойствами, но вот этот вот момент оно обыгрывает безупречно. На самом деле идея простая: если всю площадь ФС сделать подобием журнала, записывать дважды уже не придется.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Ананоним (?), 27-Май-23, 01:48
	У меня раздел ext4 1GB уже 9 лет живёт, я начинаю тихо охреневать от фрагментации. Нужна программа дефрагментации. Некоторые директории открываются 30 секунд.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	33. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от totem (?), 27-Май-23, 04:45
	Это не фрагментация. "Ext4 умеет на ходу увеличивать размер структур на диске, в которых хранится список файлов и директорий в ней, но не умеет уменьшать. Поэтому если создать в директории много файлов, а потом удалить, она останется большой. При доступе к такой директории приходится читать эти фрагменты, которые ещё и оказываются разбросаны по диску там и сям. Это медленно." Создай новую директорию и перенеси файлы туда. При этом блоки данных этих файлов на диске останутся на своих местах.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	127. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Виктор Федорович Полторищенко (?), 27-Май-23, 14:03
	e2fsck не решает эту проблему посредством опции optimize_extents?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от totem (?), 27-Май-23, 04:47
	Посмотри ls -ld . в "плохой" директории И в хорошей.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	132. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от ZloySergant (ok), 27-Май-23, 14:16
	>Нужна программа дефрагментации. anyfs-tools
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	168. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (168), 27-Май-23, 19:20
	mkfs.ext4
	Ответить \| Правка \| Наверх \| Cообщить модератору


	178. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 27-Май-23, 20:43
	>Нужна программа дефрагментации. е4defrag - штатная программа. Не знали ? Правда есть недостаток-иноды плохо дефрагментирует,хорошо только экстэнты.Поэтому иногда проще перенести каталог на внешний диск а потом обратно, как делали в старые времена.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	31. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Амаяк Акопян (?), 27-Май-23, 03:36
	Подозреваю, что для больших каталогов подойдёт включение опции dir_index
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору