С++ vs прямая запись на флешку

использование MJPEG обусловлено тем, что у меня их куча образовалась + вроде как лучше для качества картинки в архиве + говорят распознавание с такого потока точнее

непонятно причем тут с++ и зачем давать по 32 байта на «временную метку» и тем более на «адрес физического блока». такой длиной адреса удобно атомы во вселенной адресовать.

критика тут простая. то что ты хочешь сделать это куцая флешевая файловая система.

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

1. надо позаботиться о минимальном количестве операций записи в блоки.
2. использование блоков должно быть равномерным
3. никакого специального журнала быть не должно. вся инфа о связи блоков в файл, или последовательность лежит внутри блока данных.

то есть все блоки флешки равноправны, в них можно писать данные, некоторые блоки помечены как бэдблоки в заголовках.

непонятно причем тут с++

при том, что это все на gcc надо наваять мне

зачем давать по 32 байта на «временную метку»

ну как бы число с плавающей точкой, чтобы не делать преобразований

тем более на «адрес физического блока»

потому как физический блок надо писать 1 раз целиком, нельзя что то добаписать иба он стирается и пишется заново весь, а раз размер 512 байт, то вопщим то все равно метка делает пратически пустой блок

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

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

вот собсна https://habr.com/ru/company/dsol/blog/504380/

ну как бы число с плавающей точкой, чтобы не делать преобразований

1.время отродясь не было плавающим числом. 2.даже double в С++ 8 байт. 3.если есть журнал..и ты его все время пишешь вместе с блоками данных - ты блоки журнала первыми и убьешь.

alysnix

ога! тупанул я, с битами перепутал )))

блоки журнала предполагаю пишутся по 512 байт, в котором одна метка времени + адрес блока т.е. 16 байт всего лишь занято, размер журнала всегда конечной длины.

т.е. как бы надо 2 условия соблюсти

1. максимальный ресурс флешки
2. максимальная скорость ПОСЛЕДОВАТЕЛЬНЫХ записи и чтения

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

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

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

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

а вообще надо об этом подумать, спасибо

моя фс работала на 16 кажется мгц. и 16 битном проце, насколько я помню. но она была полновесной фс с дирами, и файлами.

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

в твоем случае и бедблоков то не будет небось. накопитель будет ремапить физблоки тебе.

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

согласен, можно и меньшие ресурсы использовать, но у меня вопрос адекватности времени работы важен, надо тестировать за сколько сд карты будут читаться объемом 64-128Гб, с другой стороны в целом нет жесткого ограничения именно на первый запуск

Плохая идея. Воспользуйся ФС созданными специально для флешек. Там все фичи уже есть.

физические блоки на дешевых флешках обычные 512 байт

Там же запись страницами идёт, а не блоками.

Посмотри ролик Cluster про создание картриджа-многоигровки для NES. Он там решал проблему усиления записи для флеша.

https://www.youtube.com/watch?v=VihgDVlgBY0

Вроде тут тоже https://www.youtube.com/watch?v=LwKKMoTirSo

ox55ff

Гугл говорит нет таких

Radjah

Спасибо посмотрю, на Хабре пишут и странично и поблоково можно, хз в чем разница кроме размера

F2FS, например. Драйвер уже есть в ядре. JFFS ещё, но она уже старая.

F2FS практически ничем не лучше файловой системы ext4 https://xakep.ru/2016/10/10/f2fs-mythology/

хакер

Это не серьёзно. F2fs делает то что ты хочешь написать самостоятельно. Но уже отлажена и встроена в ядро.

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

Нет, мне не нужна фс как таковая вообще, мне нужно писать и читать покругу один большой файл на флешке, у меня нет случайного доступа и ограничен в объеме кеша в памяти

Какая фс на видео регистраторах? Вот в чем вопрос по большому счету

Автомобильных? Какой нибудь fat, чтобы юзер мог вставить флешку в комп с виндой и скачать видео. На взрослых видеорегистраторах что я видел была ext4. Но там диски hdd, а не флеш.

Нет, там не эти фс, они создают много лишнего мусора, в видеосерверах не выполняется никакое форматирование после установки нового диска

Да и подключение дисков оттуда никакой фс не находит

Лично видел. Диски как раз форматировать надо. Может тебе попался такой рег особенный.

Они не пишут на диск файлы в mp4. Создают несколько больших файлов неизвестного формата и внутри них пишут сырые h264 кадры. Ключевые кадры и промежуточные в разных файлах.

круговая запись регистратора самый щадящий для флехи режим, так что живут они долго. больший урон нанесет постоянная перезапись метаданных фс.
все прелести ntfs для авторегистратора нафих не нужны. прикладная необходимость в нтфс ext* и т.д. появляется только во флешках более 4 гб. нападал на статью в которой описывали как в нтфс отключить журнал и что-то еще для уменьшения лишних измывательств над ячейками.
намудрить что-либо хитроумно-долгоживущее для режима круговой записи практически практически не получится. потратишь время на разработку с практически нулевым (продление жизни флешки) финишным результатом.

у меня их куча образовалась + вроде как лучше для качества картинки в архиве + говорят распознавание с такого потока точнее

врут. MJPEG минимум в 10 раз жирнее чем H264 при аналогичном качестве видео. С H265 разница может быть ещё больше.