Проблемы завруса

Executier

ВадимП писал(а):
Executier писал(а): #!/bin/bash

while 1>2
do
echo `cat /proc/apm` >> ~/batstat
sync
sleep 60
done
1. Больше всего меня заинтересовало, что за команда команда перенаправления "1>2"? :P
Скорее всего, автор подразумевал нечто вроде "while true".
2. Очень понравилась форма "echo `cat /proc/apm` >>". Если кто мне сумеет объяснить, чем это лучше обычного "cat /proc/apm >>" буду очень благодарен.
3. sync тут тоже ни к селу, ни к городу (все равно пишется на jffs2). Правда, никому не мешает.

sync на тот случай если кпк повиснет при низком заряде батареи и кэш не будет сброшен на диск. Хотя, есть такой процесс bdflush... Кстати, что будет, если во время записи в файл вытащить батарейку? Мне кажется файл будет потерян, т.к. он на лету сжимается и во флешку попадает уже в сжатом виде. А если в этот момент прервать запись, то на флешке будет только часть архива.
По поводу всего остального-да я вообще программировать не умею, тем более bash scripting. Это все делалось в торопях и по принципу "лишь бы правильно работала". Ведь работает, а? :)
Кстати, Вадим, Вы на меня потратили больше времени чем требуется на доработку этого аплета или вправления ядерной таблицы. Осталось только подправить вышеуказанную мной функцию и делов-то. Я думаю, последний шаг не вызывает сомнений в свое простате?
PS Надеюсь, сырцы под gpl а то еще обвинят в незаконном изменении и распространении кода...

ВадимП

Executier писал(а):Кстати, Вадим, Вы на меня потратили больше времени чем требуется на доработку этого аплета или вправления ядерной таблицы. Осталось только подправить вышеуказанную мной функцию и делов-то. Я думаю, последний шаг не вызывает сомнений в свое простате?

Не знаю, как там по поводу простАты (где подразумевается ударение?

), но если бы всё было так просто, то это, вероятно, уже было бы сделано, не правда ли?

P.S. Драйвер jffs2 (в зависимости от версии) имеет определенные особенности выполнения системных вызовов sync()/fsync().

ВадимП

Немного поясню по поводу "особенностей" (может кому будет интересно, хотя вряд ли): драйвер устанавливает таймер, который обнуляется при каждой записи в файловую систему. Если значение таймера достигает WBUF_FLUSH_TIMEOUT, то sync() вызывается автоматически...
А это значение по умолчанию установлено в 2 секунды. То есть, если записи в файловую системы не было хотя бы 2 секунды, то все буфера сбрасываются.
Поскольку в Вашем примере запись происходила в файл в домашней директории - значит необходимости в явном вызове sync не было...

ВадимП

Кстати, похоже, что в предыдущем сообщении у меня всё неправильно

.
Я сейчас не обнаружил процесса для автоматического сброса буферов по таймеру и решил заново просмотреть тексты драйвера. Меня ввела в заблуждение вот эта его часть:

Код: Выделить всё

    if (c->mtd->type == MTD_NANDFLASH) {	
        /* Initialise write buffer */	
        c->wbuf_pagesize = c->mtd->oobblock;	
        c->wbuf_ofs = 0xFFFFFFFF;	
        c->wbuf = kmalloc(c->wbuf_pagesize, GFP_KERNEL);	
        if (!c->wbuf)	
            return -ENOMEM;	
 	
        /* Initialise process for timed wbuf flush */	
        INIT_WORK(&c->wbuf_task,(void*) jffs2_wbuf_process, (void *)c);	
 	
        /* Initialise timer for timed wbuf flush */	
        init_timer(&c->wbuf_timer);	
        c->wbuf_timer.function = jffs2_wbuf_timeout;	
        c->wbuf_timer.data = (unsigned long) c;	
    }

однако исходников самого процесса я найти не смог. Скорее всего, он просто еще не написан.

Executier

Должна же существовать jffs2_wbuf_process, иначе бы она не скомпилилась, или я туплю?Ничего, что я про оффтопик? :).

Таки разобрало любопытство про arch/arm/mach-pxa/sharpsl_battery.c
Скачаю в ближайшее время..

Еще прикол.
Если тип устройства MTD_NANDFLASH, то делается следующее
/* Initialise process for timed wbuf flush */
INIT_WORK(&c->wbuf_task,(void*) jffs2_wbuf_process, (void *)c);
А если тип файловой системы не jffs2, то он все равно подрубит jffs2_wbuf_process, что, по-моему, неправильно....
Объясните ламеру, где я не прав.

Neopes · Сообщение **Neopes** » Чт ноя 18, 2004 01:29

2 Executier:
Под pdaXrom смотреть видео можно. мплеер без проблем играет видео с битрейтом 600-700. вот так вот.

ВадимП

Если есть поддержка этой фс в ядре, то должен быть и процесс (как есть процесс для "сборки мусора"). Процесс порождается при монтировании фс. Сейчас там стоит "заглушка".

Executier

Да я про странное имя у заглушки. Вот еслиб они доделали и имя бы кореллировалось с функцией, то были бы проблемы, нет? Просто странно одну заглушку прилеплять ко всем файловым системам. Понятное дело, сейчас это работает. Но вот если бы доделали? У обычных пользователей это бы не принесло проблем. А вот я хотел поставить ext3...
Я бы так не в жизни не сделал и каждой файловой системе прилепил бы по заглушке, разве я не прав?

ВадимП

Executier писал(а):Еще прикол.
Если тип устройства MTD_NANDFLASH, то делается следующее
/* Initialise process for timed wbuf flush */
INIT_WORK(&c->wbuf_task,(void*) jffs2_wbuf_process, (void *)c);
А если тип файловой системы не jffs2, то он все равно подрубит jffs2_wbuf_process, что, по-моему, неправильно....

До меня только сейчас (как до жирафа) дошло, что Вы имели в виду: это же была выдержка из подпрограммы инициализации в драйвере jffs2. Она вызывается только при монтировании раздела с этой файловой системой. Никакого отношения к разделам других фс она не имеет.

maslovsky

ВадимП писал(а):Немного поясню по поводу "особенностей" (может кому будет интересно, хотя вряд ли): драйвер устанавливает таймер, который обнуляется при каждой записи в файловую систему. Если значение таймера достигает WBUF_FLUSH_TIMEOUT, то sync() вызывается автоматически...
А это значение по умолчанию установлено в 2 секунды. То есть, если записи в файловую системы не было хотя бы 2 секунды, то все буфера сбрасываются.
Поскольку в Вашем примере запись происходила в файл в домашней директории - значит необходимости в явном вызове sync не было...

Скажу больше - Шарп перстраховался не на 100% и даже не на 200% - в системе запускается специальный процесс под названием shsync, который каждые несколько секудн сбрасывает буфера.

Более того, в шарповском ядре еще и принудительно было выключен весь асинхронный ввод/вывод.

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

Executier

Тааак, я, конечно, извиняюсь за оффтопик, как это async io выкинули? Вообще везде выкинули? Т.е. я, например, напишу прогу с неблокируемыми сокетами, а она во время работы возмет и заблокируется ядром? Или в cacko это пофиксили? Кроме того, висит же bdflush, разве не этот процесс все и вся синхронизирует?

maslovsky

Кстати, Вадим, Вы на меня потратили больше времени чем требуется на доработку этого аплета или вправления ядерной таблицы. Осталось только подправить вышеуказанную мной функцию и делов-то. Я думаю, последний шаг не вызывает сомнений в свое простате?

Конечно, удивительно даже, что никто до сих пор этого не сделал. Похоже, все вокруг лохи, а ни какие не настоящие линуксоиды...

ВадимП

Executier писал(а):Кроме того, висит же bdflush, разве не этот процесс все и вся синхронизирует?

Скорее kupdated.

ВадимП

ВадимП писал(а):
Executier писал(а):Кроме того, висит же bdflush, разве не этот процесс все и вся синхронизирует?
Скорее kupdated.

Маленькая цитата, чтобы лучше это понимать:

When a process writes to disk, the kernel does not necessarily write the data to disk immediately. Instead, it updates its in memory copy of the block, but defers the disk update until later (an exception to this is files that are open for synchronous writing). There are two kernel threads that handle these deferred updates: bdflush and kupdate. [1]

The bdflush thread writes updates to disk when either of two conditions occur. One condition that can cause bdflush to update the disk is when the virtual memory system is having trouble finding enough free memory to satisfy allocation requests. In this case, the VM system will ask bdflush to free pages by flushing the written data to disk (thereby freeing the buffer space used by that data). The other event that will cause bdflush to update the disk is when the fraction of dirty buffers (those containing modified data which has not been updated on disk) in the buffer cache exceeds a threshold. This is described in Documentation/filesystems/proc.txt.

The other kernel thread that deals with flushing modified data to disk is kupdate. In normal usage, kupdate periodically writes modified buffers to disk. The period is set using the fifth field in /proc/sys/vm/bdflush. The value is specified in hertz. So on most Linux systems, which use a hertz value of 100, a value of 500 in the fifth field of /proc/sys/vm/bdflush would means that kupdate will flush dirty buffers to disk every 5 seconds.

The kupdate thread supports another mode of operation as well. It listens for SIGSTOP and SIGCONT signals. On receiving a SIGSTOP signal, kupdate stops its periodic operation, and instead, waits for SIGCONT. When it receives SIGCONT, it will flush dirty buffers. A similar effect can be achieved by setting the period for kupdate to 0 instead of sending the thread SIGSTOP. This mechanism enables a user space process to implement some other policy for when buffers are flushed.

In addition to these methods for flushing buffers, processes can specifically request that buffers be flushed to disk by using the sync(), fsync(), and fdatasync() system calls.