- Выпуск Debian 9.8, Аноним, 21:27 , 16-Фев-19 (7) –18 [V]
- Выпуск Debian 9.8, Аноним, 21:42 , 16-Фев-19 (11) +10 [^]
- Выпуск Debian 9.8, Аноним, 21:52 , 16-Фев-19 (16) +8 [^]
- Выпуск Debian 9.8, Andrey Mitrofanov, 09:29 , 18-Фев-19 (133)
- Выпуск Debian 9.8, Lexa3110, 11:35 , 18-Фев-19 (142) +2
- Выпуск Debian 9.8, Аноним, 21:30 , 16-Фев-19 (8) +4
- Выпуск Debian 9.8, Аноним, 21:52 , 16-Фев-19 (17) –10 [V]
- Выпуск Debian 9.8, th3m3, 22:02 , 16-Фев-19 (23) +1
- Выпуск Debian 9.8, Аноним, 22:08 , 16-Фев-19 (25) –4 [V]
- Выпуск Debian 9.8, Аноним, 22:36 , 16-Фев-19 (32) –4 [V]
- Выпуск Debian 9.8, zzz, 23:02 , 16-Фев-19 (40) –2
- Выпуск Debian 9.8, Аноним, 00:01 , 17-Фев-19 (49) +4
- Выпуск Debian 9.8, пох, 09:26 , 17-Фев-19 (84)
- Выпуск Debian 9.8, анонн, 21:43 , 17-Фев-19 (118)
> это у которой одна fs "works as intended","Works as intended" вполне документирована - делай бэкапы, отключай "оптимизацию" записи данных на диск (или не бери диски, которые в ответ на sync "врут", что они все записали, хотя на самом деле ... а ведь просто нужно было вовремя и дружно бить маркетологов арматуриной, когда они проталкивали эту пакость, вместо покорного подстраивания и вкорячивания квирксов) или отключай журнал или заимей УПС и будет тебе щастье. Опять же, dump+restore прекрасно работает, в отличие от. К тому, есть некоторые сомнения что чексуммы метаданных в журнале решают эту проблему сильно лучше, т.к. по умолчанию запись и в пингвине вроде как "ordered" (и зависит от этого) плюс журналируются только метаданные. Но целостность метаданных совсем не означает целостность самих данных. Или вы хотели сказать, что лучше (потому что меньше знаешь -- крепче спишь) просто тихо портить данные (типа blq-mq) в любой FS, заодно превращая бэкапы в тыкву?
https://www.opennet.ru/keywords/ext4.html
[05.12.2018] Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, которая приводит к потере данных [23.05.2015] Проблема с повреждением разделов Ext4 оказалась в md-raid0 [20.05.2015] В ядре Linux выявлены ошибки, приводящие к зависанию процессов и повреждению разделов EXT4 [05.04.2013] В Ext4 исправлена ошибка, которая потенциально могла привести к разрушению данных [06.11.2012] Обновление ядра Linux 3.0.51, 3.4.18 и 3.6.6 с устранением нашумевшей проблемы в ext4 [02.11.2012] Выпущен патч для исправления ошибки в ext4, которая могла привести к повреждению ФС [25.10.2012] Появившаяся в ядре Linux 3.6.2 ошибка способна привести к повреждению данных в ФС Ext4
А вот в простой, как валенок, UFS только "works as intended".
- Выпуск Debian 9.8, анонн, 21:45 , 17-Фев-19 (119)
> по умолчанию запись и в пингвине вроде как "ordered" (и зависит от этого) плюс журналируются только метаданные. Уточнение: речь в основном идет о ext4.
- Выпуск Debian 9.8, пох, 22:13 , 17-Фев-19 (120)
- Выпуск Debian 9.8, анонн, 22:50 , 17-Фев-19 (125)
> Так вот, если вы не разобрались в проблеме - суть не в > том что в fs побьются данные, которые только что писались - > они не могут не побиться, и это совершенно нормально, а нормально > спроектированная программа должна это пережить. Суть не в том что побьются > метаданные, хотя journaled, cow, log-store fs изобретены сто лет назад и Я-то может не разобрался, но вот проблема была как раз в системах с gmirror+журнал+unexpected poweroff. Что и упоминалось в ответе: > This is a problem that is endemic to all overwriting filesystems that use journalling. Specifically, the journal only checks and corrects things that it knows need to be fixed. Ну а чексуммы в журнал для метаданных в ext4 добавили конечно же исключительно от нечего делать или же неосиляния "правильной реализации", а не потому что принципиально невозможно сделать быструю журналируованную запись при отсутсвии возможности достоверного синка данных. > при правильной реализации ведут только к потере последнего изменения и то если звезды не сошлись. Ну да, ну да. https://lwn.ext4 experience > Posted Nov 30, 2011 4:52 UTC (Wed) by ringerc (subscriber, #3071) > In reply to: ext4 experience by dskoll > The usual culprit in those sorts of severe corruption or loss cases is aggressive write-back caching without battery backup. Some cheap RAID https://opensource.com/article/18/4/ext4-filesystem
Journal checksummingExt3 did not checksum its journals, which presented problems for disk or controller devices with caches of their own, outside the kernel's direct control. If a controller or a disk with its own cache did writes out of order, it could break ext3's journaling transaction order, potentially corrupting files being written to during (or for some time preceding) a crash. In theory, this problem is resolved by the use of write barriers—when (...) In practice, it's been discovered that storage devices and controllers frequently do not honor write barriers—improving performance (and benchmarks, where they're compared to their competitors) but opening up the possibility of data corruption that should have been prevented.
Я же говорю, что чексуммы просто из любви к искусству добавили. > Суть в том, что в системе произойдет _silent_ corruption, который будет расти, пока не приведет к полному развалу fs. Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае.
- Выпуск Debian 9.8, Алкогол, 14:48 , 18-Фев-19 (150)
- Выпуск Debian 9.8, Алкогол, 15:33 , 18-Фев-19 (151)
- Выпуск Debian 9.8, анонн, 15:53 , 18-Фев-19 (152)
>> Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае. > Не в любом :-) В ошибочном только. Угу, угу. https://queue.acm.org/detail.cfm?id=1866298 > The NetApp study looked at the incidence of silent storage corruption in individual disks in RAID arrays. The data was collected over 41 months from NetApp's filers in the field, covering more than 1.5×106 drives. The study found more than 4×105 silent corruption incidents. > их как-то реализовывать. И как выянилось где-то не совсем реализует :-) Вот именно что при отсутсвии надежного способа делать sync -- "как-то". > Где-то да, из-за прогресса в устройстве дисков. Прогресс этот однако -- инженерный процесс, отнюдь не от маркетологов... Читсо технически то да. Но вот есть у меня большие сомнения, что инициатива "а давай сделаем так, что write cache будет игнорить все попытки синхронизации, сразу возвращая "ок"? Пусть оно будет ломать данные, зато в бенчах все будет ого-го как!" исходила от иженеров. Да и в чем тут "прогресс", кроме как для синтетических бенчей и дополнительного (в идеальном случае, если не забьют) геморроя разрабам ФС?
- Выпуск Debian 9.8, Анонн, 23:26 , 17-Фев-19 (126)
- Выпуск Debian 9.8, Аноним, 09:48 , 17-Фев-19 (88)
- Выпуск Debian 9.8, Аноним, 20:11 , 18-Фев-19 (153)
- Выпуск Debian 9.8, axredneck, 23:30 , 16-Фев-19 (46)
- Выпуск Debian 9.8, Persepolis, 22:27 , 16-Фев-19 (29)
- Выпуск Debian 9.8, Аноним, 22:40 , 16-Фев-19 (34) +1
- Выпуск Debian 9.8, BlackRot, 22:42 , 16-Фев-19 (35) –3
- Выпуск Debian 9.8, Levon77, 09:09 , 20-Фев-19 (180)
- Выпуск Debian 9.8, Аноним, 22:24 , 16-Фев-19 (28) +8 [^]
- Выпуск Debian 9.8, Ю.Т., 10:46 , 17-Фев-19 (91)
- Выпуск Debian 9.8, Аноним, 15:33 , 17-Фев-19 (110)
- Выпуск Debian 9.8, Аноним, 16:08 , 17-Фев-19 (111)
- Выпуск Debian 9.8, Аноним, 16:55 , 17-Фев-19 (113)
- Выпуск Debian 9.8, Аноним, 22:16 , 17-Фев-19 (122)
- Выпуск Debian 9.8, пох, 22:27 , 17-Фев-19 (124)
- Выпуск Debian 9.8, Аноним, 23:28 , 17-Фев-19 (127) –1
- Выпуск Debian 9.8, пох, 10:56 , 18-Фев-19 (137)
- Выпуск Debian 9.8, Аноним, 11:20 , 18-Фев-19 (141) +1
- Выпуск Debian 9.8, Ю.Т., 12:08 , 18-Фев-19 (143) +3
- Выпуск Debian 9.8, Аноним, 13:06 , 18-Фев-19 (144)
- Выпуск Debian 9.8, Ю.Т., 13:40 , 18-Фев-19 (146)
- Выпуск Debian 9.8, пох, 20:45 , 18-Фев-19 (157)
- Выпуск Debian 9.8, Ю.Т., 21:57 , 18-Фев-19 (158)
- Выпуск Debian 9.8, пох, 22:47 , 18-Фев-19 (159)
- Выпуск Debian 9.8, Ю.Т., 23:23 , 18-Фев-19 (160)
- Выпуск Debian 9.8, Аноним84701, 01:11 , 19-Фев-19 (164)
- Выпуск Debian 9.8, Аноним, 06:52 , 19-Фев-19 (168) +1
- Выпуск Debian 9.8, пох, 12:22 , 19-Фев-19 (174)
- Выпуск Debian 9.8, Аноним84701, 13:44 , 19-Фев-19 (177)
- Выпуск Debian 9.8, Аноним, 07:34 , 19-Фев-19 (170)
- Выпуск Debian 9.8, Аноним, 13:40 , 18-Фев-19 (147) –1
- Выпуск Debian 9.8, пох, 20:33 , 18-Фев-19 (156)
- Выпуск Debian 9.8, Аноним, 06:30 , 18-Фев-19 (130)
- Выпуск Debian 9.8, Ю.Т., 09:09 , 18-Фев-19 (132)
- Выпуск Debian 9.8, Хоха, 21:35 , 17-Фев-19 (117) –1
- Выпуск Debian 9.8, Аноним, 23:39 , 16-Фев-19 (47) –3
- Выпуск Debian 9.8, Аноним, 00:27 , 17-Фев-19 (53) –1
- Выпуск Debian 9.8, Аноним, 00:57 , 17-Фев-19 (59) –1
- Выпуск Debian 9.8, Аноним, 12:47 , 17-Фев-19 (100)
- Выпуск Debian 9.8, Аноним, 01:08 , 18-Фев-19 (129) –1
- Выпуск Debian 9.8, Аноним, 04:05 , 12-Мрт-19 (186)
- Выпуск Debian 9.8, Аноним, 04:09 , 12-Мрт-19 (187)
|