Почему файл после многократного количество циклов записи перестает быть доступен для открытия (fopen)?

Question

[Вадим Дерябкин]

Здравствуйте. Задача - открывать файл-образ fat32 flash накопителя и читать/записывать данные и него/в него. Данные читаются или записываются блоками по 512 * n байт. Выхода за пределы файла гарантировано быть не может (по сути, имитируется доступ к аппаратному flash накопителю, с которым работает fatfs).
Имеется:
Операционная система: Ubuntu 18.04.3 LTS, x64
Файл (образ fat32 micro-sd на 256 мегабайт), созданный следующей последовательностью команд:

$ sudo dd if=/dev/zero of=microsd.img bs=512 count=524288
$ sudo mkfs.fat -F32 -v -I microsd.img
$ sudo chmod 777 microsd.img
$ sudo chown user_name:user_name microsd.img

Программа собирается с флагами:

-m32 -O0 -g3 -fdata-sections -ffunction-sections -Wl,--gc-sections  -std=gnu99

Программа должна быть обязательно собрана под x32, по-этому флаг -m32 обязателен (целевая платформа 32-х битная).

Файл успешно создается, его чтение-запись из системы происходит успешно на всем объеме (скидывал на накопитель файл близкий ко всему объему и вычитывал обратно).
Чтение/запись в файл/из файла осуществляется следующим кодом:

// Путь до файла верный, работа ведется только с 1 файлом.
const char FILE_MICROSD_PATH[] = "../resurse/microsd.img";

// Размер блока стандартные 512 байт.
#define SD_BLOCK_SIZE 512
static FILE *sd = NULL;

int sdio_write (const uint32_t *buf, uint32_t block_num, uint32_t num_block) {
    if ((sd = fopen(FILE_MICROSD_PATH, "r+b")) == NULL) {
        return -1;
    };

    if (fseek(sd, block_num*SD_BLOCK_SIZE, SEEK_SET) != 0) {
        fclose(sd);
        sd = NULL;
        return -1;
    }

    if (fwrite(buf, SD_BLOCK_SIZE, num_block, sd) != num_block) {
        fclose(sd);
        sd = NULL;
        return -1;
    };

    int rv = fclose(sd);
    sd = NULL;
    return rv;
}

int sdio_read (uint32_t *buf, uint32_t block_num, uint32_t num_block) {
if ((sd = fopen(FILE_MICROSD_PATH, "r+b")) == NULL) {
        return -1;
    };

    if (fseek(sd, block_num*SD_BLOCK_SIZE, SEEK_SET) != 0) {
        fclose(sd);
        sd = NULL;
        return -1;
    }

    if (fread(buf, SD_BLOCK_SIZE, num_block, sd) != num_block) {
        fclose(sd);
        sd = NULL;
        return -1;
    };

    int rv = fclose(sd);
    sd = NULL;
    return rv;
}

Если запустить запись множество раз подряд, то в какой-то момент при следующем открытии файла fopen будет возвращать ошибку. Всегда на одном и том же месте при запуске без отладки. Однако, если включить отладку и ставить точку остановки перед открытием файла, то весь цикл открытия, записи или чтения будет проходить успешно и никаких ошибок не будет. Отсюда напрашивается желание поставить некоторую задержку после закрытия файла. Например, 100 миллисекунд. Но это не спасает ситуацию (да и не правильно). Если какой-то способ решить данную проблему нормальными способами? Может есть функция, сообщающая о том, что файл действительно был закрыт и к нему можно обратиться снова или что0то подобное?
P.S. Файл гарантировано закрывается после каждого обращения, возвращая при этом флаг успешного закрытия.

Answer 1

[Karpion]

Исследовать код завершения оператора fopen().
Проверить, как оно работает при задержке "100 миллисекунд" или больше.

Comments

[Вадим Дерябкин]

Задержки до секунды точно не помогают. А вот про исследовать код... Я что-то и не подумал. В errno же должно писаться какой-то значение при возвращении NULL Сейчас проверю.

[Вадим Дерябкин]

После возвращения NULL из fopen в errno -переменной пусто.

[Вадим Дерябкин]

Попробовал поставить последний GCC-9 (ну и G++, multilib). Толку не дало. Хотя читать/писать стало на несколько секторов дальше.

[Вадим Дерябкин]

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

if (fflush(sd) != 0) {
        fclose(sd);
        sd = NULL;
        return -1;
    }

[Karpion]

1) Мне не нравится static FILE *sd Я бы сделал локальные переменные внутри обеих функций. При многопоточном программировании со статическими переменными - можно поиметь проблему.
До кучи можно указать, что они регистровые.

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

3) "После возвращения NULL из fopen в errno -переменной пусто." - противоречит мануалу. Я понимаю, что реальность сильнее мануала - но такого быть не должно. Напишите актуальный на данный код вместо старого в головном посте.

4) Кстати, errno - статическая. Т.е. при многопоточном программировании - её может затереть другой поток.

5) По правилам хорошего тона - в зависимости от того, где произошла ошибка, надо возвращать разные значения. Не "-1", как Вы сделали, а разные.

6) Попробуйте отказаться от оптимизации при компиляции. См.пункт 2.

7) Проверьте код завершения fclose().

8) Можно попробовать работать без буферизации. Ваш стиль работы с файлом - как бы намекает, что надо использовать open(), close(), read() и write() - без "f" в начале. Заодно избавитесь от от лишних расходов на буферизацию в user-space, которые здесь бесполезны.

[Вадим Дерябкин]

1) Мне не нравится static FILE *sd Я бы сделал локальные переменные внутри обеих функций. При многопоточном программировании со статическими переменными - можно поиметь проблему.
До кучи можно указать, что они регистровые.

С файловой системой гарантировано работает один поток. Но согласен. Просто изначально была мысль открывать файл в начале и закрывать в конце (работы приложения). Но это оказалось плохой идеей, поскольку приложение по сути является бесконечным и его остановка по Ctrl + C не даст должного эффекта (файл не будет закрыт и что там будет на момент закрытия - не ясно). Про пункт - сделаю локальной в каждой функции. Сейчас это уместно.

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

Хорошо. Попробую.

3) "После возвращения NULL из fopen в errno -переменной пусто." - противоречит мануалу. Я понимаю, что реальность сильнее мануала - но такого быть не должно. Напишите актуальный на данный код вместо старого в головном посте.

Это возможно из-за того, что в приложении еще крутится планировщик, который меняет контекст задач (да, сейчас в приложении много потоков, один из которых работает с файловой системой. Это пусти запущенная ос (freertos) как приложение под linux). Он мог так же перетирать errno. Сейчас оставлю только базовый поток (в котором main) и отключу вообще весь функционал ОС. Чтобы убедиться что планировщик не виноват (я расставлял перед обращениями к fopen/fclose переход в критическую секцию, чтобы гарантировать, что контекст не будет переключен, но все же лучше вообще сейчас избавиться от всего лишнего).

4) Кстати, errno - статическая. Т.е. при многопоточном программировании - её может затереть другой поток.

Сейчас оставлю один поток, как сказал выше, и проверю еще раз.

5) По правилам хорошего тона - в зависимости от того, где произошла ошибка, надо возвращать разные значения. Не "-1", как Вы сделали, а разные.

Тут не соглашусь. Эти функции являются прослойкой имитации работы с аппаратной периферией. И драйверу, который находится выше, все равно, какой код ошибки будет возвращен (FatFS). Для него все, что не 0, это ошибка и логика действий при этом одна и та же.

6) Попробуйте отказаться от оптимизации при компиляции. См.пункт 2.

Уже -O0 -g3. Писал об этом, когда перечислял флаги.

7) Проверьте код завершения fclose().

Он всегда возвращает 0. В errno так же пусто. Сейчас проверю без ОС, лишних потоков и прочего еще раз.

8) Можно попробовать работать без буферизации. Ваш стиль работы с файлом - как бы намекает, что надо использовать open(), close(), read() и write() - без "f" в начале. Заодно избавитесь от от лишних расходов на буферизацию в user-space, которые здесь бесполезны.

Соглашусь. На худой конец попробую и это.

[Вадим Дерябкин]

Так. Убрал все лишнее. Все потоки, ОС-имитацию. Оставил только выше приведенные функции. Поведение не изменилось. В errno так же пусто (0). Попробую вариант с open/write/read/close.

[Karpion]

изначально была мысль открывать файл в начале и закрывать в конце (работы приложения). Но это оказалось плохой идеей, поскольку приложение по сути является бесконечным и его остановка по Ctrl + C не даст должного эффекта (файл не будет закрыт и что там будет на момент закрытия - не ясно).

Ну, держать файл всё время открытым - мне нравится.

Любое завершение процесса - приводит к закрытию всех открытых им файлов. На уровне fd=open() - закрытие всегда корректное. На уровне fp=fopen() - закрытие корректное в большинстве случаев (по kill -9 - думаю, будет некорректно); ну так на то надо делать fflush().
И вот тут я бы советовал открыть файл один раз, но через fd=open(), избежав проблем с user-space буферами.

[Вадим Дерябкин]

Успех. Цель достигнута. В итоге работает адекватно с open/write/read/close. Рабочий код выглядит так.

int sdio_read (uint32_t *buf, uint32_t block_num, uint32_t num_block) {
    int sd = open(FILE_MICROSD_PATH, O_RDONLY);
    if (sd == -1) {
        return -1;
    };

    int rv = lseek(sd, block_num*SD_BLOCK_SIZE, SEEK_SET);
    if (rv != block_num*SD_BLOCK_SIZE) {
        close(sd);
        return -1;
    }

    ssize_t read_byte_num = 0;
    while (read_byte_num != SD_BLOCK_SIZE*num_block) {
        ssize_t real_read_byte_num = read(sd, &buf[read_byte_num], SD_BLOCK_SIZE*num_block - read_byte_num);
        if (real_read_byte_num == -1) {
            close(sd);
            return -1;
        }

        read_byte_num += real_read_byte_num;
    }

    rv = close(sd);
    return rv;
}

int sdio_write (const uint32_t *buf, uint32_t block_num, uint32_t num_block) {
    int sd = open(FILE_MICROSD_PATH, O_WRONLY);
    if (sd == -1) {
        return -1;
    };

    int rv = lseek(sd, block_num*SD_BLOCK_SIZE, SEEK_SET);
    if (rv != block_num*SD_BLOCK_SIZE) {
        close(sd);
        return -1;
    }

    ssize_t write_byte_num = 0;
    while (write_byte_num != SD_BLOCK_SIZE*num_block) {
        ssize_t real_write_byte_num = write(sd, &buf[write_byte_num], SD_BLOCK_SIZE*num_block - write_byte_num);
        if (real_write_byte_num == -1) {
            close(sd);
            return -1;
        }

        write_byte_num += real_write_byte_num;
    }

    rv = close(sd);
    return rv;
}

[Karpion]

Ну, я бы всё-таки открыл файл один раз на всю сессию. Прервать работу Вашей программы можно и в момент, когда файл открыт, в т.ч. в момент выполнения read()/write().

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

[Вадим Дерябкин]

Karpion, полагаю, во всем виноват -m32 для сборки под x32. Он необходим, потому что у меня там freertos-имитация. А он (freertos) рухнет, если собрать под x64. Там грязные хаки с указателями во имя скорости и запрет собираться под x64 от разработчиков.