Majestio

И да ... при многопоточной записи в один файл - нужно предусмотреть примитивы синхронизации. Чтобы поток (процесс) прежде чем записать - проверил корректность последнего индекса и данных. И писал только в том случае, если он "нашел" или "опознал" что последний блок данных валидный.

Файл индексов имеет записи фиксированной длины. По ним и нужно пробегать. Искать данные в файле данных, сверять CRC в индексе и CRC сверяемого куска данных.

Выросла мочала, начинаем все с начала? ))) В чате я расписал как в пару итераций найти последний корректно записанный пакет. Как откусить некорректно записанные данные. Умываю руки )))

А в конце записи, при сбое, он некорректен и несогласован. И?

Давайте продолжим обсуждение в чате.

Максим, попробуй сам ответить на свой вопрос! Что нужно делать если последний индекс по величине смещения меньше предыдущего?

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

Искать в индексе - в порядки быстрее

zed, пост сдал! бб

Да, хэш сумма не гарантирует на 100%, но гарантирует на большое количество девяток в дробной части 99.(9)%. Можно два поля суммы впилить sha и md5. Вообще точно.

Ну-ну )))

zed, думаю это не нужно не только лишь во всех случаях, мало где это нужно :) Иными словами - если система кривая и косая, и пишет данные левой ногой.

А вот предложенный мною способ хорош тем, что, в случае сбоев не нужно последовательно (от начала и до конца парсить) битый массив информации, а наоборот с конца - это на порядки быстрее! Берем индекс, читаем данные, сверяем CRC. Не проходит - берем предыдущий. И до тех пор, пока текущий индекс и записанная CRC не совпадают. Потом "откусываем" битый хвост индекса и битый хвост данных. Все - данные в согласованном состоянии.

Предлагаю решать только то, что реально в "зоне ответственности" прикладной программы. Пример: корректно пишем на SSD, а через 2 дня диск умрет. Без дополнительных мер безопасности (чека целостности, зеркалирования, бэкапов) - эту задачу не решить. И не в Си, дело - даже на асме в лоб не решить.

Максим, попробуй сам ответить на свой вопрос! Что нужно делать если последний индекс по величине смещения меньше предыдущего?

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

Искать в индексе - в порядки быстрее

вы написали "я сделал вот-так, прав ли я?". Это для решения неудобно. Отредактируйте. пожалуйста, свой вопрос - выделив сам вопрос предложением (что вы решаете). И вторым предложением - "в чем вы не уверены". И второй важный момент - начните с однопоточной (потоконебезопасной) реализации и выделите проблемные куски.

Конвенция вызовов - это другая песня. Это про порядок запихивания в стек.

@Akina, такие проверки - лютый оверхед. Тем не менее, если нужно блочное выделение (читаем "проверок мало"), то почему бы и нет.

@Тарас, на курсах и в сообщении PashaPash - тебе сказали правильно, не всегда.

Вы чего, издеваетесь?!! Оставили блок отлова исключения в свой код и все! Когда будет "все плохо" (возникнет исключение) - туда и прилетит "точка выполнения". Никаких проверок, зачем тогда SEH придумали?

@Тарас, системный стек растет в сторону уменьшения адресов.

Кстати, по поводу возможной рекурсии ... задал еще один "непрактический" вопрос, просто ради любопытства - ru.stackoverflow.com/questions/609745/…

По "тамоншей" постановке задачи надо = несколько миллионов * [500..1000]

Для "обозначения практичности". Вопрос действительно пока "синтетический". А ноги растут из этой темы - forum.sources.ru/index.php?showtopic=410129 (и из моего ответа там forum.sources.ru/…). Просто вопрос заинтересовал.

Конечно, пусть будет уникальный ключ!

В порядке убывания "значимости": SQLlite, PostgreSQL, MySQL. Сделаете на любом - по любому буду оч благодарен!)

Перебор расстановок - только для первой пары. Потом n-j кратное сканирование. А "на всех диалектах" - чтобы хоть кто-то ответил, чтобы можно было от чего-то отталкиваться.

ABS(ABS(-1)-Abs(-1)) < ABS(ABS(-5)-Abs(4))

Пусть так: -1,-1,4,-5

Для меня важно - реализация на этих трех "диалектах", а как - это менее важно. И да ... пример для теста привел.

Хранимые процедуры MySQL могут как-то помочь?

По поводу "разных тегов" - интересуют любые решения "в рамках" данных тегов. Лучший вариант - решения для всех тегов. Пример сейчас постараюсь набросать.

И возможно не раз. и не два)

Так этож еще и сортировать нужно)))

Да. Чтобы исключить влияние ОС. Нужно будет обработать кусок данных примерно в 1Tb. Кусок один - зачем ему файловая система. Да и "ручное" размещение его более-менее гарантирует отсутствие "побочных эффектов" от ОС, как писал выше.

В общем, понял. Пока достоверной инфы мало - надо на пустой шлейф вешать тестовый веник, пройтись low-level форматом, и не форматируя его по ФС просто поэксперементировать с последовательным (а именно такое только и интересует) разными размеров блоков. Тогда будет ясно - нужен этот кэш в принципе или нет, ибо включенный кэш - это загрузка 3-го кэш проца контроллера. Может если его освободить от работы - так и трасфер поднимется :-\

А вот если произвольное чтение мелочи в пределах размера кэша HDD, то да - там аппаратный кэш вывезет.

Наиболее медленная операция - первая. Что нам с того, если кэш будет забит "фрагментированными" кусками? Если читаем в программный кэш большими блоками - аппаратный кэш будет всегда "грязный".

Вот блин))) Час от часу не легче) Да, там описывается дескриптор кэш таблицы. Однако можно обратить внимание, что данные адресуются LBA. Теперь надо искать формулы преобразования CHS->LBA, и везде ли они одинаковы. Я объясню почему... Нас интересует макс. быстродействие. Но процесс считывания зависти не только от RPM, но и от характеристик "считывателя". Грубо говоря, это цепочка действий 1) Позиционирование головки 2) Задержка 3) Поиск формат-метки 4) Чтение секторов.

@avp бегло читал, прочел что третий камень отвечает за кеширование. Но, или плохо читал, или одно из двух))) на свои вопросы ответа не нашел

Ну и более сложные вопросы, типа, "если последовательно читать первый и последний треки - они оба будут в кэше, или туда ложаться только данные с соседних треков?"

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

да видимо просто по ссылке

Ну вижу, норм!

Срфк = Char*, очепятка

начнем с того, где в Стандарте определен тип "строка"? Я имею ввиду не STL, а POD тип. Integer есть, Float, Double, Срфк есть ... Где определен String?

>Для широких строк, которые недавно были включены в стандарт

не льстите себе )))) она находит только нуль-байт)