К сравнению надёжности и наработки на критический отказ btrfs и ext3

ext3

2019 год

Плохо весною без таблеток

ммэ. побились сектора с ext3 разделом, значит путин виноват

ext4 по моему опыту довольно быстро перезаписывает первичный загрузчик.

Значит ФС семейства ext виновата, а Путин тут не причём.

Шта?

Так у вас флешка перешла в RO или файловая система на флешке из-за ошибок перешла в RO?

Что значит ext4 перезаписывает загрузчик?

Даже если ext3 перешла в RO, то проверьте её на ошибки и используйте дальше.

Эта нормальное поведение файловой системы, если вы на неё писали и далее либо отключили флешку, либо сделали reset компьютера до отмонтирования файловой системы.

ну и о чём это говорит? каким то рандомом первыми сломались именно те элементы NAND-памяти, которые были выделены для /boot раздела, какие выводы можно тут делать?

под /boot я её отформатировал ext3

Умный ход? Сразу напрашивается - зачем? Для журнала? Журналируемый boot? ext2 не пошёл бы? Ты специально изнасиловал boot журналом?

Флешки емкие вообще ненадежные. Любая ФС сдохнет.

ext3 у меня сейчас смонтировалась пустой, при монтировании через Caja она пишет "exit status 32", что мол флешка реадонли и по этому смонтирована быть не может.

По этому поправка, ext3 монтируется, но пустой.

Что значит ext4 перезаписывает загрузчик?

Строго говоря перезаписывается не первичный, а полуторный загрузчик, который грузится загрузчиком загрузчиком из первого сектора

Даже если ext3 перешла в RO, то проверьте её на ошибки и используйте дальше.

Фдешка целиком, как устройство перешла в RO

Умный ход? Сразу напрашивается - зачем? Для журнала? Журналируемый boot? ext2 не пошёл бы? Ты специально изнасиловал boot журналом?

Хехе, другая то часть флешки насиловалась btrfs журналом и чексуммами.

Флешки емкие вообще ненадежные. Любая ФС сдохнет.

Вполне себе надёжная флешка, где то от полуторых до двух лет отработала в режиме 34/7

Строго говоря перезаписывается не первичный, а полуторный загрузчик, который грузится загрузчиком загрузчиком из первого сектора

Я с таким ни разу не сталкивался, видимо, ты что-то делаешь не так.

Фдешка целиком, как устройство перешла в RO

Ну так, в чём тогда смысл темы? У тебя отказал накопитель, а ты пишешь, что проблема в ext3.

Хехе, другая то часть флешки насиловалась btrfs журналом и чексуммами.

Да. Только для этого было 10G места, куда хотишь, туда и кладёшь. А для boot меньше 1G, особо не разбежишься.

ext3 под папку /boot

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

Ну так, в чём тогда смысл темы? У тебя отказал накопитель, а ты пишешь, что проблема в ext3.

В том что в равных условиях сдохла именно ext3, хотя на неё были самые маленькие нагрузки.

В этом треде странно все, но страннее всего отдельный /boot. Нафига?

На /boot ведётся запись большого объёма данных только при обновлении ядра, которое происходит отнюдь не каждый день.
А на btrfs на котрой была остальная часть системы каждые два-три дня от 20 до 150 МБ приходило.

Ну не получился у меня /boot на btrfs подразделе.

На /boot ведётся запись большого объёма данных только при обновлении ядра

Так бы оно и было бы, если бы это был ext2.

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

И на основе этого ты сделал вывод, что ext3 хуже btrfs и вообще она виновата?

С логикой у тебя плохо.

Ну а как ты предлагаешь определить виноватого?

И как ты этого добился? Это в стабильном дебиане лет семь как просто работало, что у тебя могло не выйти?

Наверное тем что выносил /boot на subvolume

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

Если у тебя там стояла операционная система и работала в обычном режиме, то виноват ты сам.

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

Посмотри хотя бы сколько логов пишется в /var/log.

Посмотри хотя бы сколько логов пишется в /var/log.

/var/log на отдельном подразделе btrfs, а сдохла ext3

Использовал основную ОС на журналируемой ФС на флешке когда флешки были еще по 256 МБ. Флешки стали в 16 раз больше, а тот Transcend так по сей день и не сдох.

Может хватит уже повторять бредни эпохи моего детства?

Ты пишешь, что у тебя вся флешка перешла в RO, это так?

Если ты, то повторяю, что ext3 - журналируемая файовая система. И если у тебя в момент когда контроллер флешки перевёл FLASH памяти в режиме чтения на ext3 писался журнал, то у тебя ext3 и сломалась. Потому, что контроллер заблокировал запись на накопитель.

Прочитай данные с первого раздела dd в файл и проверь файловую систему в файле на ошибки.

Прочитай ещё раз прошлое сообщение и включи голову.

У меня тоже ест 1Гб флешка 2006 года Transcend JetFlash 120, котрая использовалась некоторое время в режиме как у ТС, на ней стоял Linux, а потом просто носил файлы с FAT32 и сейчас она работает.

А новые флешки дохнут, переходят в RO.

Не знаю, что изменилось, но сайчас современные флешки дольше 4-х лет не живут. Всё зависит от объёма записанных данных.

но страннее всего отдельный /boot

Решил я как-то посмотреть на сжатие в btrfs. И как раз была виртуалка с btrfs. Дал команду пережать всё, вроде неплохо получилось. Но потом, после перезагрузки выяснилось, что grub 2 не в курсе, как читать с btrfs со сжатием.

И было это в 2012? Потому что где-то в 2013 в Вилларибо уже все работало.

Прочитай данные с первого раздела dd в файл и проверь файловую систему в файле на ошибки.

root@debian:~# fsck.ext3 /home/sdc2.img
e2fsck 1.43.4 (31-Jan-2017)
boot: recovering journal
boot: clean, 353/936 files, 178378/952300 blocks
root@debian:~# mount -o loop,rw /home/sdc2.img /mnt
root@debian:~# ls /mnt
config-4.19.0-2-amd64	  config-4.19.0-4-rt-amd64   initrd.img-4.19.0-2-rt-amd64  memtest86+.bin	      System.map-4.19.0-2-rt-amd64  vmlinuz-4.19.0-2-amd64     vmlinuz-4.19.0-4-rt-amd64
config-4.19.0-2-rt-amd64  grub			     initrd.img-4.19.0-4-amd64	   memtest86+_multiboot.bin   System.map-4.19.0-4-amd64     vmlinuz-4.19.0-2-rt-amd64
config-4.19.0-4-amd64	  initrd.img-4.19.0-2-amd64  initrd.img-4.19.0-4-rt-amd64  System.map-4.19.0-2-amd64  System.map-4.19.0-4-rt-amd64  vmlinuz-4.19.0-4-amd64
root@debian:~# 

Прочитай ещё раз прошлое сообщение и включи голову

Меры были приняты и условия у ФС были раными:

UUID=c048fc94-3ea9-4804-a833-ffa4c5d26a8a /                    btrfs   defaults,noatime,nodiscard,commit=7200,acl,compress-force=zlib:6,ssd         1 1
# /boot was on /dev/sdb2 during installation
UUID=0f875dd9-40ca-4e20-9112-af91e934a270 /boot                ext3    defaults,noatime,nodiscard,commit=7200,discard        1 1

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

Так что смысл твоей темы не ясен.

Можно лишь сделать вывод, что не нужно ставить Linux в обычном режиме на флешку, если уж так хочется, то делай как в случае LiveCD, файловая система находится в squashfs, а запись проводится на файловую систему в памяти.

Где-то с месяц назад. Честно говоря, не помню, что ставил. Скорее всего, это был Arch или производная.

Так что смысл твоей темы не ясен.

Смысл в том, что из двух ФС сломалась именно EXT3, при чём до этого я за время эксплуатации резетил компьютер, так как забивал и файерфоксом ОЗУ и его работа парализовывалась.
Так что у было больше шансов накрыться при резете компьютера, а для ext3 получается хватило и одного.

Ни кто не знает, как определить то какая ФС замучила флешку?

Ты в курсе, как работает контроллер флэшки? Да при чем тут вообще ext3 и /boot в частности, когда она ушла в RO во время wear-leveling. Естесно, скорее всего, контроллер не смог перетащить редкоменяемые данные в изношенную область, чем сломал ext3 и ушёл в RO, чтоб дальше не косячить. Вопрос у индивидуума, который ОП - глупый.

ФЛэшки если что современные гораздо менее износоустойчивы. Техпроцесс-с...

Как у тебя в одном месте discard и nodiscard согласуются? И зачем вообще nodiscrd на флэшке? дефолт вооще не судьба, да? btrfs со сжатием... да ты вообще отморозок. Хотя после использования журналируемых ФС на флэхе... Хе-хе.

ext4 с отключенным журналом

Если Вы про tune2fs -O «^has_journal» /dev/sdXN, но мм оно тормозило на несколько порядков больше, чем ext4, какие ещё будут предложения? Почему бы не использовать стандартный для efi (и флешек) fat32?

Смысл в том, что из двух ФС сломалась именно EXT3

Смысл в том, что ты дурак. Сломалась у тебя не ФС, а носитель. И да. УБили носитель не файловые системы, а убил его износ. Банальный износ, чего твоя куриная башка понять не может.

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

Но раз сломался носитель в момент записи на ту часть носителя на которой была ext3, то видимо и ext3 свою часть больше, чем btrfs свою.

то видимо и ext3 свою часть больше, чем btrfs свою.

ТС, вы говорите загадками.

я пропустил слово 'износила', если бы ты мне о этом не написал, то я бы сейчас это поправило.

я пропустил слово 'износила'.

ТС пропустил изнасилование своей флешки и не фс, а самим ТС.

Про WearLeveling почитай, узнаешь, как современные флэшки работают хоть. Я ещё почитай, что такое NAND (ибо опять же современные флэшки). Я не знаю, сколько тебе надо объяснять, что убил носитель износ. Да и банально мог брак оказаться, ячейки с низким ресурсом оказались под ext3. Ну вот такое тоже бывает. Ты тут специально голову морочишь, или просто не хочешь мозг включать?

Или btrfs не имеет утилит позволяющих заметить, что память сдохла. Это не дискетка всё-таки, нет такого понятия как запись «в начало» или «в конец». Кроме того, если флешка уже обнаружила расхождения в контрольных блоках, она может просто переставать работать (а не продолжать насилие с порчей данных).

Там SanDisk Cruzer - они уходят в RO, и часто такое бывает, что и ячейки памяти то ещё не сбойные. но контроллер уже испугался. А еще такая флэха может полежать месячишко-другой без питания и тоже окочуриться из-за стекания заряда.

Понимаешь в чём суть, у тебя контроллер флешки считаеот общее количество циклов записи на флешку.

И то, что запись на файловую систему ext3 стала пороговой записью для контроллера, после которой он перевёл flash память в режим только чтения не означает, что виной этому ext3.

Ты это понимаешь или нет?

Просто запись на ext3 стала последней каплей для достижения порога циклов перезаписи.

Понятно?

Да и банально мог брак оказаться, ячейки с низким ресурсом оказались под ext3.

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