LINUX.ORG.RU

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

 , , ,


0

1

В общем закончилась жизнь флешки Sandisk Cruser Fit и ушла она в ro защитное.
Так вот:
1. под /boot я её отформатировал ext3 с объёмом 930 МБ с использоваными 174 МБ
2. под / я её отформатировал в btrfs разбив на кучу субволюмов, занято там 4 ГБ из 14 ГБ.

Как думаете, какая ФС сдохла и не читается?
А ворт фиг вам, сдохла и вообще не читается ext3 под папку /boot, в которую запись и чтение то происходят раз сто лет в обед.

Ну вот я вам рассказал, у меня всё, если есть вопросы задавайте, отвечу в меру своих сил.

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

Ещё раз: используемая флешка это Sandisk Cruser Fit

★★★★★

Ответ на: комментарий от torvn77

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

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

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

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

anonymous ()

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

eternal_sorrow ★★★★★ ()

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

torvn77 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

torvn77 ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

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

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

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

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

anonymous ()
Ответ на: комментарий от torvn77

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

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

Deleted ()

ext3 под папку /boot

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

torvn77 ★★★★★ ()
Ответ на: комментарий от Deleted

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

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

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

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

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

anonymous ()
Ответ на: комментарий от torvn77

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

t184256 ★★★★★ ()
Ответ на: комментарий от torvn77

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

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

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

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

anonymous ()
Ответ на: комментарий от t184256

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

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

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

anonymous ()
Ответ на: комментарий от t184256

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Прочитай данные с первого раздела 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

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 3)
Ответ на: комментарий от torvn77

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

Deleted ()
Ответ на: комментарий от torvn77

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

linuxnewbie ()
Ответ на: комментарий от torvn77

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

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

Deleted ()
Ответ на: комментарий от torvn77

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

linuxnewbie ()
Ответ на: комментарий от linuxnewbie

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

Deleted ()
Ответ на: комментарий от torvn77

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

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

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

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

Понятно?

anonymous ()
Ответ на: комментарий от Deleted

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

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

torvn77 ★★★★★ ()