udev?

Читать одно и то же бесполезно, оно в кеше. Писать надо.

udev, /proc, /sys не сработают пока ядро не обнаружит отсутствие диска, а это произойдет когда будет чтение или запись не кешированных данных

Читать одно и то же бесполезно, оно в кеше. Писать надо.

я так и понял... проблема в том, что файлуха read-only и писать на диск нельзя. :(

Тогда перед чтением сбрасывай кеш

Тогда перед чтением сбрасывай кеш

а можно подсказку, чтоб я смог загуглить, как это сделать?

echo 3 > /proc/sys/vm/drop_caches

Почему udev не сработает? Он получит событие отключения устройства.

Когда?

Можно периодически заставлять дисковый контроллер сканировать диски

echo "- - -" > /sys/class/scsi_host/host0/scan

Почему udev не сработает? Он получит событие отключения устройства.

только что проверил: запустил udevadm monitor и отключил диск. Тишина вообще...

sdio, спасибо большое. Сейчас попробую оба варианта и отпишу.

Когда флешку вынут из порта.

udev сработает от события ядра, а ядро ничего пока не знает о диске. Когда контроллер не сможет достучаться до диска, тогда и сработает исключение

Это же CF, который (возможно) напрямую сидит на IDE контроллере, а не на USB card reader

Диск подключается по usb?

Понял.

Диск подключается по usb?

Нет. Сокет для диска на плате распаян. Система его видит как SATA-контроллер

Вроде как был флаг O_DIRECT, чтобы чтение шло напрямую с диска. Или вобще выдрать кусок кода из smartctl и постоянно опрашивать SMART диска (через ioctl SG_IO).

Вроде как был флаг O_DIRECT, чтобы чтение шло напрямую с диска. Или вобще выдрать кусок кода из smartctl и постоянно опрашивать SMART диска (через ioctl SG_IO).

у меня почему-то файл не открывается с O_DIRECT. Просто open возвращает ошибку.

echo 3 > /proc/sys/vm/drop_caches

попробовал сбрасывать кеш и затем читать из файла (файл при этом уже открыт). Все работает, если диск вытащить.

Думаю может open каждый раз делать..

Бро,

А посмотри-ка на это, в особенности на этот файлик. Может поможет чем?

я так и понял... проблема в том, что файлуха read-only и писать на диск нельзя.

mount -o remount,ro /

Если не работает O_DIRECT от root'а, значит не повезло. В ядре не особо хорошая реализация этой опции и её регулярно ломают. Тогда, ИМХО, только ioctl'ами читать SMART диска, или идентификацию диска (как hdparm).

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

mount -o remount,ro /

На диск нельзя писать, т.к. он посыпется. Флешки очень ненадёжные, поэтому мы их в read-only гоняем.

На диск нельзя писать, т.к. он посыпется.

я тебя и не заставляю писать. Эта команда скидывает кеш и переммонтирует девайс. Она завершится ошибкой, если девайс не существует(отвалился).

(т.е. обычно так бывает, но ты попробуй)

Флешки очень ненадёжные

4.2

Флешки весьма надёжные по ресурсу записи, и умираю в 95% случаев от других причин. Т.ч. вы сами создаёте себе лишние сложности.

Если это SATA - ИМХО, задача нерешаема. Посмотри в логах - а само ядро видит, что диск отсоединен? Тогда на крайний случай можео парсить выхлоп dmesg.

Если это SATA - ИМХО, задача нерешаема. Посмотри в логах - а само ядро видит, что диск отсоединен? Тогда на крайний случай можео парсить выхлоп dmesg.

в dmesg ничего нет. Пробовал мониторить через udevadm monitor - тоже тишина. Эта утилита берет события как из ядра, так и из udev

я тебя и не заставляю писать. Эта команда скидывает кеш и переммонтирует девайс. Она завершится ошибкой, если девайс не существует(отвалился).

угу, спасибо, я попробую. Появилась слабая надежда сейчас...

Флешки весьма надёжные по ресурсу записи, и умираю в 95% случаев от других причин. Т.ч. вы сами создаёте себе лишние сложности.

мы пробовали, умирают. Они должны служить много лет, поэтому ничего не пишем на них. Обычно клиенты используют самые дешевые компакт-флешки. Бывают еще industrial grade, которые получше, но они дорогие и их обычно не используют.

в dmesg ничего нет

Значит, система и сама об этом ничего не знает.

Можно попробовать сделать на диске дополнительный раздел и постоянно монтировать/отмонтировать его; если монтирование не проходит - диска нет. Но, если в контроллере CF есть кэширование, то задача выглядит неразрешимой.

угу, спасибо, я попробую. Появилась слабая надежда сейчас...

mount немного читает с начала носителя. DiskID и некоторые первые байты ФС, их можно посмотреть для ext* в tune2fs -l. Если контроллер всё это не закешировал, то сработает. Иначе придётся читатть какой-то рандомный файл...

мы пробовали, умирают. Они должны служить много лет, поэтому ничего не пишем на них. Обычно клиенты используют самые дешевые компакт-флешки. Бывают еще industrial grade, которые получше, но они дорогие и их обычно не используют.

1. сейчас флешки не такое говно, что раньше

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

А посмотри-ка на это, в особенности на этот файлик. Может поможет чем?

я глянул - там через нетлинк от ядра получают инфу. То же самое делает udevadm monitor. Он не видит ничего, т.к. ядро не вкурсе, что диск отвалился.

Ну а что lspci, ls /sys/block говорят.

mount немного читает с начала носителя. DiskID и некоторые первые байты ФС, их можно посмотреть для ext* в tune2fs -l. Если контроллер всё это не закешировал, то сработает. Иначе придётся читатть какой-то рандомный файл...

mount -o remount не помог, видимо контроллер кеширует данные, т.к. выполняется без ошибок, если вынуть диск.

Помогла периодическая запись файла на диск

Помогла периодическая запись данных на диск. Делаю примерно следующиее в цикле раз в 15 минут:

mount -o remount,rw /
write file
mount -o remount,ro /

в файл пишу time текущий. Если вынуть диск, то write мгновенно возвращает ошибку, что мне и нужно. Решение не очень хорошее, но хоть какое-то....

Сделал вывод, что кеширование данных происходит в контроллере, поэтому ядро ничего не знает о том, что диск вынули.

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

Сделал вывод, что кеширование данных происходит в контроллере, поэтому ядро ничего не знает о том, что диск вынули.

да. Я предупреждал, что такое возможно...