Стандартная проблема с mount/umount «device or recourse is busy»

нету, потому что так и должно быть

man lsof, man fuser

> Неужели нет другого решения?

Другого решения нет. А чем не устраивает «убить и отмонтировать»?

Если честно, то из чрута не всегда удается выйти а lsof,fuser показывают что партицией никто не пользуется, так что не всегда это выход.

а umount -f не катит?

>Другого решения нет. А чем не устраивает «убить и отмонтировать»?

А представьте себе на секунду, что программа, которая между делом ещё и на СД карточу что-то пишет, работает в медицинском приборе, к примеру, в дыхательном аппарате. Слово «убить» тут уже приобретает прямой смысл. Не понимаю, почему это не решено на уровне ОС. Ведь ясно же, что ресурса, к которому обращён такой запрос в системе уже НЕТ. Ведь можно же вызову fwrite() вернуть errorcode и автоматом отключить устройство в ОС. К чему эти грабли в UserSpace?

>а umount -f не катит? Не, он не отрабатывает такие отключения. Тоже говорит, что ресурс занят

К.О. Намекает, что сначала надо отмонтировать, а потом вытаскивать.

А представьте себе на секунду, что программа, которая между делом ещё и на СД карточу что-то пишет, работает в медицинском приборе, к примеру, в дыхательном аппарате. Слово «убить» тут уже приобретает прямой смысл.

Разработчика такой программы надо очень долго и больно бить =).

Не понимаю, почему это не решено на уровне ОС.

Потому что это не решаемо на уровне ОС. Вообще сама процедура отмонтирования очень часто предполагает запись данных на устройство. По этому отмонтировать устройство, которого уже в системе нет, бессмысленно. По хорошему, должен быть способ сообщить системе о том, что пользователь собирается вынуть SD-карту, но такого способа, увы, не предусмотрено by design.

Ведь ясно же, что ресурса, к которому обращён такой запрос в системе уже НЕТ. Ведь можно же вызову fwrite() вернуть errorcode и автоматом отключить устройство в ОС. К чему эти грабли в UserSpace?

Кому ясно? Тебе ясно? Ну так понятно, это же ты выдернул SD-карту =). А система честно ждёт по таймауту, как и должно быть.

>Кому ясно? Тебе ясно? Ну так понятно, это же ты выдернул SD-карту =). А система честно ждёт по таймауту, как и должно быть.

Странно, но в той же Windows такая «нестандартная» проблема решена - вытащил карту, система поругалась, всунул опять - устройство на месте. А тут вытащил - решай сам, как убить процесс записи, потому что при следующем втыкании хрен чё примонтируешь. Не, в данном случае грабли явно в ОС :-(

velikS>> работает в медицинском приборе, к примеру, в дыхательном аппарате.

mironov_ivan> Разработчика такой программы надо очень долго и больно бить =).

А потом лечить в той больнице с тем дыхательным аппаратом :-)

> А представьте себе на секунду, что программа, которая между делом ещё и на СД карточу что-то пишет, работает в медицинском приборе, к примеру, в дыхательном аппарате. Слово «убить» тут уже приобретает прямой смысл

Да, убить разработчика этой программы. В прямом смысле.

>Да, убить разработчика этой программы. В прямом смысле.
Надо подумать над этим предложением :-) А вообще классный подход - кривость в ОС by design (с mironov_ivan) убиваем разработчика в UserSpace ;)))

> А вообще классный подход - кривость в ОС by design (с mironov_ivan) убиваем разработчика в UserSpace

приложения, от которых зависит жизнь человека не должны зависеть от вытащенной SD-карточки, это очевидно.

>приложения, от которых зависит жизнь человека не должны зависеть от вытащенной SD-карточки, это очевидно.

Абсолютно с Вами согласен. Честно говоря сегодня сильно удивился такой дыре в Линукс by design. Придётся лепить чёрти что в UserSpace, чтобы разделить процессы записи на карту и управления дыхательной машиной и при возникновении такой ситуации убивать процесс записи.

Ну а то, что тут писали товарищи в стиле:
«Кому ясно? Тебе ясно? Ну так понятно, это же ты выдернул SD-карту =). А система честно ждёт по таймауту, как и должно быть.»

Увы, но это не аргументы. Система СРАЗУ знает если выдернули УСБ-Стик по прерыванию, и СРАЗУ знает, если выдернули СД-Карту по одному из сигналов. Просто у разработчиков Kernel-Space или ещё руки не дошли (скорее всего), или у них в голове проблемы by design

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

>кривость в ОС by design

кривость бай дезигн - это именно в Вашем хвалёном виндовс, отмонтировать что ни попадя, не синхронизируя, вот потом и мрут больные от таких АИВЛ.

man sync
потом рассуждай о кривости архитектуры, гений

а флаг MNT_DETACH не выручит в данной ситуации?

>а флаг MNT_DETACH не выручит в данной ситуации?
Ха! Спасибо! Похоже делает то, что надо!

umount2( /mnt/SD, MNT_DETACH );

> Ха! Спасибо! Похоже делает то, что надо!
Только чур если пациент задохнётся от ошибки в программе на меня не ссылаться!

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

umount -f -l?

>Только чур если пациент задохнётся от ошибки в программе на меня не ссылаться!

В приборе будут стоять 2 контроллера. Дыхательной машиной управляет второй с safeRTOS. Этот с Линукс для всяких User-Примочек, вроде Qt, SD, Ethernet, USB и т.д. Т.е., если он отвалится, то будет нехорошо, но не страшно :)

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

Безусловно! Этим сейчас и занимаюсь. Но теперь по крайней мере отпала проблема убивать процесс записи. Процесс записи должен отрабатывать ошибку fwrite (или fwrite_unlocked, я ещё неопределился) и сообщать на экране прибора, что запись была неуспешной. А второй процесс безболезненно отмонтирует карточку в этот момент. Это как раз нормальное поведение такой системы, которое я и хотел.

А то все эти грабли с «карточка вытащена -> убить процесс записи -> отмонтировать» требовали запись в отдельном потоке и хренЗнаетКакие грабли, чтобы определить такое поведение и сообщить об нём на экране. Теперь всё красиво :)))

>umount -f -l?
Да, это оно. Я не знал про lazy unmount. -f работает только для NFS. Тут он бессмыслен

Всем ещё раз спасибо

Вот человек сначала man'ы не читает,а потом у него видите ли проблемы в ОС, а не в его незнании и нежелании прочитать man.

>Вот человек сначала man'ы не читает,а потом у него видите ли проблемы в ОС, а не в его незнании и нежелании прочитать man.

Вот сейчас вся эта байда при вытаскивании карточки во время записи отваливается по «Kernel panic - not syncing: Fatal exception in interrupt» :) Будут какие-то дельные идеи или только бестолковая мораль :)

> при вытаскивании карточки во время записи отваливается по «Kernel panic
Погоди-погоди, у тебя там точно не FreeBSD?

Вот сейчас вся эта байда при вытаскивании карточки во время записи отваливается по «Kernel panic - not syncing: Fatal exception in interrupt» :) Будут какие-то дельные идеи или только бестолковая мораль :)

Значит ошибка в драйвере ридера карт. https://bugzilla.kernel.org/.

>Погоди-погоди, у тебя там точно не FreeBSD?

Господь с вами! Какая BSD? Сами мы не местные. Процессор АRМ9 от Atmel AT91SAM9G45, ядро 2.6.30 с патчами с linux4sam.com. Rootfs и toolchain от Buildroot-a 2010.05 и естессно кой-какие скрипты пришлось подрихтовать.

Я пока на время «забыл» про unmount(). Похоже, оно будет работать с MNT_DETACH. Пока при записи со стандартной «cp /mnt/data/blabla /mnt/SD/» весьма часто выскакивает kernel panic если выдернуть карту. с ним пока буду разбираться. Похоже, пацаны в ISR SD-карты в своём патче напортачили. Но тут вряд ли кто с таким поможет

>Значит ошибка в драйвере ридера карт. https://bugzilla.kernel.org/.

Спасбо за линк - стукану им :)

Почему же? Попробуй при записи чего-нибудь на жёсткий диск вытащить его. Получишь то же самое. И что, будешь говорить, драйвер виноват?

> Почему же? Попробуй при записи чего-нибудь на жёсткий диск вытащить его. Получишь то же самое. И что, будешь говорить, драйвер виноват?
Если вытащить не системный то ничего не будет фатального. У самого отваливалось питание на втором винте и система работала как ни в чём не бывало.
Другое дело если отрубить диск с рутовой фс.

>Почему же? Попробуй при записи чего-нибудь на жёсткий диск вытащить его. Получишь то же самое. И что, будешь говорить, драйвер виноват?

Как приятно обшаться с людьми с Луны ) Да я буду говорить, что драйвер виноват, потому что by design: система проектируется для людей, а не наоборот. Драйвер знает, что устройство отсутствует, значет должен корректно обработать ситуацию без обвала ВСЕЙ системы

> Похоже, пацаны в ISR SD-карты в своём патче напортачили.
Если проблема в стороннем патче, то на bugzilla.kernel.org вас ессно пошлют :)

>Другое дело если отрубить диск с рутовой фс. Ну это - другой случай. Тут ресурс нужен для работы ОС. Я не ожидаю, что ОС будет нормально работать, если вытащить планку RAM. Но у меня другой случай. Будем посмотреть )

>Если проблема в стороннем патче, то на bugzilla.kernel.org вас ессно пошлют :)
И я их пойму :) Поэтому сперва попробую сам разобраться. Вот только так глубоко Кернел ещё не ковырял :(

значет должен корректно обработать ситуацию без обвала ВСЕЙ системы

Просто для смеха выжержка из педивикии (статья про kernel panic):

Сообщение Kernel panic было введено в ранних версиях UNIX и представляла собой важное отличие в философии этой операционной системы от главного конкурента на то время, Multics. Разработчик Multics, Том ван Влек так описывает это изменение в дискуссии с разработчиком UNIX Денисом Ритчи[1]:

Я сказал Деннису, что примерно половина кода, который я написал для Multics, был кодом обработки ошибок. Он ответил: «Мы всё это отбросили. Если произошла ошибка, у нас есть процедура под названием panic и если она вызвана, компьютер зависает и вы кричите: „Эй, перезапустите его!“»

> И я их пойму :) Поэтому сперва попробую сам разобраться. Вот только так глубоко Кернел ещё не ковырял :(
А с ванильным ядром эта карточка работает? Если да, то можешь попробовать всё это проделать с ваниллой.

Я не ожидаю, что ОС будет нормально работать, если вытащить планку RAM.

Зря. Линукс это поддерживает, правда, только на специальном железе.

О какой корректной обработке может идти речь, если у драйвера куча данных в кеше и 0 информации о процессах, которые ему её туда передали?

Ты правда думаешь, что драйвер должен всех на уши ставить сообщениями в духе «заберите свои байты назад», а приложения (каждое(!), включая наколенные самоделки) должны их забирать и пытаться как-то «корректно» обработать их далее?

Вопросы у меня, конечно, риторические. Отвечать вовсе не обязательно.

>А с ванильным ядром эта карточка работает? Если да, то можешь попробовать всё это проделать с ваниллой.

К сожалению поддержка этого очень нового процессора пока не включена в ванильное. Без патчей пока никак. Хотя я тут вот тоже засомневался - мож подождать немного? Прибор в серию пойдёт не раньше, чем через 2 года.За это время кого-то куда более опытного с Линуксом точно сильнее, чем меня припечёт решить такую проблему :)

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

>Ты правда думаешь, что драйвер должен всех на уши ставить сообщениями в духе «заберите свои байты назад», а приложения (каждое(!), включая наколенные самоделки) должны их забирать и пытаться как-то «корректно» обработать их далее?

Риторические вопросы подымают интересную интерпретацию. Вы считаете нормальным поведение системы, которая валится при отключении несущественного ресурса? Вопрос тоже риторический

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

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

> Корректно обработать сообщение в духе «не удалась запись файла» - невозможно. Можно лишь попробовать файл записать ещё раз (туда же или в другое место), и посоветовать пользователю проверить железо.

Что понимается под «корректной обработкой» ?
Например если после такого казуса приложение выведет на экран сообщение в духе «Ошибка записи в файл. Проверьте наличие карты памяти. Попробовать ещё раз? (Д/н)» то это можно считать корректной обработкой?

> Что понимается под «корректной обработкой» ?

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

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

>>А с ванильным ядром эта карточка работает? Если да, то можешь попробовать всё это проделать с ваниллой.

К сожалению поддержка этого очень нового процессора пока не включена в ванильное. Без патчей пока никак. Хотя я тут вот тоже засомневался - мож подождать немного? Прибор в серию пойдёт не раньше, чем через 2 года.За это время кого-то куда более опытного с Линуксом точно сильнее, чем меня припечёт решить такую проблему :)

Ха! Прикольно!!! Только что скачал 2.6.34. Так вот в нём есть всё, что есть в патчах КРОМЕ(!!!) поддержки SD карты!!! Похоже таки не я один с этим столкнулся (это плюс), и ребята работают с поддержкой этого процессора в ванильном (ещё больший плюс). Качаю 2.6.35-rc6 ))

В 2.6.35-rc6 поддержку SD карты тоже не включили. Интересно почему?

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

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

> например после вставки карты обратно приложение может возобновить нормальную работу.

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

Текущий kernel panic связан с багом в ядре, не в приложении (-ях).

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

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

>Таймаут в таких случаях

Подскажите пожалуйста, по завершении таймаута write вернёт ошибку, ноль или как? Просто проверить сейчас не могу.