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] :
A_M_B писал(а):
Другое дело, если написано конкретно "1024 Мб" - почему их там 950 ?
А где вы видели надписи на картах 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. В мануале написано
The memory size of flash card may appear to be smaller than what is stated on the package. The discrepancy mainly arises from different file managements and algorithms run by different operating systems, and also from the reserved space for error-block.
Общий смысл такой, что размер файла на карте может быть меньше, чем указан на коробке, т.к. в разных ОС используются разные системы и алгоритмы управлением файлами. А так же из-за того, что некоторое место зарезервировано под битые блоки
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, потому что подобные вопросы возникают с пугающей регулярностью. Такой обстоятельный и методичный подход убедит любого...
[Ответить]
[Вперед >]