fs перемонтировалась в ro из-за ошибок, как сделать назад

mount ***** -o remount,rw

Это нельзя как раз, я ж написал почему.

А что говорит lsof?

сделать umount -f и смонтировать назад. Нет, пишет umount: /home: target is busy., почему?

Это работает только для некоторых сетевых ФС и fuse.

Теоретически ещё можно поробовать losetup. Но, как-то всё странно, вроде в ro должен улетать весь ssd и его из ro нужно выводить через blockdev. А у вас fsck отработал...

Я и без lsof знаю что там куча открытых файлов. Вопрос как раз в том чтоб размонтировать несмотря на их наличие, не убивая процессы их открывшие а просто возвращая им ошибки при попытке дальнейшего обращения к этим открытым дескрипторам. Либо просто подмонтировать эту фс по другому пути уже read-write параллельно, а старую оставить как есть.

Как устройство может в ro улететь? Мне всегда казалось что это именно свойство подмонтированной файловой системы. Всегда улетает именно /home ну и /var иногда, те которым не повезло пытаться что-то делать с диском пока он висит.

losetup имеется ввиду сделать клон /dev/sda и монтировать уже его?

Размонитрованию мешают не только открытые файлы, но и процессы, у которых там рабочий каталог. В теории, можно все эти процесс через gdb заставить и каталог сменить и файлы закрыть. ЕМНИМ, делают же фокус по перенаправлению stdout в файл запущенного процесса.

Ну раньше по записям в dmesg, в RO всё устройство уходило. Там всякие ошибки записи, попытки сделать reset контроллеру/диску, потом, раз проблемы на уровне устройства, это устройство в RO и переводилось. Не на физическом уровне, а на уровне драйвера в ядре.

В у себя dmesg изучили? Что там за ошибки?

/dev/sda

Я бы делал loseup на то устройство, на котором ФС, обычно они на разделах, а не на весь ssd.

Через gdb это ж куча возни. Но вообще как основа для идеи хорошая: можно сделать прогу которая автоматически проходится по всем процессам и заменяет неподходящие дескрипторы на невалидные (но надо не просто close а чтоб он занят чем-то оставался, чтоб туда другой файл потом не открылся, например pipe открыть и один конец оставить). Но это когда-нить потом.

Ух ты, всё просто оказалось.

mount -o loop /dev/sda8 /mnt/home

Может быть можно и

mount -o loop /dev/sda8 /home

чтобы спрятать старую фс и потом плавно переходить на новую. Единственное, новая то будет что-то писать туда, а драйвер старой будет в итоге получать неожиданные изменения данных на ro-диске, надеюсь от этого panic не случится или ещё что плохое.

mount -o loop /dev/sda8 /home

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

В у себя dmesg изучили? Что там за ошибки?

[378510.200548] sd 1:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=51s
[378510.200557] sd 1:0:0:0: [sda] tag#18 CDB: Write(10) 2a 00 03 07 08 30 00 00 08 00
[378510.200562] blk_update_request: I/O error, dev sda, sector 50792496 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[378510.200571] EXT4-fs warning (device sda6): ext4_end_bio:345: I/O error 10 writing to inode 16 starting block 6349063)
[378510.200578] Buffer I/O error on device sda6, logical block 56838
[378510.200610] sd 1:0:0:0: [sda] tag#30 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=48s
[378510.200615] sd 1:0:0:0: [sda] tag#30 CDB: Write(10) 2a 00 1a 00 28 30 00 00 08 00
[378510.200619] blk_update_request: I/O error, dev sda, sector 436217904 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
[378510.200625] Buffer I/O error on dev sda8, logical block 46137350, lost async page write
.........
[378510.200854] Buffer I/O error on dev sda8, logical block 23, lost async page write
[378510.200866] Buffer I/O error on dev sda8, logical block 14, lost async page write
[378510.200929] EXT4-fs error (device sda8): ext4_check_bdev_write_error:215: comm Cache2 I/O: Error while async write back metadata
[378510.200940] EXT4-fs (sda8): previous I/O error to superblock detected
[378510.201662] Aborting journal on device sda8-8.
[378510.210953] EXT4-fs error (device sda8) in __ext4_new_inode:1089: Journal has aborted
[378510.218014] EXT4-fs error (device sda8) in ext4_create:2634: Journal has aborted
[378510.221070] EXT4-fs error (device sda8) in ext4_orphan_add:3015: Journal has aborted
[378510.227722] EXT4-fs error (device sda8) in ext4_reserve_inode_write:5761: Journal has aborted
[378510.230011] EXT4-fs error (device sda8): ext4_truncate:4296: inode #3933615: comm mozStorage #4: mark_inode_dirty error
[378510.232221] EXT4-fs error (device sda8) in ext4_truncate:4299: Journal has aborted
[378510.234433] EXT4-fs error (device sda8) in ext4_setattr:5539: Journal has aborted
[378510.286039] EXT4-fs error (device sda8): ext4_journal_check_start:83: Detected aborted journal
[378510.286048] EXT4-fs (sda8): Remounting filesystem read-only

Не знаю почему у них одинаковый таймстамп, видимо начало лага никак не логируется, а это только конец. До этого примерно минуту в top-е процам показывается %wait вместо %idle и все операции с диском висят. Если меньше минуты - всё норм, если больше - то ошибки и remount-ro.

Что-то можно ещё сделать?

Да - как можно быстрее купить новый SSD и переписать на него данные с лагающего. Железо шепчет, что скоро ему абгемахт.

Из-за общей слабости организма пациент постоянно падает. Сделает пару шагов и упадет, а иногда и сразу падает.

Допустим я его поставил на ноги, неважно как. Если не дуть, то стоит, значит все с ним на самом деле в порядке. Дальше можно, если не издавать резких звуков, не дергаться и вообще не пугать, быстро сфотать его для отчетности. Метод 100% рабочий, но не всегда удобно, хотелось бы избежать этой возни.

Понятное дело, примотать его к стене скотчем нельзя, тут пробовал две идеи, обе провалились:

1. если падает, бить по почкам и ставить заново. Бока опухают, теперь не всегда попадаю по почкам.

2. ставить в другом месте, плачет и стонет, что не может.

Что-то еще можно сделать?

не написал, почему. Прозреваю причина в том, что файловая система как раз не починена, поэтому и слетает в ro.

Как устройство может в ro улететь? Мне всегда казалось что это именно свойство подмонтированной файловой системы.

ну попробуй в rw смонтировать sdкарту со опущенной шторкой ro. Если устройство ro, то любая fs на нем будет монтироваться в ro.

Мне нравится твой оптимизм. Честно, без сарказма.

Иногда ведь приходится работать с такими устройствами да еще и железку перезапускать нельзя. Вот тут такие знания хитростей перемонтирования на лету очень помогают…

Он такой с момента покупки был и живёт уже лет 5. Это просто плохая прошивка, подозреваю он всякое ссд-обслуживание делает не в фоне просто и всё это время не отвечает. Но новый надо да, на этом места мало (кстати кажется чем меньше места остаётся тем чаще оно происходит) да и хотел десктопное фрибсд попробовать.

Если что это Kingston SA400S37/240G, но я слышал что у них даже в рамках одной модели разные ревизии могут быть с разными контроллерами, видимо в этом экземпляре контроллер+прошивка не совсем удачные.

Напишу ещё раз: ядро не смогло что-то туда записать, выбросило все очереди записи, после чего туда писало fsck. Продолжать с того места, где ядро не смогло записать, после такого однозначно опасно, даже если б ядро это и позволяло. Но оно вполне разумно не позволяет.

Вообще в коде ext4_remount() в ветке, где обрабатывается случай ro→rw есть комментарий:

                        /*
                         * Mounting a RDONLY partition read-write, so reread
                         * and store the current valid flag.  (It may have
                         * been changed by e2fsck since we originally mounted
                         * the partition.)
                         */

который намекает на то, что твой сценарий, как минимум, рассматривался.

Перемонтировать ro в rw в общем случае, конечно, можно - когда это сначала было штатное ro и потом надо добавить запись. А тут аварийное ro с неконсистентным представлением ядра о том, что сейчас записано на диск (потому что запись была отброшена и журнал остановился на каком-то устаревшем месте) - его нельзя перемонтировать.

Хотя e2fsck после чистого ro-монтирования конечно тоже может нарушить консистентность и тоже нехорошо. Но, думаю, тут два момента:

1) ядру сложно об этом нормально узнать, поэтому до как-то пытаться учесть такую опасность

2) тут изменения только вперёд, их надо как-то допрочитать, а в случае аварии надо откатить незаписанное ещё, хотя и разницы формально мало

Логично.

Я просто прочитал это так, что ты успешно пролечил файловую систему и все равно она монтируется в ro.

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

Я не про кеш а про то что например список блоков, на которых расположена открытая инода, скорее всего не перечитывается с диска каждый раз при чтении/записи этой иноды. И если, допустим, перед отвалом был удалён один файл, создан на его месте другой, и всё это не смогло записаться на диск, то при перемонтировании в rw на лету запись нового файла будет вестись совсем не туда, куда нужно (по факту то этого нового файла вообще не будет на диске, а ядро будет туда писать как будто он есть). А потом, когда кто-то заставит ядро перечитать директорию с удалённым, оно обнаружит и его там на старом месте на тех же блоках куда только что писался новый, и вообще непонятно что будет.

Что бы это всё привести в консистентное состояние, надо всю рантайм информацию об открытых файлах принудительно сверить с состоянием диска и инвалидировать те, которых на диске нет, и скорректировать те, что есть, если метаданные на диске отличаются. Просто «выбросить всё» и прочитать заново нельзя - эти данные привязаны к открытым дескрипторам.

Почитал код ext4 и вот что нашёл.

Сообщение «Remounting filesystem read-only» может быть сгенерировано либо в ext4_handle_error(), либо в __ext4_abort(). В обоих случаях устанавливается флаг EXT4_MF_FS_ABORTED, который затем будет проверен в ext4_remount(), если попытаться перемонтировать ФС. Если я правильно понял, если флаг установлен, дело дальше не пойдёт, и ФС не будет смонтирована на запись.