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]

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

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

Баг в ядре, чукча.
xfs наверно единственная годная из всего зоопарка помимо ext.

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

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ообщить модератору

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

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

zfs норм

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

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

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

Капризная и жрущая много ресурсов для своей работы ФС. На BSD иногда есть смысл ее использовать. В линуксе ее функциональность составляется из комбинации ФС и LVM.

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

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

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

>В линуксе ее функциональность составляется из комбинации ФС и LVM.
В линуксе ее функциональность составляется использованием Btrfs.

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

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

Сообщение от n00by (ok), 27-Май-23, 06:45

С той разницей, что я заливал командой dd 2 гигабайта на один из накопителей в ZFS RAID0 и система осталась жива (какие-то файлы побило, но пул восстановил), а BtrFS сама собой рассыпалась.

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

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

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

btrfs нельзя *восстанавливать* через dd, если в системе есть ещё хоть одно устройство с тем-же UUID. Потому, что btrfs автоматически подхватит клонируемое устройство, объеденит его с уже имеющимся и в результате будет "ой".
И об этом написано везде. Аршинными буквами.

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

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

Сообщение от n00by (ok), 27-Май-23, 09:07

А где у меня написано, что я ВОССТАНАВЛИВАЛ btrfs?
Но намёк по поводу аршинных букв понял, исправляюсь:
"BtrFS САМА СОБОЙ рассыпалась."

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

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

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

а делал ЧТО, если лил данные через dd?

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

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

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

> а делал ЧТО, если лил данные через dd?
В каком месте Вам не понятно "заливал командой dd 2 гигабайта на один из накопителей в ZFS RAID0" и как Вы это привязали к "а BtrFS сама собой рассыпалась"?

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

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

Сообщение от мшефд (?), 27-Май-23, 09:46

Другими словами, человек _специально_ _портил_ данные на одном из элементов RAID-массива для проверки его, этого RAID-массива, устойчивости.

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

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

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

Нуб, диски клонировать нужно через send/receive, а не dd.

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

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

Сообщение от n00by (ok), 27-Май-23, 09:06

Прежде чем оставлять своё особо ценное мнение, хорошо бы научиться читать.
Даю ещё один шанс, выделив ключевое слово:
"я заливал командой dd 2 гигабайта НА один из накопителей в ... RAID0 "
Такая операция гипотетически разрушает массив, но в случае ZFS он выжил из-за дублирования метаданных.

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

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

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

ой, ёёёй.
запись произвольных данных на один из элементов raid, тем более raid0?!
это что за удивительное тестирование? тут ни одна фс и ни одна из равновидностей raid не даст никаких гарантий и место хранения метаданных не спасёт.
Подозреваю, что при повторении эксперимента даже и на zfs будет давать сильно разные результаты.

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

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

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

> ой, ёёёй.
> запись произвольных данных на один из элементов raid, тем более raid0?!
Да.
> это что за удивительное тестирование? тут ни одна фс и ни одна
> из равновидностей raid не даст никаких гарантий и место хранения метаданных
> не спасёт.
Гарантий вообще никто не даст, читайте "AS IS" в лицензии.
Потому проверять следует самому.
> Подозреваю, что при повторении эксперимента даже и на zfs будет давать сильно
> разные результаты.
Вот это и есть -- удивительное тестирование.

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

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

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

>Вот это и есть -- удивительное тестирование.
удивительное -- не то слово, я бы применил "идиотское". без обид, просто потому, что результат заведомо будет случайным, непредсказуемым и главное, неповторяющимся.

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

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

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

>>Вот это и есть -- удивительное тестирование.
> удивительное -- не то слово, я бы применил "идиотское". без обид, просто
> потому, что результат заведомо будет случайным, непредсказуемым и главное, неповторяющимся.
Пожалуй, не буду спорить. Если опыт не ставить, но утверждать о неких его результатах - это можно назвать и идиотизмом. Тем более, что Вы сами так предложили. ;)
Но всё же рекомендую впредь проводить хоть какие-то эксперименты, как это делал я.

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

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

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

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

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

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

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

>> впредь проводить хоть какие-то эксперименты, как это делал я.
> эксперимент должен планироваться так, чтобы давать повторяемые результаты, иначе зачем
> он нужен?
Вы ведь не пробовали повторить, но утверждаете, что результаты не повторятся.
> из общих соображений, запись в произвольное место массива, это нештатная и крайне
> маловеротяная в реальном мире ситуация, защиты от которой никто не делает.
И вероятность Вы не рассчитывали. По факту я случайно записал установочный образ вместо флешки на накопитель. Следом провел эксперимент по восстановлению, внимательно почитал документацию и всё получилось.
> Её имитация не может даже ответить на вопорс, "выживет ли массив".
> Потому что вероятность, как у блондики, смотря, куда попадёт, и от
> используемой файловой зависит слабо.
Можно примерно рассчитать, какой процент данных повредится безвозвратно. Но делать я это не буду - Вы же свои утверждения никак не доказываете.

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

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

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

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

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

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

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

После этого нубика и поперли из росы не заплатив и дав повод для многолетних рыданий

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

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

Сообщение от n00by (ok), 28-Май-23, 08:43

После этого работники Росы принялись анонимно клеветать, что меня откуда-то попёрли. Тогда как я был обычный пользователь, кто решал за "разработчиков" то, что те не могли.

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

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

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

>тут ни одна фс и ни одна из равновидностей raid не даст никаких гарантий и место хранения метаданных не спасёт.
Читайте статью (Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных),на Хабре ,просвещайтесь.
Работает при выходе 2 дисков из массива (6.2) или 3 !! (RAID 7.3) дисков.

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

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

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

>выжил из-за дублирования метаданных
В btrfs метаданные тоже дублируются. Режим DUP назвыается.

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

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

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

>>> диски клонировать нужно через send/receive, а не dd
>> хорошо бы научиться читать
>> я заливал командой dd 2 гигабайта НА один из накопителей в ... RAID0
> В btrfs метаданные тоже дублируются.
Это называется "подмена предмета обсуждения" и является довольно унылым приёмом демагогии.

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

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

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

Ну так не демагогствуй. Свою кривую память протести на битроты и контроллеры на data flush. Btrfs рассыпается только если железо давно рассыпалось и его место на помойке. От этого даже ZFS не спасет.

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

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

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

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

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

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

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

> Я не составлял багрепорт о том случае с BtrFS, мне не до
> того было. Ты судишь на основании систематический ошибки выжившего? Поздравляю. Весомый
> аргумент к твоей экспертизе, помимо неумения читать и фантазировать на тему
> железа, когда по факту был накопитель с ионисторами.
Ну окей, тогда я буду вместо него. И скажу что поймал в btrfs пару жирных багов - в RC - в моих конфигах. А еще в отличие от вас я все же оформил баги, потеребил разработчиков, получил очень быстрый, крутой и компетентный ответ. И теперь этих багов нет.
Более того - судя по рассылкам и чатам других ФС у них с багами все примерно так же. Т.е. сыпется все что угодно. И обычно по достаточно хорошей причине, типа мало того что некорректной работы оборудование - так еще в месте где это выходит за допущения дизайна. Скажем ни 1 фс не готова к произвольным глюкам проца. Однако ряд глюков проца может, вот, вызывать асимметрию счета чексум на чтение и запись и в этом случае детектируем. Но это работает для рандомных сбоев а не перманентного повреждения проца симметричного на сбой и при чтении и при записи (с таким процом все как правило падает до того и проблема отпадает сама собой).
И это не про ошибку выжившего а про чудаков думающих что все баги во всех случаях реально отловить. Даже в штуке типа EXT4 до сих пор бывают приколы. А уж в дизайнах типа btrfs и zfs - нет, можно конечно рассказывать легенды, но, имхо, это будут сказки. Начиная с того момента что zfs вообще сторонний модуль и никто ничего не гарантирует на его счет со стороны кодеров ядра. Более того - после вгрузки такого модуля багрепорт на майнлайн вообще не особо вкатишь и это как бы грабли. Конечно можно рассказать что все всегда должно работать идеально и это не должно требоваться, но тут мы возвращаемся к ошибке выжевшего.

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

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

Сообщение от n00by (ok), 30-Май-23, 07:52

> А еще в отличие от вас я все же оформил баги,
> потеребил разработчиков, получил очень быстрый, крутой и компетентный ответ. И теперь
> этих багов нет.
Порадуете ссылочкой на багзиллу?
Если захотите сослаться на боязнь деанона, расскажите, куда заливали образ в пол гигабайта с битой файловой системой, что бы его круто посмотрели спецы. И каким образом заливали. По умолчанию у среднестатистического пользователя нет запасного накопителя - он просто удаляет систему и ставит родную Бесяточку.
> И это не про ошибку выжившего а про чудаков думающих что все
> баги во всех случаях реально отловить.
Априори программа на императивном языке содержит ошибки, её корректность требует доказательств. Частные случаи вроде Вашего для обобщения требуют доказательств по индукции. Всему этому учат в школе.

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

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

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

> Порадуете ссылочкой на багзиллу? Если захотите сослаться на боязнь деанона,
Титул даденый мне вами тому не способствует.
> расскажите, куда заливали образ в пол гигабайта с битой файловой системой,
В моих случаях не требовалось: я как правило сам могу локализовать проблему на моей стороне, в том числе и сделав бисект, с точностью до комита. Кажется это способствует шустрому фиксу проблемы и приятным взаимодействиям. Это опенсорс как он задуман изначально.
Я слал немелкие образа, правда не девам а знакомым которым датарекавери делал, просто торентом Потому что поблочная верификация и докачка/перекачка битого для 500 гигз - аргумент. DHT-only, без трекеров и акаунтов. А чтоб левые это не скачали, сжал 7z с нормальным паролем, еще и образ раза в 2-3 сжимается заодно.
А полгига (вы же только метаданные сняли, если это не опечатка?) можно и просто на любой свой сервак залить.
> что бы его круто посмотрели спецы.
Для себя я считаю что это МОЯ проблема как мне обеспечить вон то. Это же мне надо а не спецам. Если у вас иначе - ну, удачи. Ну и спецы не глупые и после недолгих переговоров с ними в чатике или почте можно устроить кастомные договоренности как и чего. Разумеется трансфер штук на сотни гиг и терабайты оговаривается "штучно" исходя из технологически возможностей сторон.
> И каким образом заливали.
Так у btrfs в send есть режим send где он только метаданные снимает, спецом для дебага. Это еще и приваси сохраняет малость, содержимого файлов там нет.
> По умолчанию у среднестатистического пользователя нет запасного
> накопителя - он просто удаляет систему и ставит родную Бесяточку.
Ну он и идет в вон ту датарекавери лабу и платит, если данные надо. А если умничать попытался и таки не смог - получает кратное умножение ценика. За усложнение работ. Действия без понимания что и зачем имеют свойство делать хуже чем было.
Лично я и не собираюсь таких тянуть в линух. Если им десяточка лучше, пусть пользуются, для меня это ничего не меняет. Я btrfs советую только продвинутым личностям которые могут врубиться в азы путешествий во времени и мультивселенных. А лучше и в азы устройства этой фс. Так будет просто, логично, понятно, удобно. Без этого всего - это как дикарю дать звездолет, при том что он уверен что планета плоская. Куда он такой полетит?
> Априори программа на императивном языке содержит ошибки, её корректность
> требует доказательств.
Я бы сказал что штуки такой сложностью гарантировано содержат ошибки. Вопрос в их вредности и масштабе.
> Частные случаи вроде Вашего для обобщения требуют доказательств по индукции. Всему
> этому учат в школе.
У меня были более мощные учителя по части процессов вот именно разработки софта. Объяснившие некоторые эмпирические, но зато работающие в реальном мире соотношения. И это ИМХО работает лучше теоретических рассуждений. Со школьными знаниями вы никогда не разработаете мало мальски крупный и успешный софтварный проект. Да и с институтскими тоже. Потому что не рассказывают там вон то. Это можно только в большой корпе самому увидеть.

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

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

Сообщение от n00by (ok), 02-Июн-23, 08:59

Так мне и не надо, поскольку мне не нужна BtrFS как таковая (скрипт Шишкина до сих пор её забивает до отказа пустым пространством? вот то-то же). Мне надо было пощупать разные ФС и выбрать что-то. Бисект тем более пустая трата времени, когда данные уже убиты. Он мог бы помочь, если ситуация воспроизводится.

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

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

Сообщение от Аноним (-), 03-Июн-23, 09:18

> Так мне и не надо, поскольку мне не нужна BtrFS как таковая
Тут как бы дело хозяйское, но когда из вас не удается выжать даже точное сообщение об ошибке и детали, ценность такого знания, как бы это сказать... я за объективную и актуальную оценку технологий и борьбу с багами. Но по таким данным невозможно сделать никаких выводов. Даже версии кернелов не указаны, блин. Если 2.6.32 - "кто б сомневался?!". Если 6.3 как в сабже - "ORLY?!"
> (скрипт Шишкина до сих пор её забивает до отказа пустым пространством?
ХЗ. Меня интересуют реалистичные юзкейсы, похожие на мои прежде всего. И поведение фс там. Я их и тестирую. "А если рельсу?" (мужики vs лесопилка из анека) - я не против экспериментов edge case, но их ценность для меня небольшая, потому что я в них никогда не упираюсь. Более прагматичные вещи типа окончания места, даже при каком-нибудь каче торентов проблем сейчас не вызывают. Можно стереть файло и дело с концом. С каких-т о
> вот то-то же).
Если для вас файловые системы Шишкина работают лучше, пользуйтесь ими :). А ZFS мне на уровне дизайна не нравится. Не с чего этому дизайну быть быстрым. Даже не экстентный толком, архаика. А с ломовым подпором RAM что угодно быстрое, но это не заслуга файлухи и ее структур.
Ну и что-то мне подсказывает что с свежими кернелами ZFSникам будет довольно душновато. На выбор или ждать портов черти сколько или будет очень опасное глюкало. Там сейчас апи рефакторят, в том числе vfs и mm и это напрямую затрагивает файлухи. Это очень деликатная совместная игра. И когда игрок не на поле, а где-то там, он ситуацию не видит, и сможет при случае покушать гуана лаптем, имхо.
И кстати если уж мы о птичках, а в этом вашем ZFS дефрагер хотя-бы сделали? А то если CoW на механике забить - сами понимаете, "не очень". Оно и с обычными то "не очень" из-за душняка аллокатору. А многодисковый пул разбирать - тоже "не очень".
> Мне надо было пощупать разные ФС и выбрать что-то.
Ну как бы подход то сам по себе верный. Просто не понимаю откуда взялся вон тот результат, особенно без деталей.
> Бисект тем более пустая трата времени, когда данные уже убиты.
С точки зрения вот именно убиения данных - там офлайн читалка без монтирования в "btrfs" встроена, с возможностью попробовать разные точки входа (CoW же не сносит старые состояния так сразу, есть >1 варианта как его пытаться распарсить). Так что если вот именно данные, именно нужны, и их вот именно вынуть надо, btrfs ИМХО не хучший в этом аспекте. Для нтфс и фат есть офлайн читалки такого типа - как коммерческие виндовые утили, конечно. Иногда очень помогают, "альтернативный парсинг" без монтирования - с недеструктивным вытаскиванием на ДРУГОЙ стораж штука очень полезная, для вот именно вытаскивания, именно максимума данных. А тут такое прям в родном тулките фс. Вот все бы так.
> Он мог бы помочь, если ситуация воспроизводится.
Это да. У меня на самом деле "интуиция" прокачана. Нечто типа чувства мащины. Я могу просто угадать что надо сделать, если видел ситуацию лично. Но без данных и ремотно это не работает. Пространство поиска слишком большое. А очевидные факапы уже давно выбиты xfs :)) test suite :) и миллиардом юзеров фэйсбука. Так что нарываться на подобный сценарий можно весьма долго и безуспешно, даже с явным желанием его сообразить.

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

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

Сообщение от n00by (ok), 03-Июн-23, 17:15

Похоже, тут один фанат автономной ОС устроил дудос жалобами, и бот всё подряд чистит. Как я понимаю, он же и экзитноды Тора своим поведением блэклистит.

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

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

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

> Похоже, тут один фанат автономной ОС устроил дудос жалобами,
Да, бот тут иногда жесткарит, меня правда обычно не полностью выпиливает а скорее скрывает. Я это лечу "сообщить модератору -> распрячьте". Но вообще бот перегибает. Кажется, кроме жалобщика есть и вполне себе абузивные спамеры, судя по логу модерации по некоторым спамерам ну реально рожа кирпича просит. Если мы про фс хотим потрындеть, провоцировать совсем левак наверное не есть айс с их стороны.
> и бот всё подряд чистит. Как я понимаю, он же и экзитноды Тора своим
> поведением блэклистит.
Я пока лишь на ~70% процентов декодировал его эвристику. В остальных 30% подбешивает внезапными сносами или скрытиями сообщений. И мне кажется что спамеров возможно более 1. Хоть я и не анализировал их в деталях, так, лог модерирования посмотрел (ссылка внизу). Если обратить внимание - в логе есть и совершенно отшибленые на голову персонажи.

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

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

Сообщение от n00by (ok), 04-Июн-23, 08:04

Тот персонаж, который заявлял про открутку электросчётчика (цена вопроса за одного человека наверное рублей 500, или 6 долларов; а если ему это существенно, значит за него 50% платит бюджет) накрутил мне тогда 20 минусов. При этом он 20 раз зашёл через Тор и написал сообщения, однозначно попадающие под удаления. Бот эти айпишники занёс в серый список, если кто-то через те же ноды что-то написал, сразу попадает под подозрение. При этом активист в десяти других темах делает тоже самое, плюс наверняка во всё подряд помимо минусов хаотично тыкает. А система защиты сайта писалась в расчёте, что атаковать будет кто-то вменяемый, вот и сбоит.

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

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

Сообщение от Аноним (418), 05-Июн-23, 02:43

> Тот персонаж, который заявлял про открутку электросчётчика
...меня репортнул модерам/ботам наверное раз 5-10 и это даже потерли.
Я прикинул что раз так, в эту игру могут играть и двое. В ответ я репортнул оригинальное сообщение вызвавшее флейм. Вроде прокатило и его вынесли? Я не фанат игры в 1 ворота :P.
> (цена вопроса за одного человека наверное рублей 500, или 6 долларов;
> а если ему это существенно, значит за него 50% платит бюджет)
Да вообще лол. И к тому же - кому как а мне например летом в помещении без кондея не комфортно рядом с пень4 находиться, его выхлоп тепла ощущается прямо рожей при входе в комнату. Даже в холостом режиме. У пней4 с управлением питанием просто никаковски и с их TDP это как бы некий трабл. С стоковым кулером они еще и воют совершенно отвратительно. А кулер на такой TDP который не воет будет стоить побольше чем те мамка+проц, пожалуй.
> накрутил мне тогда 20 минусов. При этом он 20 раз зашёл через Тор и написал
> сообщения, однозначно попадающие под удаления. Бот эти айпишники занёс в серый список,
Ну да. Я заметил что типаж гадит и в долгу не остался репортнув его оригинальный наброс.
> если кто-то через те же ноды что-то написал, сразу попадает под подозрение.
> При этом активист в десяти других темах делает тоже самое,
> плюс наверняка во всё подряд помимо минусов хаотично тыкает. А система
> защиты сайта писалась в расчёте, что атаковать будет кто-то вменяемый, вот и сбоит.
Я так понмиаю что защита в основном от спамботов, а тут "бот" условный, забагованый. Интеллекта не сильно больше - но более рандомный и хаотичный, антиспам боты и тригерятся.

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

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

Сообщение от n00by (ok), 05-Июн-23, 09:07

>> Тот персонаж, который заявлял про открутку электросчётчика
> ...меня репортнул модерам/ботам наверное раз 5-10 и это даже потерли.
> Я прикинул что раз так, в эту игру могут играть и двое.
> В ответ я репортнул оригинальное сообщение вызвавшее флейм. Вроде прокатило и
> его вынесли? Я не фанат игры в 1 ворота :P.
Гипотетически здесь три модератора, а практически у Максима нет времени во всем разбираться. Жалобы  от Анонима на другого Анонима лишь увеличивают энтропию. Если тот персонаж такой активист, ну пусть своё время и тратит активнее, тем более что сносится автоматически.
>> (цена вопроса за одного человека наверное рублей 500, или 6 долларов;
>> а если ему это существенно, значит за него 50% платит бюджет)
> Да вообще лол. И к тому же - кому как а мне
> например летом в помещении без кондея не комфортно рядом с пень4
> находиться, его выхлоп тепла ощущается прямо рожей при входе в комнату.
> Даже в холостом режиме. У пней4 с управлением питанием просто никаковски
> и с их TDP это как бы некий трабл. С стоковым
> кулером они еще и воют совершенно отвратительно. А кулер на такой
> TDP который не воет будет стоить побольше чем те мамка+проц, пожалуй.
Я застал время 4-х пней в торговле и знаю, что обычно покупали больше Селероны или АМД, а разницу вкладывали в память-видеокарту, получая в сумме железо мощнее. Тот процессор называли кукурузным и покупался в основном ради понтов. Потому полагал, что он какой-то тролль. Был бы он специалист, даже в трудном положении, ему бы кто-то подарил старое железо получше - торговцам Б/У его подчас складировать некуда. Теперь подозреваю, что он уже всех в своём городе обошёл и обматерил за предложения обновить его любимый процессор задаром.

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

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

Сообщение от Аноним (425), 06-Июн-23, 00:18

> Гипотетически здесь три модератора, а практически у Максима нет времени во всем
> разбираться.
Мир не идеальный. Я под его неидеальности стараюсь адаптироваться. Если какое-то сообщение кажется ценным или принципиальным, я могу бэкапнуть и при случае вывесить вновь. Порой отредактировав в менее едкое, чтобы осталась техническая компонента мысли а не обсуждения персоналий людей. Это фича, памятуя что "...остальные обсуждают людей".
> Жалобы от Анонима на другого Анонима лишь увеличивают энтропию.
Если какой-то анон назойлив - я начинаю действовать наименее удобным ему способом. Например вынос исходного сообщения - обламывает кайф мелкому жулику на фундаментальном уровне, а заодно рубит предмет флейма. Если кто пытается залочиться на именно меня и выносить именно мои сообщения, я могу выбирать наименее удобные им тайминги или даже менять немного технологии и стиль. Скажем некоторые аноны с номером бывают и мной. Не все, разумеется. Равно как не все Аноним (-) это я. Если кто хочет попытаться трекать всех анонимусов опеннета - окей, круто, это как раз его заякорит и порвет их маленький мозг на тысячи клочков. Может я именно это и хотел? А что, нехай клацают минусы не только нубу но и легиону анонов, нормальный якорь :)
> Если тот персонаж такой активист, ну пусть своё время и тратит
> активнее, тем более что сносится автоматически.
Я ему немного в этом помогаю. С минимальными затратами моего собственного времени. Люблю асимметричные варианты :)
> Я застал время 4-х пней в торговле и знаю, что обычно покупали
> больше Селероны или АМД, а разницу вкладывали в память-видеокарту,
Их больше в офисы ставили. Может, кто ухватил ЭТО нашару когда те их на утилизацию стали сдавать, мало ли. У всяких корп админов иногда можно совершенно даром хардвар получить, порой он даже вполне живой, просто древний. Им иначе еще и утилизацию оплачивать придется и они даже рады если кто утащит.
> получая в сумме железо мощнее. Тот процессор называли кукурузным и покупался в основном
> ради понтов.
Я их видел в офисах скорее - и из за тех свойств их считали куском проблемы, а шиком считалось 64-битная амдшка, все кого я знаю бурно радовались перейда на 64-бит атлоны, оно и воздух грело сильно меньше, и 64 бита это 64 бита, как ни крути :). Это и мультимедии всякой с кодеками, компрессорами и крипто хорошо, и для "продвинутостей" есть где позажигать. Скажем SWAR на 64-бит регистре интереснее чем 32-бит, хоть там как, а в 2 раза больше lanes это в 2 раза больше lanes и фиг оспоришь.
> получше - торговцам Б/У его подчас складировать некуда. Теперь подозреваю, что
> он уже всех в своём городе обошёл и обматерил за предложения
> обновить его любимый процессор задаром.
Мне вообще в свое время эн (полу)дохлых мамок всучили чуть не насильно, с аргументом что я электроникой и компами интересуюсь. Я сперва думал что нафиг они мне. Потом купил паялку - получил полкило зачетных силовых FET нашару, продвинутые конденсаторы и заодно тренировочные кошки для отпайки BGA. А потом я обнаглел и сделал реинжиниринг некоторых преобразователей питания под свои нужды. А чо, многофазные синхронные понижайки это круто и продвинуто, тем более что даташиты есть. И изначально на десятки ампер. И совсем не обязательно именно 1 с чем-то вольта Vcore делать. Можно в принципе "что угодно ниже 12V" если немного подумать (повышать тоже можно, но сложнее и реже надо). Появился выводок для питания всякого разного от 12V ("свинцовые акумы") на продвинутых чипах, халявно. Такие чипы даже на дижикее каком заманаешься покупать, это в основном вагонами производителям мамок уходит а для DIY и мелочи слишком сложно, не особо возят.

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

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

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

> побило, но пул восстановил), а BtrFS сама собой рассыпалась.
Нельзя ли конкретнее?
1) Какие были конфигурации ФС?
2) Что конкретно было сделано?
3) Что случилось с точностью до сообщений об ошибке?
4) "Пул восстановил" очень растяжимое понятие, кмк. Это точно scrub проходит и не разваливается без долговременных последствий?

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

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

Сообщение от n00by (ok), 30-Май-23, 08:17

> 4) "Пул восстановил" очень растяжимое понятие, кмк.
> Это точно scrub проходит и не разваливается без долговременных последствий?
Набираю в поисковике "восстановление zfs пула", читаю по второй ссылке документацию Оркала:
# zpool status
  pool: tpool
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Recovery is possible, but will result in some data loss.
        Returning the pool to its state as of Wed Jul 14 11:44:10 2010
        should correct the problem.  Approximately 5 seconds of data
        must be discarded, irreversibly.  Recovery can be attempted
        by executing 'zpool clear -F tpool'.  A scrub of the pool
        is strongly recommended after recovery.
Т.о. scrub является частью процедуры восстановления и вопрос теряет смысл.
Сложности там, если и были, то с затёртой таблицей разделов. Не помню уже, что именно с ней делал. Но ничего сверхъестественного, иначе бы записал.
> Нельзя ли конкретнее?
> 1) Какие были конфигурации ФС?
> 2) Что конкретно было сделано?
> 3) Что случилось с точностью до сообщений об ошибке?
Не вижу смысла всё это уточнять, когда ZFS я поднял.
Был сделан вывод о непригодности BtrFS "для дома".
Можно просто считать меня нубом и обывателем - вполне годное основание для вывода. ;)

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

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

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

> Набираю в поисковике "восстановление zfs пула", читаю по второй ссылке документацию Оркала:
Я наверное непонятно выразился, пардон. Мой апстрим - майнлайн, мне интересно чтобы он, и его технологии, используемые мной (включая btrfs) работали хорошо. На внемайнлайновые вещи (включая zfs) это НЕ распостраняется. Если интересно почему: я плотно подсел на апстрим, опенсорс и пользуюсь возможностями удобного, быстрого фикса багов путем пинка конкретных тушек с подробными данными о проблеме, вплоть до точного коммита (если я смог в это). Это возможно только с чистым майнлайновым кернелом актуальной версии.
В этом контексте я бы послушал что с btrfs случилось. Что делалось, в каких обстоятельствах (конфиг, версия ядра, etc), если это что-то характерное для актуальных версий ядер, все такое. Что за сообщения об ошибке и т.п.. Это конечно в чисто научных целях, но я люблю всякие странные эксперименты, анализ того что я вижу и это иногда срабатывает. Для себя это срабатывало хорошо, в ядре не осталось ни 1 бага который бы мешал мне жить. Мало ли, вдруг сработает и в подобных случаях - улучшив технологию которую я использую. Это был бы правильный вариант "спасибо" создателям оной с моей стороны. Разумеется без гарантий и обязательств, я не саппорт.
> Сложности там, если и были, то с затёртой таблицей разделов. Не помню
> уже, что именно с ней делал. Но ничего сверхъестественного, иначе бы записал.
Таблицу разделов не особо сложно чинить как по мне.
> Не вижу смысла всё это уточнять, когда ZFS я поднял.
В моем случае смысл изложен выше. Ну как бы дело хозяйское.
> Был сделан вывод о непригодности BtrFS "для дома".
На мой вкус это либо неверный, либо неактуальный вывод, идущий вразрез с моими выводами - у меня btrfs много где, в том числе и "дома" (на компах, лаптопе и все такое). Если я не прав, хотелось бы каких-то более убедительных технических деталей (на основании которых я попытаюсь предпринять действия чтобы мои заявления стали ближе к правде).
> Можно просто считать меня нубом и обывателем - вполне годное основание для вывода. ;)
Это было бы проще всего. Но этот мир так устроен что правда редко бывает простой или приятной, законы Мерфи в технике имеют место быть. К тому же так вышло что я отличаю "n00by" от фонового шума и накопленные данные свидетелствуют что это было бы слишком упрощенной картиной мира.

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

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

Сообщение от n00by (ok), 31-Май-23, 15:35

> В этом контексте я бы послушал что с btrfs случилось. Что делалось,
> в каких обстоятельствах (конфиг, версия ядра, etc), если это что-то характерное
> для актуальных версий ядер, все такое. Что за сообщения об ошибке
> и т.п.. Это конечно в чисто научных целях, но я люблю
> всякие странные эксперименты, анализ того что я вижу и это иногда
> срабатывает.
Я поступил ровно так же, как в случае с ZFS. Набрал в поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить. Так на моём месте поступил бы средний пользователь, если он не полный чайник. Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа не дождался - как всегда внезапно понадобился.
Случилось, что при старте ОС неожиданно оказалась BtrFS немонтируема, в том числе в R/O, что несколько раз спасало. А ZFS я сам сломал.
>> Был сделан вывод о непригодности BtrFS "для дома".
> На мой вкус это либо неверный, либо неактуальный вывод, идущий вразрез с
> моими выводами - у меня btrfs много где, в том числе
> и "дома" (на компах, лаптопе и все такое). Если я не
> прав, хотелось бы каких-то более убедительных технических деталей (на основании которых
> я попытаюсь предпринять действия чтобы мои заявления стали ближе к правде).
"Я использую" и "посоветую другу для дома" не одно и тоже. Если надо просто ФС для SSD, то проще F2FS или EXT4 для консерваторов. Если надо снапшоты, более-менее ёмкий RAID с кешем на NVMe - то как бы и нет выбора кроме ZFS. Если надо "на работу" - так там есть админ, пусть он убеждает.

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

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

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

> Я поступил ровно так же, как в случае с ZFS. Набрал в
> поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить.
Я бы не назвал идею что-то делать с фс по советам из интернета от хз кого удачной идеей. Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше. При этом крайне желательно самому понимать что и зачем делаем и насколько оно соответствует ситуации. Иначе риск получить фигню высокий. С любой ФС.
Одна из причин по которой мне рефлинки нравятся - возможность слепить "копию" образа восстанавливаемой файлухи - и прогнать допустим fsck на "копии" дешево и сердито. При этом реально оно конечно создается в жалкие секунды для образа пару терабайт, а потом занимает места только на дельту относительно оригинала. А нужно это вот как раз на случай если результат попытки починить до моунтабельного состояния не понравится. Так бывает, увы. Много с чем и почему, так что запасной план на этот случай хорошая идея.
> Так на моём месте поступил бы средний пользователь, если он не полный чайник.
Средний пользователь при должной прыти заканчивает у вооон тех господ из датарекавери лабы. С кратной накруткой за прыть, сделавшей восстановление данных сложнее а потому - в разы дороже. Мои знакомые если не уверены в себе меня теребят, но тому есть причины, эн вполне успешных рекавери сессий и общее понимание азов того ремесла :)
> Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа
> не дождался - как всегда внезапно понадобился.
А это был что? HDD? SSD? Ну и там достаточно было снять метаданные без данных с него, у btrfs есть такой вариант, спецом для багрепортов и воспроизведения багов. Только метаданные - сильно легче и их хранить не особо напряжно. Но да, это слегка продвинутости, для тех кто настроен с вылезшей проблемой зарубиться. Т.е. нормальных опенсорсников.
> Случилось, что при старте ОС неожиданно оказалась BtrFS немонтируема, в том числе
> в R/O, что несколько раз спасало. А ZFS я сам сломал.
Оказалась немонтируема - печально, спору нет. Но с технической точки зрения хотелось бы понять что произошло. Скажем какое сообщение было, etc. А так фигня у всех случается.
> "Я использую" и "посоветую другу для дома" не одно и тоже.
Эм... тут есть достаточно неопределенный фактор "квалификация друга". Если это хомяк с виндой, он может и не врубиться в продвинутости типа снапшотов, рефлинков и всего такого, если едва одуплял основы иерархии это слишком круто. А если это мощный *никсоид... ему я и с data recovery при такой нужде помогу практически "за интерес". Я предпочитаю дружить с вон теми и поэтому в целом это не проблема, есть группка друзей использующих достаточно продвинутые технологии и обменивающихся опытом.
> Если надо просто ФС для SSD, то проще F2FS или EXT4 для консерваторов.
У меня F2FS не пережил power loss/system reset tests когда я оценивал идею затолкать его как ФС для одноплатников. Он быстрый, дружественный к флешу... а еще он феерично разлетается без особых усилий. И даже fsck далеко не всегда может его собрать. И если это не получилось, плана Б особо и нету. Кроме скорости и дружественности к флешу он ничего предложить не имеет. Если этого достаточно - ну, окей. И все же снапшоты системы это круто и удобно, делает основную систему чем-то похожей на виртуалки, если кто понимает multiverse и альтернативные таймлайны из sci-fi, он оценит возможность итеративно догнать систему до нужного состояния даже если изначально эксперимент не прокатил за весьма обозримое время. А в файлухах без снапшотов undo нету. Можно LVM сделать но это муторно и работает хуже.
На самом деле все просто: на F2FS надрывается по сути 1 кодер в самсе. На котором еще и ksmbd на минуточку. Может ли 1 чел столько нагрузки тянуть - вы наверное поняли. Это продукт корейской галерной промышленности. Со всеми вытекающими. Но да, дизайн дружественный к флещу. Впрочем, btrfs тоже флешу не враждебен, например. Для флеша логика CoW достаточно удобна, а в zoned режиме оно вообще само FTL напоминает по логике.
Ext4? Ну он как бы есть, как бы работает, на идеальном железе даже не особо убиваем, а если что-то все же испортилось, fsck его все же обычно чинит. Быстрый ли он? Смотря что с ним делать. И его основной минус - он не парится что будет с данными. Чексум нет. С полным журналом он тормоз, а без - можно смесь старого и нового состояний файла получить, это обычно непригодно к использованию.
> Если надо снапшоты, более-менее ёмкий RAID с кешем на NVMe
> - то как бы и нет выбора кроме ZFS.
ЧСХ и с оным и с btrfs (там они через bcachefs кэш делают) на этом прикольно налетает, когда затертый до дыр SSD начинает чудить. Реакция SSD на окончание ресурса это такой отдельный достаточно забавный топик.
Ну и вот советовать друзьям такое - реально разве что в убунте. Где проблемы стороннего модуля майнтайнеры порешают. Без этого - очень круто когда не маунтится системная файлуха потому что сторонний модуль отъехал, аж 2 раза. И тут в зависимости от юзера возможны варианты. К тому же вон те например свежую виляшку какую хотят, или еще что - значит с свежим кернелом. Так то они есть в бэкпортах и прочем но вот как там ZFS себя чувствует... использовать друзей как лабораторного мыша тоже как-то такое себе имхо. Я btrfs'а продвинутым советую, тем что сможет его плюсы оценить. Прозрачно обрисовав что сие с свежими кернелом. А любители старины типа 2.6.32 вроде поха, разумеется, успеха с этой технологией не достигнут.
> Если надо "на работу" - так там есть админ, пусть он убеждает.
Ну, я сам себе админ. Впрочем и сборщик образов систем и фиксер системных проблем. Это как раз та культура самообслуживания которая зародилась в опенсорсе. И использование вот именно возможностей, именно опенсорса. Когда при проблеме я могу гораздо более продвинуто диагностику сделать, а при острой нужде и патч для себя попытаться скроить. Вот так опенсорс получает пойнт. А если им пользоваться как виндой... ну и в чем профит? ;)

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

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

Сообщение от n00by (ok), 01-Июн-23, 08:41

>> Я поступил ровно так же, как в случае с ZFS. Набрал в
>> поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить.
> Я бы не назвал идею что-то делать с фс по советам из
> интернета от хз кого удачной идеей.
Это как раз один из критериев, почему BtrFS непригодна для дома.
По ZFS имеется документация от Оркала.
> Разработчики, или хоть топичные форумы,
> чаты и рассылки сильно лучше.
Это не годится. В торговле такой финт называется навязанная услуга.
>> Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа
>> не дождался - как всегда внезапно понадобился.
> А это был что? HDD? SSD? Ну и там достаточно было снять
> метаданные без данных с него, у btrfs есть такой вариант, спецом
> для багрепортов и воспроизведения багов. Только метаданные - сильно легче и
> их хранить не особо напряжно. Но да, это слегка продвинутости, для
> тех кто настроен с вылезшей проблемой зарубиться. Т.е. нормальных опенсорсников.
Это SSD с ионисторами, где производитель обещает завершение операций записи при отказе питания. Слишком много действий для восстановления данных - не годится для дома. Проще взять из резервной копии и ФС снести к чертям.

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

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

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

> Это как раз один из критериев, почему BtrFS непригодна для дома.
На мой вкус так я и еще эн продвинутых юзерей пользуемся этим всем - в том числе и дома, на десктопах, лаптопах, одноплатниках и роутерах (скачка файлов в фоне или торенты) всяких, и каких-то траблов с этого всего нету. А у меня с энных пор образа для одноплатников на достаточно больших выводках (сотни) на btrfs перешли. А перешли после того как разок пришлось чинить в темпе вальса одноплатник который ВНЕЗАПНО умер. По обидной причине. Там был простой EXT4. И при загрузке - вот 1 бэд случился. Зато - под libc6! Этого хватило чтобы я поимел ВНЕЗАПНОГО гимора. Я обиделся на столь дурной теорвер и стал под образа btrfs с DUP юзать, теперь 1 рандомный бэд не проблема, только в лог матюки и я знаю что да, вон там карточку неплохо б заменить, если повторяется часто, но это именно раннее предупреждение. Играть в это казино можно долго, я отловленые текучки и сыпучки под тестовые сетапы поюазл и пока даже совсем поганые в такое казино вот не проиграли чтоб 2 копии побились в 1 логическом смещении. Так теорвер ощущается намного приятнее. Моя идея в том что с законами природы глупо спорить, ими надо пользоваться на свое благо. Ну вот теорвер в свою сторону крутануть...
> По ZFS имеется документация от Оркала.
При том эта документация - на версию которая у вас дома очень врядли появится. Откуда бы у вас дома вот оно? Это ж только для соляры. А для линуха это ZoL - сторонние перцы, с отдельным форком этсамого. Развивавшийся независимо. Конечно можно о дельте между форками узнать и вот таким странным способом, но...
И чисто практически мне док с вики/readthedocs/мана вроде хватило для понимания что и куда. А со временем я из интереса немного въехал в оющую структуру этой штуки и могу достаточно осмысленно применять фичи на свое благо с минимумом проблем. А вот что с ним надо сделать чтобы он совсем умер - я не знаю. Если б знал относительно честные методы - давно б зарепортил.
Пока я видел только юзерей с протертыми SSD-кешами где накопители труху файлухе отдавали, без избыточности, но с такой конфигой - это сами юзеры виноваты что сделали стремный конфиг и не чекали ресурс SSD'шника до момента пока он не протерся в хламину и не начал выгружать труху просто мегабайтами, без копий этого, а на такое в общем никто их ФС не расчитан.
>> Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше.
> Это не годится. В торговле такой финт называется навязанная услуга.
Лол. Если за это деньги брать как рейзер, я еще пойму претензии. Но денег платить не предлагалось. Я лишь сообщил какой вариант для меня самого работал лучше всего. ИМХО отличный вариант для разумных существ имхо. А в опенсорсе еще и культура самообслживания приветствуется, если кто не в курсе. Ну а лучшее что случается это если я смог вычислить мощный баг при помощи вон того зала. А какие-то додики в интернете - они кто и почему я вообще должен на их "клевые" советы время тратить? И главное вас не смущает что сейчас полно блогеров пишут красивые слова чисто для повышения популярности бложика или потрындеть? Достоверность и актуальность этой инфы - полная лотерея. От джекпота до эпикфейла. Чтобы понять что вам подсунули надо как минимум разбираться в этом дизайне ФС и быть в теме на уровне выше среднего, а этого как раз и нету. Я и предложил прийти в места где информированность по топику заведомо выше среднего.
> Это SSD с ионисторами, где производитель обещает завершение операций записи
> при отказе питания.
Обещают все эти господа много где и чего, а что, где и как реально происходит по факту, в реальных условиях - сильно отдельный вопрос, требующий изучения. Ну вон у самсуней EVO некоторые версии фирмварей могут харакири себе вообще сделать если еще удумать обещаной поддержкой TRIM воспользоваться. При том не сразу, а изредка, в определенных ситуациях. Харакири, кстати, в характеристиках не обещают, но я видел достаточно юзеров с ЭТИМ, и их было столько что в майнлайне задолбались и внесли определенные модели и версии фирмварей в блеклист - для них DISCARD форсировано отключен, даже если накопитель и думает что умеет его. Ну вот такой вот оверайд с затыканием чужого фирмварного глюка на уровне кернела. Хотя нормальный фикс это фирмвару глюкастику обновить, конечно.
У интелей недавно тоже какие-то обсираки были с некоторыми топовыми SSD, деталей не помню уже.
> Слишком много действий для восстановления данных - не годится для
> дома. Проще взять из резервной копии и ФС снести к чертям.
Я как бы согласен что так быть не должно. И если б мне была известна ситуация когда вот это воспроизводится, я бы ее аннулировал, собрав максимум деталей и пинганув девов. Но у меня на данный момент все работает, потому что все что я знал я и репортнул и плотно впрягся в процесс фикса, и это возымело предсказуемый результат - баги были починены, у меня все просто работает. Да и баги были словлены "правильно", -RC ядрами, так что до реальных продакшнов и не долетели как раз. Да, прогон и валидация -RC требует некоторых затрат времени, но если я уж плотно подсел на линух в моих проектах, я знал на что шел и это... ну... такой вот левелап в линуксе и его скиллах. Когда можно стать сам себе систембилдером, сапортом и в общем-то чем-то типа OEM :). Как по мне это было лучшее что линух мог мне предложить. Хороший апгрейд из консумеров и пользователей в часть процесса :)

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

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

Сообщение от n00by (ok), 02-Июн-23, 09:04

>>> Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше.
>> Это не годится. В торговле такой финт называется навязанная услуга.
> Лол. Если за это деньги брать как рейзер, я еще пойму претензии.
Вместо денег в ходу монета с чеканкой "сделай бисект".

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

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

Сообщение от Аноним (-), 03-Июн-23, 09:33

> Вместо денег в ходу монета с чеканкой "сделай бисект".
Вообще - вы в чем-то правы. Паразитизм и потребццтво в более-менее живом и успешном опенсорсе не очень приветствуется. Потому что ведет к загниванию проекта и нездоровому климату в экосистеме.
И да, это такая себе оплата без оплаты, но мне почему-то кажется что вооон те господа для меня повкалывали сильно больше чем я - для них, поэтому мне грешно жаловаться. А кто хотел, вот натурально, чистым потребителем быть, для него винда есть. За денежку, конечно. Потребители не имеют какого-то внятного смысла в опенсорсе, это ж почти имплементация коммунизма.
И да, так то на подумать почему СССР развалился. Ну вот у вас там не удалось воспитание человека разумного. А опенсорсники более менее могут вот. Чисто технически: потребители в конечном итоге обычно встревают в технические проблемы уникальные для себя, никто с оными бороться не хочет или не может - и бай бай, проваливайте на свою дрисняточку или что там у вас, никто не будет скучать об балласте, который получив сотни халявы совсем уж не контрибутит в ответ. Это примерно как торент, можете и не аплоадить, просто будете в самом хвосте списка, получая остатки бандвиза если они есть. А если нет - их получат более полезные клиенты. И хрен такую логику обойдешь, это самозащита сообщества от разрушения.

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

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

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

> В линуксе ее функциональность составляется из комбинации ФС и LVM.
Спасибо, кэп. Собственно zfs так и появилась.
С дедубликацией по сути всего 3 ФС: zfs, btrfs, xfs. Последние две нестабильные. Вот и весь выбор.
Снапшоты, copy-on-write, сжатие, репликация - весь фарш есть. Надежность уровня production (что не отменяет необходимость бекапов, как и везде). А лишняя (конкретно в данном случае) прослойка LVM не нужна.
Ставить zfs в старый ноут 500ГБ hdd 4ГБ ram смысла конечно нет. Но уже для домашней файлопомойки вполне.

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

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

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

thin lvm, потому что иначе снапшоты будут ни разу непохожие на те что у zfs. А это - внезапно, "капризное и много ресурсов требующее для своей работы". Причем заметно более капризное и ненадежное чем zfs.
И еще и крайне неудобное в управлении. Понадобилось тебе выделить отдельную фс с другими параметрами монтирования под какой-то специфический проект - zfs create pool/mount/point
А теперь опиши все костыли и подпорки с thin lvm - предположим даже что места там с избытком и я в этом create не попросил чего странного - например, зарезервировать мне место чтоб оно точно не кончилось вместе с каким /var/log/trash
Единственное (но надо признать наиболее типовое) в чем этот вариант удобнее zfs - это рутинное увеличение пула не имеющего избыточности (или имеющего средствами железа).
Но это потому что ZoL.

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

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

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

Сложная в освоении и память жрет побольше некоторых.

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

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

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

знаешь, если две команды zfs и zpool тебе сложно - я боюсь представить что тебя ждет когда ты столкнешься с lvm, где их аж пять и все имеют совершенно зубодробительные синтаксис и семантику.
Память жрет поменьше чем надо бы - потому что вариантов кроме оставить половину системе там в современных версиях нет. Но за счет ARC может что и выиграет даже.

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

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

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

Меня ждет btrfs.

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

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

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

если тебе даже zfs сложно оказалось осилить - она тебя не дождется.

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

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

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

Чего там ждать? mkfs.btrfs и все. Никаких zpool и прочего не нужно.

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

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

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

> Чего там ждать? mkfs.btrfs и все. Никаких zpool и прочего не нужно.
о ужас, набрать zpool вместо mkfs ?
В общем, степень адекватности опеннетчиков уже очередное дно пробила.

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

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

Сообщение от n00by (ok), 30-Май-23, 08:24

Это называется "когнитивная ригидность" в психологии и "синдром утенка" у местных экспертов.
Мне было проще собрать модули zfs и spl, чем читать man mount.)

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

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

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

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

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

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

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

> если тебе даже zfs сложно оказалось осилить - она тебя не дождется.
Btrfs заметно проще, приятнее и дружественнее в управлении. Однако чтобы с btrfs стоит почитать ман и понять основы ее устройства. Тогда dos и donts станут более очевидны.
А так оно просто работает. В сложных случаях можно живьем отловить разработчков btrfs и в отличие от zfs они даже могут дать дельные советы, в отличие от zfs'ных с их саморекламой и рассказами почему именно збс быть не может (как будто это кого кроме них интересует).

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

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

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

> Btrfs заметно проще, приятнее и дружественнее в управлении.
Покажите пальцем, в каком месте?
Что именно вам сложно и неприятно в банальном управлении zfs ? То что у нее не кончаются метаданные в самый неожиданный момент?
> В сложных случаях можно живьем отловить разработчков btrfs и в отличие от zfs они даже могут
> дать дельные советы, в отличие от zfs'ных с их саморекламой
вас обидели разработчики zfs? Покусились на святое?

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

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

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

> Покажите пальцем, в каком месте?
Добавление, замена, изъятие девайсов, рестрайп на ходу, все такое. Можно просто подоткнуть девайс если места мало. Или даже временно расширить хранилку под разовое действо, а потом вынуть добавленые девайсы. Или даже передумать насчет схемы хранения. И все это парой команд, логично, ненапряжно, шустрее чем можно было бы ожидать - благодаря backrefs и дизайну с блочными группами оно может трекать что реально аллоцировано и кантовать только это. Это управление ФС
> Что именно вам сложно и неприятно в банальном управлении zfs ? То
> что у нее не кончаются метаданные в самый неожиданный момент?
Ну для начала мне сложно out of tree файлухой пользоваться. Это сразу +100 к системным граблям и траблам с репортом багов в майнлайн. Еще я нахожу очень странным что дедуп только с ломовым жором ресурсов - и более никак. Финт с "reflinks" мне в этом плане очень понравился: это по смыслу стопроцентный дедуп блоков, всего лишь. Когда копия изначально на 100% дедупнута относительно оригинала. Мне нравится гибкость дизайна, типа схемы хранения DUP для 1-дисковых систем. Это намного лучше лечилова про энтерпрайз, блаблабла, и позволяет прикрутить в достаточно странные применения, типа одноплатников или ноута с 1 диском. Повышает надежность системы на этом всем. Вместо рассказов про правильное железо. Это сильно лучше чем ничего. ZFS под такие допущения не делался, так что если это не энтерпрайзная файлопомойка была... а представляешь, снапшоты например актуальны на "системном диске" а вовсе и не файлопомойке. Ну или вон к роутеру 3-терабайтник с btrfs прицеплен. По скорости как ext4, плюс-минус, RAM и CPU трескает умеренно, хорошо когда фича масштабируется вверх и вниз. И иногдя я хочу именно карманный вариант героя.
> вас обидели разработчики zfs? Покусились на святое?
Ммм... скорее их обидели разработчики btrfs. В сравнении. Просто взаимодействие с btrfs'ными понравилось сильно больше. Люблю когда взаимодействия конструктивные, мощные, с работой над проблемой а не рассказами о том кому что (не)нужно, вилянием окороком и маркетингом. Хороший дизайн в маркетинговом булшите не нуждается. А так было бы интересно увидеть что Кент сделает, с учетом эксплуатации btrfs. Но это не быстрая история. Когда такие штуки быстро делались...

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

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

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

А топик как раз о том как все годно в XFS получилось? :)

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

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

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

Партнёры:

Хостинг:

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

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


	3. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+10 +/–
	Сообщение от Аноним (3), 26-Май-23, 23:42
	Баг в ядре, чукча. xfs наверно единственная годная из всего зоопарка помимо ext.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	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ообщить модератору