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]

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

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

Прочитал обсуждение.
Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо.
Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то, и другое.
Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,  которая просто работает? Как например NTFS?

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

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

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

> Прочитал обсуждение.
> Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо.
> Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то,
> и другое.
> Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,
>  которая просто работает? Как например NTFS?
Да, EXT4 стабильнее всех работает, а те кто про неё пишут гадости, подсосы бутерфс от красношляпы либо просто полезные идиоты, либо на зряплате. А ты вообще жирный MS-тролль, так-то.

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

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

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

>подсосы бутерфс от красношляпы
Сосайтник, бутерфс от оракла.

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

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

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

Ой извините подсосы бутерфс от оракцле.

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

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

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

>Как например NTFS?
Вот это рили дерьмо.
>а под линукс есть хоть одна нормальная файловая система
Конечно есть - Btrfs.

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

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

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

> Вот это рили дерьмо.
Подтверждаю - рекаверил убиты в хлам нтфсы юзерам у которых все прекрасно работало до момента когда ВНЕЗАПНО развалилось вдрызг и перестало маунтиться. В основном это из-за сбойной оперативы. Но чексуммы и такое хайлайтят, потому что в таком случае несовпадения периодически лезут и это заметно.

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

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

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

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

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

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

Сообщение от Читатель сайта (?), 27-Май-23, 11:15

Сейчас придут и расскажут и почему NTFS тоже дерьмо. :)
А IMHO - вся беда в том, что серебряной пули так и не сделали. Каждая из этих FS хороша для употребления в своих условиях. Но это ж думать надо...

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

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

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

> etx4 - дерьмо
Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.
Более надёжной ФС в Линукс нет и не было.
Самый большой косяк - не умеет делать дефрагментацию свободного места, но с приходом SSD проблема перестала быть актуальной.
Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.

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

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

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

>Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.
И чо? У одного только Фейсбука, btrfs юзается в хвост и в гриву на более миллиона серверов.
>Более надёжной ФС в Линукс нет и не было.
Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори.
>Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.
Укатайка...

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

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

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

> Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори.
Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum.
Проблема не настолько серьёзная, чтобы говорить, что без этого ФС не ФС.
Я бы назвал data checksum nice to have фичей, но никак не crucial/essential.

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

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

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

>Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum.
Это не решения, а днищенские костыли. Гарантия целостности данных должна обеспечиваться на уровне ФС.

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

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

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

> Это не решения, а днищенские костыли.
Кто это решил? Я использую файлы с checksums более 20 лет. Проблем не было.
Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). Приехали?
Я скажу ещё более страшную вешь - checksumming без recovery бесполезен буквально полностью. Всё, отдыхайте. А вот тут решений на уровне FS я не знаю вообще. Есть PAR2, но это бесконечный геморрой, который я заменил на RAR.
> должна обеспечиваться на уровне ФС
Кто кому должен? Почему должен?
Я сейчас скажу, что вы мне должны $1M, потому что так "правильно". Всё? Приехали?
Не надо свои хотелки превращать в status quo.

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

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

Сообщение от пох. (?), 28-Май-23, 00:20

> Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам.
> Чем вам это поможет?
копий данных на современных fs может быть, внезапно, не одна. И даже носителей тоже может быть не один.
> FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS).
когда кажется - помогает креститься. zfs (как и любая другая с контролем целостности) ничего не выдаст, вернет ошибку чтения, если не имеет второй копии. И ты хотя бы узнаешь что файл поврежден (возможно копии нет у fs, а ты был умный и у тебя она есть где-то еще).
Если копия есть и валидна - молча вернется правильный блок, а битый при scrub будет перезаписан, без необходимости тебе лично участвовать в этом процессе.
Раз ты даже этого не знаешь - чего стоит твоя "экспертиза"?

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

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

Сообщение от Sw00p aka Jerom (?), 28-Май-23, 10:34

>копий данных на современных fs может быть, внезапно, не одна.
И какой копии доверять? Как доказать целостность? Где гарантии, что копии целые? Человек до сих пор не придумал этого механизма.

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

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

Сообщение от Прохожий (??), 29-Май-23, 11:01

Тебе ж написали:контрольные суммы.

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

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

Сообщение от Sw00p aka Jerom (?), 29-Май-23, 11:36

> Тебе ж написали:контрольные суммы.
а где храним эти контрольные суммы? и в каком количестве?

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

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

Сообщение от Аноним (400), 03-Июн-23, 19:38

> а где храним эти контрольные суммы? и в каком количестве?
Ну вот в файлухе например можно, если это не блочный а "файловый" дизайн был. В количестве копий блока разумеется - если это нечто типа RAID1. А что, чексуммы мало места vs блок занимают, оверхеда не так уж много, ценой очень скромного оверхеда знаем какая копия верная и возможности (авто)рекавери сильно возрастают. Для штук типа RAID5 парити для блоков чексум можно и не хранить по математическим причинам, для блоков данных ессно чексумы надо.

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

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

Сообщение от Sw00p aka Jerom (?), 03-Июн-23, 21:26

> знаем какая копия верная
откуда знаем? как понять чек-сумма битая или блок данных? разве не на том же устройстве они хранятся? кто дает гарантии "небитости" чек-сумм?

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

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

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

> откуда знаем? как понять чек-сумма битая или блок данных?
ИМХО пофиг: если не совпадает -> проблемная копия, просто берем из другой. И какая разница чексум в копии порушился или сам блок? Если у нас исправная копия есть, мы как раз и отрекаверим и блок и его чексум.
Эта логика на имеющихся у меня текучках и сыпучках работает изумительно, круто разворачивая теорвер в совсем другую сторону. Теперь даже на 1 неидеальном девайсе я проигрываю не "когда бэд попал под что-то важное" а "когда бэды совпали так что накрыло обе копии". И выиграть в такой джекпот при относительно редких сбоях и относительно большом числе секторов не очень реально за обозримое время. ИМХО так теорвер намного прикольнее ощущается. А всего лишь критерии проигрыша немного пересмотрели.
> разве не на том же устройстве они хранятся?
Вот как раз и пофиг, чексумы отъехали или блок, отрекаверить из исправной версии и дело с концом.
> кто дает гарантии "небитости" чек-сумм?
Стопроцентные конечно только страховой полис. Но если у вас глючное железо, на фс с чексумами это как раз очень хорошо видно когда расчитаное при записи не сходится с расчитаным при чтении, так что идут матюки фс в логи - и мы знаем что железо гунявое. У меня так целая мини коллекция глюкастиков образовалась, там и флехи, и карточки, и ссд, и мамка и проц и рама и даже шнурки сата :). Шнурки кстати в смарте видно но это ж надо явно лезть туда, а тут вот готовые матюки в логах...

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

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

Сообщение от DEF (?), 28-Май-23, 00:52

>Кто это решил?
Это решили логика и здравый смысл.
>Я использую файлы с checksums более 20 лет. Проблем не было.
Никого не интересует твой опыт использования костылей.
>Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет?
Я запущу scrub. Если у меня зеркальный RAID, то Btrfs автоматически восстановит поврежденные данные и метаданные из уцелевшей копии. Если у меня сингл, то ФС как минимум сообщит мне, какие блоки поврежденны и на каких файлах. И я как минимум не допущу попадания битых файлов в новый бэкап и восстановлю их из старого бэкапа.
>Кто кому должен? Почему должен?
За целостность данных в реляционной БД отвечает именно БД, а не какие-то костыли за пределами БД. Точно также и с ФС. ФС для этого и создана, чтобы обеспечивать целостность данных. Это ее прямая зона ответственности.

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

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

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

*ля, стыдно всё это читать.
Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums?
Или вы реально думаете, что домашние пользователи все побежали делать RAID и хранить копии данных в трёх географических разделённых местах?
У вас г*вно в голове, уважаемый - вы считаете априори, что
1) Все данные - это безумно важно!
2) Нужно убиться потратить денег, чтобы их не потерять даже в случае атомной зимы!
Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно.
Вы так бы и начали: "вот я работаю там и там, у нас такие критерии, нам только ZFS подходит".
Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING".
*ля. Ржу. Корона не жмёт?

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

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

Сообщение от dasd (?), 28-Май-23, 17:34

>Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums?
Начните уже думать, а не только троллить.
RAID защищает немножко от другого.
Куча копий данных - как выбрать верную? (Битовые ошибки - существуют)

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

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

Сообщение от DEF (?), 30-Май-23, 17:10

Мда. С тобой все ясно. Таблетки не забывай принимать вовремя, которые тебе назначил твой лечащий психиатр.

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

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

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

> Если у вас есть RAID, куча копий данных, да на кой хрен
> вам вообще checksums?
А откуда мы знаем которая из копий на райде правильная когда на отличия налетели? Ну вот для этого чексумы и надо :). Кроме того чексумы проверяют работу железа end to end.
И если сбойное железо не отлавливать - оно и кучу копий может прекрасно загадить. Счет и верификация чексум выступают неплохой такой "канарейкой" сильно демаскирующей это все.
> Или вы реально думаете, что домашние пользователи все побежали делать RAID и
> хранить копии данных в трёх географических разделённых местах?
Если нет, они тогда бегут вооон туда, в лабу по дата рекавери и облегчаются на круглые суммы, после чего те кто поумнее обычно начинают делать бэкапы, уважать райды и вообще.
> 1) Все данные - это безумно важно!
> 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае
> атомной зимы!
А прелесть btrfs как раз в том что можно заметно улучшить свойства, используя то что есть, без безумных затрат или энтерпрайзных требований. А так по жизни вовремя детектить глюки железа это очень полезная идея. Одно дело если я глюкастик в фоне заменю и другое если у меня рабочий проект развалится или глюкастик взбрыкнет в самый ответственный момент, как это по законам мерфи и случается.
> Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно.
В btrfs это все может быть в виде когда этим можно даже простому юзеру пользоваться и не париться. Схему DUP на ноутбучном диске вкатить - 1 команда в командлайне. Зато рандомный бэд раз в эн лет под метаданными прекрасно пережило, парировало и вместо ВНЕЗАПНОЙ переустановки оси в мыле я занимаюсь моими проектиками. Ну а с вашими технологиями я бы вместо этого полдня пыхтел с наруливанием операционки. Что занимает сильно больше времени чем 1 команду btrfs было скроить.
> Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING".
А таки реально - гно. Я встречал довольно много юзеров у которых ВНЕЗАПНО разлетелась файлуха до немоунтабельного состояния (чаще всего NTFS). Резко и без предупреждения. Еще вчера они свои проекты делали. Сегодня винда в бсод улетает при попытке диск прицепитьб и вообще ни 1 файла не достать. А оказывается у них там оперативочка битая, процик глюкавенький, шнурок гнилой, но они узнали об этом только когда наконец какие-то метаданные фатально накрылись и драйвер ушел в страну вечной охоты. Это кстати баг драйвера, но если вам ваш проект было надо, бодаться с сапортом майков на эту тему вам вовсе не с руки. Как и выяснять почему chkdisk это не чинит. Врядли у вас есть полгода с сапортом майков переписываться, поэтому зачастую народ юзает альтернативные планы. Так я и узнал что это бывает. Потому что внезапно, я могу и с таким подарком справиться.
> *ля. Ржу. Корона не жмёт?
Пока вы тупили, штуки типа btrfs сделали продвинутые фичи довольно доступными и ненапряжными. Представляете, в конце XIX века поездку на авто приходилось готовить почти как экспедицию. А в XXI веке мы просто плюхаемся в кресло и поехали. Хотя действо то же самое. И да т.к. отсутствие чексум ведет к резким развалам без предупреждения, это реально хреново. Так что имхо у того субъкта есть пойнт. Но да, я тоже испорчен btrfs. Зато, вот, мою коллекцию глюкастиков пополнил. Несколько флех, sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый проц... нормальненько так :) можно вам из этого комп свинтить, а вы и не заметите так сразу :P.

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

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

Сообщение от onanim (?), 04-Июн-23, 08:45

> Несколько флех,
> sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый
> проц...
мне китайский переходник SATA-USB наделал в ссд кучу Uncorrectable ошибок и даже один Reallocated, и дико тормозило чтение-запись. я думал, что диск помирает, пока не попробовал другой переходник.

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

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

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

Именно поэтому Гугль потихоньку переводит Андроид на f2fs для RW (хотя тут неточно) и EROFS для RO (вот тут уже решение принято).

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

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

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

> Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.
Математика не нужна. Миллионы школьников не могут ошибаться.

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

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

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

При форматировании флешки или внешнего HDD в NTFS проблемы с потерями данных я встречал намного чаще, чем при форматировании их в ext4. Само собой, почти все проблемы возникали после выдергивания на горячую. И если на NTFS умирали целые директории, то на ext4 - лишь записанные непосредствено перед выдергиванием файлы.
Когда в мае 2005 года в ряде ЦОД сервера аварийно отрубали во избежании перегрева (в тот день было жарко и солнечно), ext3 проблем при включении серверов не доставляло, чего не скажешь об NTFS.
xfs - для десктопа или ноута не лучший выбор. А вот для дисков многотерабайтной БД - самое то. Особенно если эта БД сама контрольные суммы страниц считает.
ext4 - наборот, когда не нужны многотерабайтные диски для БД.
btrfs - претендует на универсальность, но, на практике, проигрывает в производительности xfs, если диск используется для БД. Проверяли на PostgreSQL с выключенным CoW. С включенным - вообще молчу.
zfs - навороченный комбайн. Но на практике то нужна производительность и надежность, а не 100500 фич.

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

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

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

NTFS игрушечная ФС.

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

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

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

NTFS просто старенькая и глючная, слишком много напихали поэтому регулярно находятся 1000 способов её развалить. Адово фрагментируется и деградирует, плоховато скалируется, например, видно, когда используешь какой-нибудь msys2 и линуксовый софт в нём, эта куча мелких файлов весьма плохо работает по сравнению с линуксом. Да и вообще адок с вендософтом тоже, особенно, как туда моно с метро запихали. Отключаешь суперфетч и наслаждаешься. Поэтому, файлы приложения должны быть упакованы в большие архивы и подгружаться стримингом ресурсов, а не лежать на диске. Но, в целом, использовать можно, просто не серверная ФС. А игрушечная ФС, это у Эпла. SSD конечно многие проблемы нивелирует в значительной мере.

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

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

Сообщение от birdie (ok), 28-Май-23, 13:01

Практически всё в этом ответе - наглая ложь, и непонимание работы: "куча мелких файлов весьма плохо работает".
По поводу: "1000 способов её развалит" - дикая ложь. Ради прикола во время распаковки тысяч мелких файлов делал reset 15 раз подряд, ни разу не делая chkdsk - забавно, но всё работало.
Единственное в тему - это фрагментация, но это перестало быть важным во времена SSD.

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

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

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

Хорошо, давай вместо твоего пустословия я приведу самый надёжный способ её уничтожить, который работал на протяжении многих лет. Включаешь сжатие какого-нибудь бесполезного каталога вроде Windows/Fonts и ещё лучше квоты, после чего забиваешь место на системном разделе в ноль, нтфс приплыла (да, я знаю, что _сейчас_ нормально реагирует, но из года в год это самая частая причина для утраты данных). Ситуация, благодаря сомнительным апдейтам, не такая уж фантастическая. По поводу "распаковки тысяч мелких файлов" вообще не понятно, к чему упомянуто, я разве где-то говорил что она от этого рассыпется? Доступ к файлам тормозит из-за кучи абстракций и мелкие файлы тормозят особенно ощутимо.

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

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

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

> Хорошо, давай вместо твоего пустословия я приведу самый надёжный способ её уничтожить,
> который работал на протяжении многих лет. Включаешь сжатие какого-нибудь бесполезного
> каталога вроде Windows/Fonts и ещё лучше квоты, после чего забиваешь место
> на системном разделе в ноль, нтфс приплыла (да, я знаю, что
> _сейчас_ нормально реагирует, но из года в год это самая частая
> причина для утраты данных). Ситуация, благодаря сомнительным апдейтам, не такая уж
> фантастическая. По поводу "распаковки тысяч мелких файлов" вообще не понятно, к
> чему упомянуто, я разве где-то говорил что она от этого рассыпется?
> Доступ к файлам тормозит из-за кучи абстракций и мелкие файлы тормозят
> особенно ощутимо.
VirtualBox поставить и записать видео - делов на полчаса. Увы, не верю ни слову, пока не увижу видео доказательства. Желательно на свежей версии Win10/11, которые скачиваются за 10 минут с оф сайта: https://www.microsoft.com/software-download/windows10
Test case вымученный до ужаса: сжатие + нулевое свободное место, надо признать. Случается примерно у одного человека из миллиарда.
Большинство Linux FS не поддерживают сжатие вообще, в такой ситуации и ваши хвалёные ZFS BTRFS встанут колом поди.

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

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

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

Ну нет, тебе надо, ты и экперементируй. Лет 5 назад в очередной раз пофиксили. Ещё с шифрованием можно поиграться. Она выполняет недопустимые фоновые операции над метаданными, для которых ресурсов нет, и от это всё разлетается. Я чёт сомневаюсь, что линуксовые ФС будут иметь такую логику, разносящую суперблок, или выполнять подобные операции. А на виртуалке не обязательно прокатит, в них логика работы с данными всё же отличается от реального железа (хотя именно это -- вполне вероятно).
Учитывая, что winsxs в венде всегда разрастался на сотни гигабайт, занимая системный раздел любого объёма, а очередной драйвер звуковой карты после обновления установит десятки гигабайт веб-серверов на все порты и забудет ещё сотню гигабайт временных файлов на системном диске (и это ещё студию и офисы устанавливать не начали), то тут ничего необычного как раз. Система дельта-обновленений венды тоже иногда интересно работает, устанавливая новую ОС вместо кучи старых пакетов.

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

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

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

>[оверквотинг удален]
> разносящую суперблок, или выполнять подобные операции. А на виртуалке не обязательно
> прокатит, в них логика работы с данными всё же отличается от
> реального железа (хотя именно это -- вполне вероятно).
> Учитывая, что winsxs в венде всегда разрастался на сотни гигабайт, занимая системный
> раздел любого объёма, а очередной драйвер звуковой карты после обновления установит
> десятки гигабайт веб-серверов на все порты и забудет ещё сотню гигабайт
> временных файлов на системном диске (и это ещё студию и офисы
> устанавливать не начали), то тут ничего необычного как раз. Система дельта-обновленений
> венды тоже иногда интересно работает, устанавливая новую ОС вместо кучи старых
> пакетов.
Вы сделали громкое заявление о кривизне NTFS. The burden of proof лежит на Вас, уважаемый.
Пожалуйста, не увиливайте. Инструменты у Вас есть. Примерно час на то, чтобы продемонстрировать бесконечный поток пока что голословных обвинений.

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

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

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

> xfs - для десктопа или ноута не лучший выбор.
ну почему-же. Если хозяин балуется монтажом видео, например, то наилучший. Да и вообще, почти всегда прекрасный выбор.
Другое дело, что в последнее время стала вытесняться btrfs, несмотря на падение производительности -- снэпшоты и лёгкость бэкапа часто перевешивают.
> btrfs - претендует на универсальность, но, на практике, проигрывает в производительности xfs,
это обратная сторона универсальности. с другой стороны, btrfs-ные снэпшоты, это очень сладко, в случае БД тоже.

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

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

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

> Если хозяин балуется монтажом видео
В этом случае различия между xfs и ext4 он просто не заметит.
> btrfs-ные снэпшоты, это очень сладко, в случае БД тоже
Зачем они тому же PostgreSQL, который и так на снапшотах живет? В лом pg_export_snapshot/SET TRANSACTION SNAPSHOT использовать, когда это надо?
Это даже не считая того, что снапшот на уровне БД и на уровне ФС - очень разные вещи. В БД, до фиксации транзакции, модифицированные страницы могут быть только в оперативке. А снапшот на уровне файловой системы, если WAL и tablespace на разных дисках, как рекомендуется, - вообще бессмыслен.

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

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

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

>>Если хозяин балуется монтажом видео
>В этом случае различия между xfs и ext4 он просто не заметит.
проверено -- заметит. особенно, если паралелльно сборки проекта не ждать и плевать в потолок, а заниматься другой полезной деятельностью.
> Это даже не считая того, что снапшот на уровне БД и на уровне ФС - очень разные вещи.
это всё совершенно очевидно, но иногда нужно быстро получить полную копию базы, которая в дальнейшем будет жить своей жизнью. И btrfs'ные снапшоты тут очень вкусное решение, даже если и на разных дисках (при остановке базы, конечно).

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

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

Сообщение от ptr (??), 27-Май-23, 13:29

> при остановке базы, конечно
Понял. Мы с разных планет. На моей, остановка БД - чрезвычайное событие, граничащее с катастрофой. А плановые остановки для обновления СУБД планируются исключительно на ночь перед длинными выходными.

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

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

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

> На моей, остановка БД - чрезвычайное событие
это тоже понятно. но когда остановка -- снэпшот -- перезапуск посгресса занимает, примерно, 15 сек и юзер даже не отваливается, почему бы нет?
конечно, у меня задачи совсем ласковые и игрушечные, на остановку и на 15 минут ругани почти не будет.

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

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

Сообщение от ptr (??), 27-Май-23, 13:49

А если юзер ждет завершения обучения модели, которое длится уже часов 30? На моей планете, БД без единой активной транзакции - чудо или последствия катастрофы.
> 15 сек
Cнапшот через pg_export_snapshot делается моментально (<1 mc) на активной СУБД.
> юзер даже не отваливается
Расскажите подробней, как Вам удается восстанавливать открытые клиентом курсоры при перезапуске СУБД?

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

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

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

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

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

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

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

> Расскажите подробней, как Вам удается восстанавливать открытые клиентом курсоры при перезапуске СУБД?
никак :)
и тем не менее, технология имеет право на жизнь в своих граничных условиях.

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

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

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

Если хозяин балуется монтажем видео ему надо в сторону SSD смотреть, может даже f2fs пощупать...(осторожно правда).

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

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

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

спасибо, кэп.
но вот у мне, например, в голову не придёт покупать ссд большого объёма под эти задачи: монтаж для дома и семьи в жизни не окупится.
и кстати, на "моих" ссд -- xfs и btrfs, смысла в камасутре с f2fs как-то не вижу.

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

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

Сообщение от Kuromi (ok), 28-Май-23, 17:06

> спасибо, кэп.
> но вот у мне, например, в голову не придёт покупать ссд большого
> объёма под эти задачи: монтаж для дома и семьи в жизни
> не окупится.
> и кстати, на "моих" ссд -- xfs и btrfs, смысла в камасутре
> с f2fs как-то не вижу.
Ну на самом деле обычно всякие "топовые" NVME с 3-7 гигабайта в секунду записи (и SLC mode на треть накопителя, чтобы из кэша не вылететь) под штуки вроде видеомонтажа и покупают, ибо иначе смысла в таких линейных скоростях просто нет (ну читаете вы гигабайтный файл не треть секунды, а одну седьмую, разница уже незаметна). Так что сам дохтур прописал.
Что же до f2fs, то я вот сколько лет пользую (успешно), столько наблюдаю странно предвзятое отношение к ней, одна половина говорит "нестабильно", другая "ненужно". Мол, зачем нам ФС с оптимизацией под Flash\SSD если SSD прекрасно сами выравнивают износ, значит ненужно, хотя оптимизации f2fs никак НЕ УВЕЛИЧИВАЮТ износ, так что неясно почему тогда условная ext4 не "не нужно".
При этом багфиксы и новые фичи f2fs прилетают в ядро регулярно, развитие есть(+шифрование +сжатие +атомарные операции, даже объединение нескольких устройств в одну ФС завезли), а производительность - отличная. Но нет, оно "ненужно", зато целых три новые SSD-friendly файловые системы - bcachefs, NOVA и SSDFS, на подходе. Вот они точно будут "нужно", наверное.

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

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

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

У f2fs была проблема с GRUB. Если создать ФС с опцией -O extra_attr, загрузчик не может её читать. То есть надо создавать отдельный раздел под boot. А это может быть не каждому эксперту под силу, что и объясняет недовольство.

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

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

Сообщение от Kuromi (ok), 30-Май-23, 15:48

> У f2fs была проблема с GRUB. Если создать ФС с опцией -O
> extra_attr, загрузчик не может её читать. То есть надо создавать отдельный
> раздел под boot. А это может быть не каждому эксперту под
> силу, что и объясняет недовольство.
Есть такая проблема, да.

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

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

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

> У f2fs была проблема с GRUB. Если создать ФС с опцией
Такие проблемы бывают с много чем. С btrfs или zfs на это тоже можно нарваться. Загрузчик использует минимальную облегченную реализацию и то что она ВСЕ фичи - особенно новые - особенно в не очень свежей версии загрузчика рюхает - совсем не факт. Да даже наверное с EXT4 выпендриться можно - врядли grub умеет в fscrypt какой.
Скажем, если с старым grub поюзать zstd сжатие на btrfs, он честно скажет "unknown compression" при попытке читать кернел/инитрд/что там еще. Что логично, старая версия просто не знала про такое сжатие. Но можно и не жать кернел zstd. На btrfs могут сосуществовать файлы жатые разными сжатиями и никто не обязывает жать кернел именно zstd.
В лично моем случае я натыкался на куда более жирные прецеденты с f2fs - плохо к перезагрузкам и слетам питания относится, вплоть до полной кончины. В моих конфигах он вообще оказался одним из самых хлипких по этому аспекту.
И так то если кто думает что это только там бывает - а вон NTFS, в современных диалектах кучу алгоритмов сжатия приделали. Старая реализация загрузчика или кого там опять же их не прожует. А может и актуальная. Полный NTFS3 конечно их рюхает. Если воооон там в конфиге кернела это включть еще специально. Как и fuse. Надеюсь это объясняет почему появился kexec(). Если кто хотел странного и продвинутого, кернел, так то, тоже бутлоадер. Крутой и мощный. С полными реализациями. Которые несколько проще до актуальных версий подтягивать.

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

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

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

> Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,  которая просто работает?
> Как например NTFS?
Ну я пользуюсь, просто работает, брат жив.
Но обратите внимание, нюанс: ntfs-3g
Если тебе линейный доступ к средних размеров файлам и все больше по чтению - и больше ничего вообще не надо, ни сложных прав доступа, ни EA, ни, Б-же упаси, виндовых штук - просто работает, да.
Нормальные еще разработчики писали, а в силу изоляции от стабильного нонсенса - не смогли поломать.

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

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

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

> Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо.
...
>  которая просто работает? Как например NTFS?
Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных. Да так что не монтируется и не чинится chkdisk'ом иной раз. В силу природы ФС это еще и без предупреждений зачастую. Т.е. все выглядело ЗБС - а сегодня оно не маунтится или драйвер в бсод летает.
Но если что в линух завезли ядерный полноценный драйвер этсамого, так что кто NTFS хотел может его и юзать. Хоть я и не понимаю прелести в тормозной файлухе из 90х которая требует условный "fsck" и не демонстрирует вообще совсем ничего выдающегося.

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

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

Сообщение от Kuromi (ok), 30-Май-23, 16:42

>[оверквотинг удален]
>>  которая просто работает? Как например NTFS?
> Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных.
> Да так что не монтируется и не чинится chkdisk'ом иной раз.
> В силу природы ФС это еще и без предупреждений зачастую. Т.е.
> все выглядело ЗБС - а сегодня оно не маунтится или драйвер
> в бсод летает.
> Но если что в линух завезли ядерный полноценный драйвер этсамого, так что
> кто NTFS хотел может его и юзать. Хоть я и не
> понимаю прелести в тормозной файлухе из 90х которая требует условный "fsck"
> и не демонстрирует вообще совсем ничего выдающегося.
NTFS конечно ФС старая и на сегодняшний день не предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть), хотя на момент своего создания это был прогресс.
Однако тот факт что разрабы BTRFS не осилили сделать нормальный btrfs.fsck не значит что это норма...

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

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

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

>предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть)
Экстенты ??? Откуда HTFS взяться экстентам,будь они там она не была такой тормозной,но теряла бы файлы гораздо чаще, мда...Она как и фат (почему конвертация возможна) использует кластеры и карту свободного пространства.Кластер это что то типа инода  в юних спецификации.Может не совпадать по размерам с сектором жесткого диска.Есть фича фс -может пространство заполненное нулями упаковывать.

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

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

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

>>предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть)
> Экстенты ??? Откуда HTFS взяться экстентам,будь они там она не была такой
> тормозной,но теряла бы файлы гораздо чаще, мда...Она как и фат (почему
> конвертация возможна) использует кластеры и карту свободного пространства.Кластер это
> что то типа инода  в юних спецификации.Может не совпадать по
> размерам с сектором жесткого диска.Есть фича фс -может пространство заполненное нулями
> упаковывать.
Чтож, закапываться в спеки лень, но условная Википедия (да простят меня боги) уверена что экстенты в NTFS есть.
С другой стороны та же Википедия не знает что у F2FS есть поддержка нескольких устройств, так что...
Кстати конвертация из FAT ни о чем не говорит. EXT3 прекрасно конвертируется в EXT4, вот только старые файлы остаются битмаповыми (не-экстентами) до тех пор пока их не перезапишешь или явно не сделаешь chattr -e файлу.

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

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

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

В журнале Системный администратор приводилась статья по устройству ntfs, достаточно подробная.Не слова об экстентах.А проблема фрагментации ? При использовании экстентов и карты свободного места -файл писался бы крупным куском.Если только сейчас не добавили в виндовс  10-11.Кстати в русской версии вики тоже не слова об экстентах.На странице http://www.vsokovikov.narod.ru/New_MSDN_API/File_system/ntfs... тоже насчёт экстентов помалкивают,упоминают только что может выделять непрерывную область,но логически все равно это блок кластеров.

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

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

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

У них вроде изначально свободное место битмапом аллокации маркировалось и потом для совместимости они так и таскали это как я понимаю. Это ж делалось в лохматые 90х.
И даже если потом какие-то индексы для более быстрых операций навесить, это не отменит нужды жевать битмап как минимум при записях, если он все еще есть. Совсем его удалить они врядли смогут или захотят т.к. совместимость. А в битмапе метить занятые большие регионы ой как не быстро. У экстентов есть свои дурацкие стороны, но в целом это обычно работает лучше.

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

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

Сообщение от maximnik0 (?), 05-Июн-23, 22:20

> У них вроде изначально свободное место битмапом аллокации маркировалось и потом для
> совместимости они так и таскали это как я понимаю. Это ж
> делалось в лохматые 90х.
Ну и получается объединенная группа кластеров - это не экстент.В лучшем случае экстент имеет всего лишь 2 записи (основном и резервном) блоке (метаданные или таблица (дерево) размещение файлов) -с указанием это начало файла а это конец . Единый файл -да,быстро работает да,легко потерять -тоже да,чем и страдали XFS и райзер. Вот COW и добавила надежность для экстентов,но плата фрагментация,в самом худшем случае  таблица экстентов приближаеться к карте битманов......

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

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

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

> Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных.
> Да так что не монтируется и не чинится chkdisk'ом иной раз.
> В силу природы ФС это еще и без предупреждений зачастую.
Зато инструментов для вытаскивания данных до хрена и больше,а если еще и образ был MFT так в 80% починишь.С нее реально если сжатие не включено хорошо инфа вытаскиваеться,а бсод это вин проблемы.(Было уже - на 7-10 обнаружена проблема с альтернативными потоками проблема-определенное название файла,бсод,диск поврежден,правда в 90% случаев исправлялась ошибка). В 50% где не работало под виндовс-  монтировалось под дос или linux.А придупреждения есть - но кто будет заглядывать в администрирование,просмотр событий .А в журнале есть частенько сообщения о проблемах с бад блоками,MFC (используеться копия) или бад миссинг с непонятными номерами -источник сообщения драйвер ntfs//

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

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

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

Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка и папка это одна директория, открывающие случайные данные? Это та фс, где нет нормальных симлинков? Которая поддерживается примерно нигде (несколько кривых версий в винде, несколько кривых версий в линухе)? Эта та самая одна из медлительнейших ФС? Ну если она просто работает, то любая из ФС покажется вам вершиной технологий.

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

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

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

> Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка
> и папка это одна директория, открывающие случайные данные? Это та фс,
> где нет нормальных симлинков? Которая поддерживается примерно нигде
Сейчас с 64 мгб кэша на жестких любая фс при резком выключение может сказать -да ну его на "буй". Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.И симлинки и хардлинки данная фс поддерживает,софт не поддерживал,вот в этом беда.Даже больше скажу-ее можно было (хр,виста) под виндой монтировать если вы не знали.Да да,монтировать,а не буквой обозначать (кроме диска с). И не особо она медлительная-замечательно тюненгуеться,если стальные яйца можно даже журнал отключить.А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.

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

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

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

> Сейчас с 64 мгб кэша на жестких любая фс при резком выключение
> может сказать -да ну его на "буй".
Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи. И только после этого файлуха маркирует вон то как записаное а до этого оно считается "in flight" и на это нельзя уповать для критичных нужд.
Более того - в RAM хоста еще и не такой буфер и при слете питания или внезапном ребуте ТАМ пролюбится еще и не столько. Если fsync не делать, например. Самое интересное что даже чисто апликушный софт не может игнорить этот аспект под страхом мощной потери данных. Поэтому есть характерная семантика, а девайсы должны следовать определенным требованиям в реализации кеширования. Иначе файлухи имеют полное право неконтролируемо развалиться. На слет произвольных 64 мегов в любом месте никто корректно не реагирует. Если вы потеряете большой кус допустим метаданных - это достаточно критично.
> Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.
Это происходит потому что файлуха не журналила данные файла, инфо для undo/redo хватало только на метаданные и консистентность вида ФС в лучшем случае, а что там стало с файлом внутри - это очень отдельный вопрос. Потому и битый. Не будет произвольно взятая программа жрать наполовину старый, наполовину новый файл. А у виндовых ФС как я понимаю и оглавление диры иногда может пострадать, так что часть файлов оказывается как бы на месте, но как бы безымянными - потому что их дира разнесена вдрызг тем разлетом. Так что фс знает что аллокации есть но не знает как это называлось и где лежало, например.
> И симлинки и хардлинки данная фс поддерживает, софт не поддерживал, вот в этом беда.
От софта по логике вещей никакой особой поддержки и не надо в простых случаях.
> буквой обозначать (кроме диска с).
А у ядра NT унутрях вообще сильно другие пути так-то. Но вот совместимость...
> И не особо она медлительная-замечательно тюненгуеться,
Не выдерживает никакого сравнения с современными файлухами. Скиньте 50K-100К файлов в диру, ребутанитесь чтобы кеш очистить. А теперь попробуйте в эту диру на холодненькую зайти. И как вам времена чтения оглавления такой диры, хоть в какой проге?! Не нравится эксплорер, можно фар, или что там еще - на результат не влияет.
А теперь то же самое в линухе с какойнить иной фс. Ну там btrfs, ext4, etc. Почему там времена сильно более культурные? И тот же миднайт за весьма обозримое время это отрисовывает вот.
> если стальные яйца можно даже журнал отключить.
Никак не поможет при чтении списка 50К файлов на холодную. Вот и потюниговали :)
> А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.
Под линь сейчас NTFS3 есть. Это как раз бывший коммерческий драйвер парагона как я понимаю. Ну а что, похвально, все бы так.

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

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

Сообщение от maximnik0 (?), 05-Июн-23, 22:02

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

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

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

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

> То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать
> (1,5 года назад). Есть команды но нет гарантии
Да, вы знаете, фирмвары у девайсов бывают забагованые и кривые. Но это баг и нарушение спеков стандарта - и в этом случае предъявлять что либо ядру, фс и проч не айс. Если кто купил глюкало, пусть его MFRу и пеняет.
В кернеле воркэраундят популярные глюки, конечно, если это возможно, по мере возможности - потому что работать приходится в идеальном мире, в том числе и на откровенно гунявом железе с индусскими фирмварами. Они вон даже спектры у процов заворкэраундили.
Но тут стоит понимать что воркэраунд в ядре - не решает проблему нарушения девайсом семантики на которую файлухи закладывались. Практически все ФС при журналинге и проч уповают на то что вон те операции с сбросом кеша - работают. Если это не так, крахи и слет питания ведут к UNDEFINE с практически любой ФС. Что там дальше будет - да что угодно в принципе. Это факап за пределами допущений ФС. Против лома нет приема.
> что эти команды выполнены- очень разработчики ext4 с этим мучились, особенно на ноутбучных
> винтах был этот гемморой. Сейчас просто производителей жестких -на пальцах можно
> посчитать, но все равно глюки случаются,особенно с флэш дисками ,
Более того - такие приколы и у SD-card были. Нокия в свое время агресивно снимала питание с карт после команды шатдауна, как по спекам писано. И тут оказалось что как минимум Transcend спекам не соответствует и - отлично разлетается если так делать. И пришлось им ажно слать патчи в mmc подсистему ядра.
> а про аппаратное стирание на флэшках и говорить нечего.
Там максимальное время операций трекается машиной состояний и больше чем в спеках не будет, как максимум erase/program error в статусе чипа будет. Но пока до этого всего дойдет, там еще чертова куча кода фирмвары писаной хзкем. И у нее могли быть какие-то сильно свои идеи. Как показал пример допустим самса с EVO, иногда эти идеи бывают странные и они вот например TRIM нормално не смогли в некоторых девайсах, да так что девайс чуть не харакири себе делает с определенными сочетаниями запросов. Пришлось и это воркэраундить, заведя список гамняшек, с точностью до девайса и версии FW, их quirks, и явно избегать проблемные операции для таких.
У особо голимых флешастых устройств может FTL вообще в такой ситуации развалиться - и тут вообще ничего вы не сделаете, там вместо данных их нарезка на полосочки из стоража идет. Это уже только специализированая лаба смогет прочитать вообще.
И все же, по спекам так быть не должно. И ФС пишутся все же с опорой на эти спеки. Потому что ВСЕ мыслимые глюки ВСЕХ девайсов учесть на фазе дизайна не получится. А дальше уж пытаться воркэраундить в меру талантов. И вот тут оно может прокатить а может и нет. Разумеется новый дизайн на этапе проектирования может пытаться учесть траблы предшественников, но на 100% это нереально.

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

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

Сообщение от maximnik0 (?), 06-Июн-23, 13:45

>Против лома нет приема.
Не знаю как в 10,не пробывал,а в старых версиях офтопика в настройках управления накопителя была опция запрета использования дискового кэша для записи. Там еще можно было другие алгоритмы кэширования сменить.Правда на скорости под офтопик это сказывается ощутимо, может из-за этого ходят байки о слишком сильной тормознутостьи ntfs, потому что драйвера (иногда биос) ряд чипов обнаружив ошибки записи принудительно отключали кэш на запись,и в некоторых случаях DMA доступ.(я знаю что с мелкими файлами в одном каталоге ext поведет себя гораздо лучше,но все равно если кэш пуст и она тупить будет).В linux тоже у hdparm была опция для отключения кэша диска для записи, так что не все так фатально.

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

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

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

> Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка
> и папка это одна директория, открывающие случайные данные?
Вы путаете ФС и ОС. В NTFS это разные директории. В NTFS даже 0 (байт значения 0) может быть в середине имени.

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

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

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

> Вы путаете ФС и ОС. В NTFS это разные директории. В NTFS
> даже 0 (байт значения 0) может быть в середине имени.
Зато удачи там создать файл с именем "С:\CON", как минимум через WinAPI. А в линухе это валидное имя файла. И что-то мне кажется что 0x0 в человекочитаемых вещах встречается сильно реже чем ":" или "\" например.
И тут еще можно поспорить насколько все это именно фичи. Ничерта не подозревающий софт будет довольно интересно реагировать что на C:\ что на 0x0, 0xd, 0xa, "|" и все такое прочее. Можно даже пробовать атаки в архивах, скажем файло "C:\WINDOWS\TROLOLO.DLL" - это всего лишь файл. В топе иерархии. Если в терминах *никса. Зато если его попробовать втрамбовать на винде "как есть" может выйти интересно. Аналогично с \..\..\..\..\windows\wtf.dll каким-нибудь. Для линукса вон то тоже валидное имя файла. В топе плоской иерархии. И кстати исторически это юзерам винды икаолсь, через тот же гит допустим.

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

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

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

Партнёры:

Хостинг:

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

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

64. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+6 +/–
Сообщение от beck (??), 27-Май-23, 10:31
Прочитал обсуждение. Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо. Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то, и другое. Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система, которая просто работает? Как например NTFS?
Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+4 +/–
	Сообщение от Аноним (73), 27-Май-23, 11:06
	> Прочитал обсуждение. > Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо. > Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то, > и другое. > Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система, > которая просто работает? Как например NTFS? Да, EXT4 стабильнее всех работает, а те кто про неё пишут гадости, подсосы бутерфс от красношляпы либо просто полезные идиоты, либо на зряплате. А ты вообще жирный MS-тролль, так-то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:09
	>подсосы бутерфс от красношляпы Сосайтник, бутерфс от оракла.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	81. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:08
	>Как например NTFS? Вот это рили дерьмо. >а под линукс есть хоть одна нормальная файловая система Конечно есть - Btrfs.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	410. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 04-Июн-23, 01:04
	> Вот это рили дерьмо. Подтверждаю - рекаверил убиты в хлам нтфсы юзерам у которых все прекрасно работало до момента когда ВНЕЗАПНО развалилось вдрызг и перестало маунтиться. В основном это из-за сбойной оперативы. Но чексуммы и такое хайлайтят, потому что в таком случае несовпадения периодически лезут и это заметно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от n00by (ok), 27-Май-23, 11:10
	На zfs не каждый местный эксперт сможет установить систему, так что это их экспертное мнение скопировано у других таких же экспертов. Вероятно, в случае остальных ФС экспертиза проводится точно так же.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	86. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Читатель сайта (?), 27-Май-23, 11:15
	Сейчас придут и расскажут и почему NTFS тоже дерьмо. :) А IMHO - вся беда в том, что серебряной пули так и не сделали. Каждая из этих FS хороша для употребления в своих условиях. Но это ж думать надо...
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	102. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:52
	> etx4 - дерьмо Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. Более надёжной ФС в Линукс нет и не было. Самый большой косяк - не умеет делать дефрагментацию свободного места, но с приходом SSD проблема перестала быть актуальной. Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	105. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от DEF (?), 27-Май-23, 11:58
	>Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. И чо? У одного только Фейсбука, btrfs юзается в хвост и в гриву на более миллиона серверов. >Более надёжной ФС в Линукс нет и не было. Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори. >Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux. Укатайка...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	114. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 12:39
	> Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори. Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum. Проблема не настолько серьёзная, чтобы говорить, что без этого ФС не ФС. Я бы назвал data checksum nice to have фичей, но никак не crucial/essential.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	124. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от DEF (?), 27-Май-23, 13:45
	>Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum. Это не решения, а днищенские костыли. Гарантия целостности данных должна обеспечиваться на уровне ФС.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	126. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 13:58
	> Это не решения, а днищенские костыли. Кто это решил? Я использую файлы с checksums более 20 лет. Проблем не было. Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). Приехали? Я скажу ещё более страшную вешь - checksumming без recovery бесполезен буквально полностью. Всё, отдыхайте. А вот тут решений на уровне FS я не знаю вообще. Есть PAR2, но это бесконечный геморрой, который я заменил на RAR. > должна обеспечиваться на уровне ФС Кто кому должен? Почему должен? Я сейчас скажу, что вы мне должны $1M, потому что так "правильно". Всё? Приехали? Не надо свои хотелки превращать в status quo.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	201. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 28-Май-23, 00:20
	> Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. > Чем вам это поможет? копий данных на современных fs может быть, внезапно, не одна. И даже носителей тоже может быть не один. > FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). когда кажется - помогает креститься. zfs (как и любая другая с контролем целостности) ничего не выдаст, вернет ошибку чтения, если не имеет второй копии. И ты хотя бы узнаешь что файл поврежден (возможно копии нет у fs, а ты был умный и у тебя она есть где-то еще). Если копия есть и валидна - молча вернется правильный блок, а битый при scrub будет перезаписан, без необходимости тебе лично участвовать в этом процессе. Раз ты даже этого не знаешь - чего стоит твоя "экспертиза"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	219. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–3 +/–
	Сообщение от Sw00p aka Jerom (?), 28-Май-23, 10:34
	>копий данных на современных fs может быть, внезапно, не одна. И какой копии доверять? Как доказать целостность? Где гарантии, что копии целые? Человек до сих пор не придумал этого механизма.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	280. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Прохожий (??), 29-Май-23, 11:01
	Тебе ж написали:контрольные суммы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	282. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 29-Май-23, 11:36
	> Тебе ж написали:контрольные суммы. а где храним эти контрольные суммы? и в каком количестве?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	400. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (400), 03-Июн-23, 19:38
	> а где храним эти контрольные суммы? и в каком количестве? Ну вот в файлухе например можно, если это не блочный а "файловый" дизайн был. В количестве копий блока разумеется - если это нечто типа RAID1. А что, чексуммы мало места vs блок занимают, оверхеда не так уж много, ценой очень скромного оверхеда знаем какая копия верная и возможности (авто)рекавери сильно возрастают. Для штук типа RAID5 парити для блоков чексум можно и не хранить по математическим причинам, для блоков данных ессно чексумы надо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	404. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Июн-23, 21:26
	> знаем какая копия верная откуда знаем? как понять чек-сумма битая или блок данных? разве не на том же устройстве они хранятся? кто дает гарантии "небитости" чек-сумм?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	411. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (411), 04-Июн-23, 01:15
	> откуда знаем? как понять чек-сумма битая или блок данных? ИМХО пофиг: если не совпадает -> проблемная копия, просто берем из другой. И какая разница чексум в копии порушился или сам блок? Если у нас исправная копия есть, мы как раз и отрекаверим и блок и его чексум. Эта логика на имеющихся у меня текучках и сыпучках работает изумительно, круто разворачивая теорвер в совсем другую сторону. Теперь даже на 1 неидеальном девайсе я проигрываю не "когда бэд попал под что-то важное" а "когда бэды совпали так что накрыло обе копии". И выиграть в такой джекпот при относительно редких сбоях и относительно большом числе секторов не очень реально за обозримое время. ИМХО так теорвер намного прикольнее ощущается. А всего лишь критерии проигрыша немного пересмотрели. > разве не на том же устройстве они хранятся? Вот как раз и пофиг, чексумы отъехали или блок, отрекаверить из исправной версии и дело с концом. > кто дает гарантии "небитости" чек-сумм? Стопроцентные конечно только страховой полис. Но если у вас глючное железо, на фс с чексумами это как раз очень хорошо видно когда расчитаное при записи не сходится с расчитаным при чтении, так что идут матюки фс в логи - и мы знаем что железо гунявое. У меня так целая мини коллекция глюкастиков образовалась, там и флехи, и карточки, и ссд, и мамка и проц и рама и даже шнурки сата :). Шнурки кстати в смарте видно но это ж надо явно лезть туда, а тут вот готовые матюки в логах...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	202. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 28-Май-23, 00:52
	>Кто это решил? Это решили логика и здравый смысл. >Я использую файлы с checksums более 20 лет. Проблем не было. Никого не интересует твой опыт использования костылей. >Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? Я запущу scrub. Если у меня зеркальный RAID, то Btrfs автоматически восстановит поврежденные данные и метаданные из уцелевшей копии. Если у меня сингл, то ФС как минимум сообщит мне, какие блоки поврежденны и на каких файлах. И я как минимум не допущу попадания битых файлов в новый бэкап и восстановлю их из старого бэкапа. >Кто кому должен? Почему должен? За целостность данных в реляционной БД отвечает именно БД, а не какие-то костыли за пределами БД. Точно также и с ФС. ФС для этого и создана, чтобы обеспечивать целостность данных. Это ее прямая зона ответственности.
	Ответить \| Правка \| К родителю #126 \| Наверх \| Cообщить модератору


	223. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от birdie (ok), 28-Май-23, 12:56
	ля, стыдно всё это читать. Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums? Или вы реально думаете, что домашние пользователи все побежали делать RAID и хранить копии данных в трёх географических разделённых местах? У вас гвно в голове, уважаемый - вы считаете априори, что 1) Все данные - это безумно важно! 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае атомной зимы! Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно. Вы так бы и начали: "вот я работаю там и там, у нас такие критерии, нам только ZFS подходит". Вместо этого: "ВСЕ ФС ГВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING". ля. Ржу. Корона не жмёт?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	237. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от dasd (?), 28-Май-23, 17:34
	>Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums? Начните уже думать, а не только троллить. RAID защищает немножко от другого. Куча копий данных - как выбрать верную? (Битовые ошибки - существуют)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	317. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 30-Май-23, 17:10
	Мда. С тобой все ясно. Таблетки не забывай принимать вовремя, которые тебе назначил твой лечащий психиатр.
	Ответить \| Правка \| К родителю #223 \| Наверх \| Cообщить модератору


	401. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 19:53
	> Если у вас есть RAID, куча копий данных, да на кой хрен > вам вообще checksums? А откуда мы знаем которая из копий на райде правильная когда на отличия налетели? Ну вот для этого чексумы и надо :). Кроме того чексумы проверяют работу железа end to end. И если сбойное железо не отлавливать - оно и кучу копий может прекрасно загадить. Счет и верификация чексум выступают неплохой такой "канарейкой" сильно демаскирующей это все. > Или вы реально думаете, что домашние пользователи все побежали делать RAID и > хранить копии данных в трёх географических разделённых местах? Если нет, они тогда бегут вооон туда, в лабу по дата рекавери и облегчаются на круглые суммы, после чего те кто поумнее обычно начинают делать бэкапы, уважать райды и вообще. > 1) Все данные - это безумно важно! > 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае > атомной зимы! А прелесть btrfs как раз в том что можно заметно улучшить свойства, используя то что есть, без безумных затрат или энтерпрайзных требований. А так по жизни вовремя детектить глюки железа это очень полезная идея. Одно дело если я глюкастик в фоне заменю и другое если у меня рабочий проект развалится или глюкастик взбрыкнет в самый ответственный момент, как это по законам мерфи и случается. > Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно. В btrfs это все может быть в виде когда этим можно даже простому юзеру пользоваться и не париться. Схему DUP на ноутбучном диске вкатить - 1 команда в командлайне. Зато рандомный бэд раз в эн лет под метаданными прекрасно пережило, парировало и вместо ВНЕЗАПНОЙ переустановки оси в мыле я занимаюсь моими проектиками. Ну а с вашими технологиями я бы вместо этого полдня пыхтел с наруливанием операционки. Что занимает сильно больше времени чем 1 команду btrfs было скроить. > Вместо этого: "ВСЕ ФС ГВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING". А таки реально - гно. Я встречал довольно много юзеров у которых ВНЕЗАПНО разлетелась файлуха до немоунтабельного состояния (чаще всего NTFS). Резко и без предупреждения. Еще вчера они свои проекты делали. Сегодня винда в бсод улетает при попытке диск прицепитьб и вообще ни 1 файла не достать. А оказывается у них там оперативочка битая, процик глюкавенький, шнурок гнилой, но они узнали об этом только когда наконец какие-то метаданные фатально накрылись и драйвер ушел в страну вечной охоты. Это кстати баг драйвера, но если вам ваш проект было надо, бодаться с сапортом майков на эту тему вам вовсе не с руки. Как и выяснять почему chkdisk это не чинит. Врядли у вас есть полгода с сапортом майков переписываться, поэтому зачастую народ юзает альтернативные планы. Так я и узнал что это бывает. Потому что внезапно, я могу и с таким подарком справиться. > ля. Ржу. Корона не жмёт? Пока вы тупили, штуки типа btrfs сделали продвинутые фичи довольно доступными и ненапряжными. Представляете, в конце XIX века поездку на авто приходилось готовить почти как экспедицию. А в XXI веке мы просто плюхаемся в кресло и поехали. Хотя действо то же самое. И да т.к. отсутствие чексум ведет к резким развалам без предупреждения, это реально хреново. Так что имхо у того субъкта есть пойнт. Но да, я тоже испорчен btrfs. Зато, вот, мою коллекцию глюкастиков пополнил. Несколько флех, sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый проц... нормальненько так :) можно вам из этого комп свинтить, а вы и не заметите так сразу :P.
	Ответить \| Правка \| К родителю #223 \| Наверх \| Cообщить модератору


	417. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 04-Июн-23, 08:45
	> Несколько флех, > sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый > проц... мне китайский переходник SATA-USB наделал в ссд кучу Uncorrectable ошибок и даже один Reallocated, и дико тормозило чтение-запись. я думал, что диск помирает, пока не попробовал другой переходник.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	191. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Kuromi (ok), 27-Май-23, 23:07
	Именно поэтому Гугль потихоньку переводит Андроид на f2fs для RW (хотя тут неточно) и EROFS для RO (вот тут уже решение принято).
	Ответить \| Правка \| К родителю #102 \| Наверх \| Cообщить модератору


	327. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (324), 31-Май-23, 01:59
	> Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. Математика не нужна. Миллионы школьников не могут ошибаться.
	Ответить \| Правка \| К родителю #102 \| Наверх \| Cообщить модератору


	106. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от ptr (??), 27-Май-23, 12:06
	При форматировании флешки или внешнего HDD в NTFS проблемы с потерями данных я встречал намного чаще, чем при форматировании их в ext4. Само собой, почти все проблемы возникали после выдергивания на горячую. И если на NTFS умирали целые директории, то на ext4 - лишь записанные непосредствено перед выдергиванием файлы. Когда в мае 2005 года в ряде ЦОД сервера аварийно отрубали во избежании перегрева (в тот день было жарко и солнечно), ext3 проблем при включении серверов не доставляло, чего не скажешь об NTFS. xfs - для десктопа или ноута не лучший выбор. А вот для дисков многотерабайтной БД - самое то. Особенно если эта БД сама контрольные суммы страниц считает. ext4 - наборот, когда не нужны многотерабайтные диски для БД. btrfs - претендует на универсальность, но, на практике, проигрывает в производительности xfs, если диск используется для БД. Проверяли на PostgreSQL с выключенным CoW. С включенным - вообще молчу. zfs - навороченный комбайн. Но на практике то нужна производительность и надежность, а не 100500 фич.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	110. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (109), 27-Май-23, 12:33
	NTFS игрушечная ФС.
	Ответить \| Правка \| Наверх \| Cообщить модератору