HPC.ru lite - Все форумы
Форум: Периферия и карты памяти CF, SD, MMC
Тема: Вопрос по емкости карты SD 512
Страницы: [1] 2

[Ответить]
GRN [24.07.2005 08:20] Вопрос по емкости карты SD 512:
карточка SD 512 MB, вставил в кпк показывает емкость карты 488.2 МБ, тоесть меньше чем должно быть, отчего это может быть? дефект карты?
Leon89 [24.07.2005 12:05] :
это нормально, так и должно быть. если вставишь карту 1024Мб она покажет около 950Мб и тка далее
Gluek [24.07.2005 19:37] :
А где вы видели надписи на картах 1024 Мб?
GRN [24.07.2005 22:06] :
(512*1,000,000)/(1024*1024)=488,28125 ну так и получается...только не понятно зачем производителям это надо, 24 мега отрезать от карточки они же их печатным способом делают...
Leon89 [25.07.2005 14:38] :
во-во!
CF www.xitech.ru/product.php?pid=10395

SD www.xitech.ru/product.php?pid=11404
Voice [26.07.2005 19:31] :
вот тока что мне привезли 2-х гиговую apacer. В мануале написано
Общий смысл такой, что размер файла на карте может быть меньше, чем указан на коробке, т.к. в разных ОС используются разные системы и алгоритмы управлением файлами. А так же из-за того, что некоторое место зарезервировано под битые блоки
GRN [27.07.2005 19:52] :
тогда выходит по аналогии с увеличением объема ХДД теоретически можно как-то разлочить и эту память...
Fer_re [27.07.2005 23:10] :
А вообще по моему эти 10-20 MB ничего особо не решают. Вопрос на мой взгляд в том, действительно ли система использует это место на файловую систему или изготовитель его отрезает?
ВадимП [28.07.2005 02:29] :
В принципе, вопрос уже неоднократно обсуждался, но позволю себе кратко повторить следующие очевидные соображения:
Если оставить в стороне вопрос о количестве байтов в мега/гигабайте (эта причина "недостачи" наверное уже всем понятна) и утверждения о том, что часть пространства на картах secure digital зарезервирована под нужды системы обеспечения защиты от копирования (это выглядит вполне возможным, но об устройстве этой системы я, к сожалению, ничего не знаю), то всё равно обнаружится разница между ёмкостью карты и количеством свободного месте на ней.
Причина этого очень проста.
Когда производитель продает Вам карточку, он указывает общее количество информации, которое она может вместить.
В то же время, программы в основном показывают Вам количество информации (например, размер свободного места) в файловой системе на этой карточке.
А понятно, что это не одно и то же.
Карточка, которую Вам продали, никогда не бывает абсолютно пустой.
Несмотря на то, что на ней нет ни единого файла.
Давайте пойдем по порядку:
Самый первый сектор карточки.
Это MBR - главная загрузочная запись. Поскольку флеш-карточки никогда не используются для загрузки, то единственная полезная информация там содержится в таблице разделов. На карточке всегда бывает создан один-единственный раздел, который занимает всё остальное пространство карточки.
Значит один сектор (512 байтов) уже долой - он занят и ничего в него не запишешь.
Дальше начинается собственно раздел.
Однако, вовсе не факт, что он начнется со следующего сектора. Дело в том, что flash-карточка с точки зрения драйвера весьма похожа на жесткий диск и точно так же как жесткий диск имеет логическую геометрию. То есть состоит из какого-то числа головок/дорожек/секторов.
При этом емкость карты в секторах считается как число головок * число секторов * число дорожек.
MBR всегда расположена в первом секторе (сектора отчего-то нумеруются с единицы) на нулевой головке нулевой дорожки (всё остальное нумеруется с нуля). А разделы принято располагать так, чтобы они занимали целое число дорожек. Поэтому может оказаться так, что между MBR и первым сектором раздела окажется какое-то количество т.н. "резервных" секторов.
Я сейчас специально проверил единственную свою FAT16 карточку на 512МБ и на ней оказалось 40 резервных секторов (на всех остальных карточках у меня другая файловая система, а эта из фотоаппарата).
После этого начинается собственно раздел.
Однако не надо думать, что всё место там свободно и его можно занимать под файлы. Отнюдь.
Начинается этот раздел (вся информация дальше относится к файловой системе FAT) с загрузочной записи (boot record). Она осталась еще со времен 360 килобайтных дискет и по большей части содержит код загрузчика (сейчас уже даром никому на этих карточках не нужный) и кое-какие сведения о системе. Останавливаться подробно я на этой зписи не вижу смысла, упомяну только, что она тоже может занимать больше одного физического сектора - в FAT32 она занимает 3 сектора, причем в одном из них хранится копия загрузочной записи на всякий случай.
Прежде чем перейти к дальнейшему изложению хорошо известных большинству читателей вещей, я напомню общеизвестный факт, что в таких простых файловых системах как FAT, дисковое пространство всегда выделяется кластерами - цепочками блоков фиксированной длины (в более сложных файловых системах это не всегда так).
Значит ОС, во-первых, должна иметь возможность как-то отличать свободные кластеры от занятых. Помечать дефектные. Если файл занимает собой несколько кластеров, то должна быть возможность, зная имя файла проследить всю цепочку этих кластеров.
В FAT это достигается путем использования т.н. таблицы размещения файлов ("file allocation table") от аббревиатуры которой, собственно, и произошло название этой файловой системы.
Размер этой таблицы может быть разным, но максимально он может составлять для FAT16 (16 - потому что каждый элемент имеет величину 16 бит) 65,526 кластеров (это число отлично от 2 в 16-ой == 65,536 потому что 10 номеров кластеров зарезервированы. Номера 0 и 1 не используются - нумерация кластеров данных начинается с 2, а старшие номера зарезервированы для обозначения дефектных секторов).
Таблица размещения файлов сама по себе занимает целое число секторов. Это количество указано в boot record поэтому файловая система легко может определить место, где таблица размещения заканчивается.
Если элемент таблицы имеет размер 16 бит (2 байта), то в секторе размещается 256 элементов.
Таким образом, каждая копия FAT может занимать вплоть до 256 секторов.
Говорю "каждая копия" потому, что таблица размещения жизненно важна для поддержания целостности файловой системы и поэтому их по умолчанию создается две штуки.
Значит можно вычеркнуть еще вплоть до 512-ти секторов из величины оставшегося свободного места.
Но и это еще не всё. Кроме цепочки кластеров, занимаемой файлом, надо хранить где-то и другую информацию о нем: имя, размер, дату создания, атрибуты, номер первого кластера в цепочке (чтобы иметь возможность из множества цепочек FAT выявить нужную). Эти данные хранятся в директориях (которые пользователи windows обычно называют "папками", а потом удивляются, что на линукс-каналах люди изображают вежливое недоумение и делают вид, что не понимают о чем идет речь).
Сведения о самих директориях хранятся в родительских директориях. Сведения о "самых-самых-самых родительских" хранятся в корневой.
Сведения о корневой хранить было уже негде, поэтому авторы FAT решили, что она будет создаваться непосредственно при создании файловой системы.
Поэтому еще часть секторов занимает корневая директория. Она опять-таки может иметь разный размер, но обычно в ней достаточно места для хранения информации о 500 файлах (если быть точным, то там есть место для 512-ти записей, но, скажем, метка тома - это тоже запись, поэтому для записей о файлах и субдиректориях места остается меньше. В FAT32 размер корневой директории не ограничен).

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

Поэтому всё это длинное и нудное сообщение было написано с одной-единственной целью: показать, что безнаказанно сэкономить на служебных структурах файловой системы нельзя. Тем более, что в FAT они и так занимают, как видите, очень немного места.
[CpD]bob [28.07.2005 15:12] :
Вот стирать точно не надо. Написано крайне интересно и познавательно, это надо поместить в FAQ, потому что подобные вопросы возникают с пугающей регулярностью. Такой обстоятельный и методичный подход убедит любого...
[Ответить]
[Вперед >]