[СИ] Длина сектора дискаЯзык СИ
ОС UNIXБаза данных и транзакция.
Два вопроса.Имеется файл строк, каждая строка это отдельная запись БД.
Нужно сделать транзакцию - изменить одну из этих строк.
При этом длина строки не меняется.
Должно выдерживать мягкий сбой (выключение питания).
Винт плохой и при сбое портит весь сектор (или иную минимальную порцию данных).
Значит я должен в журнале сохранить всё то, что может быть испорчено,
т. е. сектор (или секторы) содержащий эту строку.
Вопрос 1.О длине сектора.
Как узнать длину сектора или иной порции данных,
которая может быть испорчена?Вопрос 2.
Что если я буду для верности сохранять заведомо
большую порцию, а именнно 8 Кбайт, начало порции
кратно ей самой от начала файла.Сработает ли такой подход?
>Вопрос 1.Никак. Если делать не правильно можно файл целиком потерять легко.
>Вопрос 2.
сохранение (write) в файл не имеет ничего общего с записью на диск, независимо от размера записываемых данных. Для окончательной записи на диск записанных данных используются вызовы вроде fsync.
Извините. Я не достаточно понятно сформулировал
вопросы.
Да, т. к. речь идет об отключении питания, то
всё должно быть на диске, а не в буфере.
В моём вопросе подразумевалось:
write();
fsync();
всюду такая пара, при записи журнала и при записи изменений в файл.
И в момент записи на диск изменённых данных отключается питание.
Винт плохой и при сбое портит весь сектор (или иную минимальную порцию данных).
С учетом этого и надо понимать поставленные вопросы.
RAID с батареей + UPS с настроенным автопаркованием :)>[оверквотинг удален]
>всё должно быть на диске, а не в буфере.
>В моём вопросе подразумевалось:
>write();
>fsync();
>всюду такая пара, при записи журнала и при записи изменений в файл.
>
>И в момент записи на диск изменённых данных отключается питание.
>Винт плохой и при сбое портит весь сектор (или иную минимальную порцию
>данных).
>С учетом этого и надо понимать поставленные вопросы.
Программа может работать на разных машинах
и не всегда есть возможность выбора.
А если такая возможность будет,
тогда в настройках программы можно уменьшить
страховочные действия. Сейчас хотелось бы
заложить побольше, чтоб могла надежно работать
где угодно.
Всё-таки хотелось бы получить ответ на вопросы.
>Программа может работать на разных машинах
>и не всегда есть возможность выбора.
>А если такая возможность будет,
>тогда в настройках программы можно уменьшить
>страховочные действия. Сейчас хотелось бы
>заложить побольше, чтоб могла надежно работать
>где угодно.
>Всё-таки хотелось бы получить ответ на вопросы.Страховаться программно от сбоя по питанию? ))
Старая задачка: сколько нужно программеров чтобы поменять лампочку?
ОтвЭт: ниодного, это дело электриков.
>В моём вопросе подразумевалось:
>write();
>fsync();
>всюду такая пара, при записи журнала и при записи изменений в файл.
>
>И в момент записи на диск изменённых данных отключается питание.
>Винт плохой и при сбое портит весь сектор (или иную минимальную порцию
>данных).
>С учетом этого и надо понимать поставленные вопросы.тогда не делайте overwrite существующих блоков, а пишите новые. так делает ZFS:
http://en.wikipedia.org/wiki/ZFS#Copy-on-write_transactional...
(хотя зачем вы все это делаете, так до конца и не понятно)
>[оверквотинг удален]
>Как узнать длину сектора или иной порции данных,
>которая может быть испорчена?
>
>Вопрос 2.
>
>Что если я буду для верности сохранять заведомо
>большую порцию, а именнно 8 Кбайт, начало порции
>кратно ей самой от начала файла.
>
>Сработает ли такой подход?В зависимости от того, что ты хочешь получить. Если ты пишешь файловую систему, то придётся узнать, что размер блока у разных устройств разный. У кого 512 байт, у кого 64К, а у кого и 4М. Некоторые устройства пишут не секторами, а дорожками целиком. У некоторых устройств нет прямого доступа к буферу дорожки. То есть в момент слёта по питанию в худшем случае ты теряешь дорожку, а не блок. Особо низкоуровневые устройства дают возможность видеть дорожки с разной длиной и скоростью обмена (наружные/внутренние).
Если ты пишешь user space программу, то не лазь на уровень ОС - возьми подходящую файловую систему и занимайся прикладными проблемами.
Сверхнадёжные системы на коленке не делают. Занятие это дорогое и "плохие диски" в расчёт не берутся - этим занимается RAID, с батареями и прочими давно известными трюками.
Спасибо.
Это конкретный ответ на конкретный вопрос.Программа прикладная.
Я знаю, что "флэшки" пишут огромными блоками.
Но про диски, пишущие целыми дорожками,
я не знал.
Я исходил из того, что пишут в книгах и статьях о дисках,
а так же в статье SQLite
http://www.sqlite.org/atomiccommit.html.
В этой статье написано, что если можно от системы получить
длину сектора, то используют её. Иначе 512 байт.
Не могу сказать что удовлетворён
Вашим ответом.
Предполагается работа на арендованных
машинах-серверах. ОС UNIX, ufs.
Нигде не попадалось почитать о дисках
с такими большими блоками.
Может быть дадите ссылку или иную зацепку,
где можно что-нибудь найти об этом.Но всё равно спасибо.
>Предполагается работа на арендованных
>машинах-серверах. ОС UNIX, ufs.
>Нигде не попадалось почитать о дисках
>с такими большими блоками.EMC Clariion
Netezza SPU
>В этой статье написано, что если можно от системы получить
>длину сектора, то используют её. Иначе 512 байт.почемуто мне кажется что на уровне ФС будет правильнее исходить из размера statvfs.f_frsize (fundamental file system block size).
Спасибо за отклик.В этой и других структурах
stat
statfs
есть ещё поле длины блока f_bsize.
Я бы согласился взять даже большее из них (см. вопрос 2).
Как будто, я только получу некоторую избыточность, не страшно.Но вот сильно смущают слова ACCA о блоках 64K и 4M.
Хотелось бы узнать о таких устройствах.
Не может ли быть такого, что блок файловой системы
меньше физического сектора диска?
Для "флэшек" наверное может быть.
Но они не очень применяются на машинах-серверах.
А вот для дисков?После его заявления появился вопрос
вопрос 3
Не может ли быть такого, что блок файловой системы
меньше физического сектора диска?
>[оверквотинг удален]
>меньше физического сектора диска?
>Для "флэшек" наверное может быть.
>Но они не очень применяются на машинах-серверах.
>А вот для дисков?
>
>После его заявления появился вопрос
>
>вопрос 3
>Не может ли быть такого, что блок файловой системы
>меньше физического сектора диска?Например если взять последние жесткие WD которые с сектором размером 4k, но контроллер жёсткого диска эмулирует поведение диска с размером 512 байт, и при определённых обстоятельсвах это приводит к заметному падению скорости. Контроллеры RAID1 тоже пишут не по секторам хотя также прикидываются что сектор у них 512. Я к тому что драйвер может делать вид что у него размер 512 байт, на самом деле на устройство писаться будет совсем другими блоками. Флешка один из примеров. Контроллер RAID на устройстройство тоже не по сектору пишет. Сам контроллер жёсткого диска тоже не факт что по 512 байт пишет. А ещё может быть куча прослоек LVM, RAID, жесткий каждый со своим блоком буфером и прочими удовольствиями для повышения скорости.
И порция данных может быть испорчена в любом из этих мест.
От сбоев жесткого защищает RAID. От выключения питания журнал файловой системы. А для вас придумали fsync() и подобное. При возврате из которой вам сообщается что фс передала данные переданы драйверу блочного устройство которое заверило фс что данные размещены на носителе, после чего уже запускаются другие механизмы обеспечения целостности типа батарейки на RAID и подобного. И если например некто не поставв батарейку на RAID задействует кеш то там пропадут блоки на сотни мегабайт и все ваши ухищрения пойдут лесом, а программе они только добавят тормозов.