[СИ] Длина сектора диска

К счастью, современные диски всегда записывают сектор целиком.

Согласен.
Но согласитесь и Вы, что нет-нет да кое-где
встречаются диски похуже.
Из статьи http://www.sqlite.org/atomiccommit.html
следует, что SQLite-щики не доверяют дискам.
И всё-таки хотелось бы получить ответ на вопросы.

1. Практически невозможно. Файловая система может находится в нескольких уровнях абстракции от физических дисков, при этом на каждом уровне могут быть свои размеры секторов, или даже различные размеры в пределах одного уровня. Кстати, те самые SQLщики просто определили себе константу и не стали заморачиваться дальше :) Можно поковырять в сторону ядерных АПИ, но толку от этого мало.

2. Должно сработать. Еще лучше - позволить пользователю самостоятельно указать размер сектора (а так как практически все современные жесткие диски имеют размер сектора в 512 байт, можно использовать это значение по умолчанию).

Спасибо

> К счастью, современные диски всегда записывают сектор целиком.

Вы слишком хорошего мнения о современных дисках

О плохих и хороших дисках.
Если строка занимает несколько секторов,
то даже при хорошем диске нужно делать
откат по журналу (не все секторы успели).
А выбрав правильный диапазон данных,
сохраненных в журнале, можно ещё и
подстраховаться от плохого диска.

>а так как практически все современные жесткие диски имеют размер сектора в 512 байт

вот из-за таких людей у нас сейчас проблемы с 4kb секторами.

Задал эту же тему на форуме
http://www.opennet.ru Программирование под UNIX
Вот получил такой ответ:

Если ты пишешь файловую систему, то придётся узнать,
что размер блока у разных устройств разный. У кого 512 байт,
у кого 64К, а у кого и 4М.
Некоторые устройства пишут не секторами, а дорожками целиком.
У некоторых устройств нет прямого доступа к буферу дорожки.
То есть в момент слёта по питанию в худшем случае ты теряешь дорожку,
а не блок. Особо низкоуровневые устройства дают возможность видеть дорожки
с разной длиной и скоростью обмена (наружные/внутренние).

Может ли кто-нибудь что-то сказать об этом.

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

Потому я и советовал позволить пользователю самостоятельно указать размер сектора, на случай если у него пишется дорожками по 4МБ.

Но я так пологаю, использование «особо низкоуровневых устройств с дорожками разной длины» несколько выходит за рамки вашего исследования? Или нет?

Я предложил не константу, а изменяемый параметр, то есть как раз учел ваши 4кб секторы. А 512 байт - это только значение по умолчанию, для простых десктопных убунтоводов :)

x905
Хотелось бы написать простую специализированную
базу данных.
Под специализированной понимается:
не универсальная, для конкретного приложения.
Отсюда и ожидаемая простота.
Много чего не понимаю.

«возможно она уже решена, или есть типовые решения
если конечно цель не попробовать самому все написать еще раз»
Да. Это так.

Поясню:
Появилось желание.
Я делаю первые шаги узнать, насколько реальное.
Понимаю, что бывают задачи
-не разрешимые
-не посильные
-не оправданно трудные
Но никто ещё не убедил меня ни в одном из этих трёх.


ddos3
Частично с Вами согласен в том, что этот параметр
надо вынести в настройки для «продвинутого» пользователя.
Но вот здесь на форуме не найден исчерпывающий ответ
о длине сектора, и возлагать эту обязанность на
обыкновенного пользователя не согласен.

Задача 1 о файле-счетчике и вопрос о длине сектора
это, по моему, очень трудные задачи, т. к. выходят за
рамки прикладного программирования.

Да, низкоуровневые устройства за рамками исследования
(я этим никогда раньше не занимался). Предполагалось
решить все проблемы в прикладной программе.
Но собрать побольше сведений о возможном желательно.
Человека, написавшего 4 Мб, я попросил дать ссылки
подробнее ознакомиться. Если откликнется.
Знаю, что «флэшки» пишут большими блоками, может
он это имел в виду.

x905
Добавлю еще.
Самодельная простая база данных
существует и прекрасно работает.
До поры - до времени.
Эта, с позволения сказать, база данных
основана на предположении, что
никаких сбоев нет и быть не может.
Чёрная сторона этого - частое резервное копирование
и вечный страх неприятностей.