Я знаю, что в 32-битных системах самая большая память, которую мы можем иметь, составляет 4 ГБ (2 ^ 32). Но мне не ясно, что это означает с точки зрения файлов.
Я думаю, что мы можем иметь файлы произвольного размера на наших HD, не так ли? Намного больше, чем 4 ГБ. Так есть ли какие-либо предостережения в 32-битных системах и больших файлах?
Я предполагаю, что некоторые 32-разрядные программы не смогут загружать файлы размером более 4 ГБ или я не прав?
2
2 ответа
7
Это имеет значение, только если у вас есть приложение, которое пытается загрузить весь файл в память.
Программист, который делает это для таких больших файлов, должен быть застрелен. Есть лучшие способы.
Некоторое программное обеспечение может отрыгивать на очень больших файлах (большое значение> 2 гигабайта), но такое программное обеспечение обычно делает это и на 64-битных системах.
В большинстве случаев это связано с тем, что у программиста есть программное обеспечение, разработанное и протестированное с небольшими файлами. Программное обеспечение содержит логические ошибки, препятствующие правильной работе с очень большими файлами. Это не ограничение самой ОС.
(Очень распространенный пример - использование 32-значного числа со знаком для отслеживания позиции в файле, что создает проблемы на границе размером 2 ГБ.)
В случае вашего примера видео: в память обычно загружается только небольшая часть (фактически воспроизводимая часть и несколько дополнительных секунд буферизации). Обычно не более 2-3 мегабайт за один раз.
Что касается файлов произвольного размера на жестком диске: это не так.
Каждая файловая система имеет ограничения на максимальный размер любого отдельного файла.
Например, в случае Fat32 этот лимит составляет 4 ГБ на файл. NTFS имеет ограничение в 16 ТБ. Файловая система Linux ext3 имеет ограничение 16 ГБ, 256 ГБ или 2 ТБ в зависимости от того, использует ли файловая система блоки размером 1 КБ, 2 КБ или 4 КБ.
4
Я знаю, что в 32-битных системах самая большая память, которую мы можем иметь, составляет 4 ГБ (2 ^ 32).
Это не верно; для 32-разрядного ЦП вполне возможно использовать более 4 ГБ ОЗУ, также как для 16-разрядного ЦП можно использовать более 64 КБ ОЗУ. Напомним, что 16-разрядный 80286 мог адресовать 16 МБ через 24-разрядную адресную шину (в то время это считалось огромным объемом памяти; 80286 стал доступен в 1982 году, а в 1983 году появился первый 3,5-дюймовый жесткий диск). , спортивная емкость 10 МБ, а IBM PC AT, который был разработан вокруг Intel 80286, пришел с минимумом 256 KiB ОЗУ), и 1979-марочные Intel 8086 имели адресное пространство 1 МиБ (и при условии , вычислительная емкость исходного компьютера IBM 5150, который можно было бы обновить до того же объема оперативной памяти 256 КБ, что намного превышает собственный предел 16-разрядного адреса в 64 КБ). Посмотрите методы, такие как расширение физического адреса, переключение банков (которое, хотя и требовало осторожности со стороны программиста, было обычным явлением на ранних ПК и более ранних электронных компьютерах из-за его относительной простоты реализации; компьютер управления Apollo был разработан с переключением банков)) и сегментированные модели памяти, такие как модель сегментации памяти x86.
В конечном итоге ограничивающим фактором того, сколько памяти можно адресовать, не полагаясь на такие методы, является ширина собственной адресной шины ЦП, которая не зависит от собственной ширины слова ЦП или разрядности, как обычно упоминается. Было бы вполне возможно сделать ЦП, который работает с данными в 64-битных блоках (что сделало бы его 64-битным ЦП), даже если он имеет 16-битную адресную шину; Я не вижу реальных приложений для чего-то подобного, но технически это не противоречие.
Сейчас многие люди не беспокоятся об этих методах на 32-разрядных процессорах, потому что в то время, когда они были распространены на ПК, 4 ГиБ было действительно всем, что вам нужно, а 32-разрядные процессоры обычно имели достаточно широкие адресные шины, чтобы это проблема; даже 80386SX с ограниченными возможностями имел 24-битную адресную шину, позволяющую использовать 16 МБ адресного пространства в 1988 году, когда в том же году была введена установка 20 МБ для жесткого диска. Отсутствие необходимости беспокоиться сегментации, PAE и подобные методы делает жизнь намного проще на программиста. Однако 32-разрядное серверное программное обеспечение обычно предназначалось для обработки более 4 ГБ ОЗУ.
И, конечно же, для перспективы 16-разрядное программное обеспечение регулярно работало с файлами размером более 65 536 байт. Нужно немного подумать, если вы хотите, чтобы ваше программное обеспечение изначально работало с файлами, которые слишком велики, чтобы поместиться в отдельно выделенный блок памяти, но это определенно не невозможно.
Но мне не ясно, что это означает с точки зрения файлов. Я думаю, что мы можем иметь файлы произвольного размера на наших HD, не так ли? Намного больше, чем 4 ГБ.
Нет, вы не можете иметь произвольно большие файлы, даже если они ограничены доступным физическим пространством хранения: на самом низком логическом уровне файловая система накладывает ограничения на то, как большие файлы могут храниться, просто потому, что она должна иметь возможность хранить размер файла. подать куда-нибудь Точное ограничение зависит от файловой системы и иногда от настроек. В современных файловых системах, таких как NTFS, ext4 и т.д., Ограничения достаточно высоки, так что вы вряд ли поразите их одним диском, хотя это может быть проблемой, если у вас большой массив хранения. Например, NTFS (файловая система) поддерживает размеры файлов до 16 EiB, хотя реализация NTFS в Windows в настоящее время (искусственно) ограничена максимальным размером файла чуть менее 256 ТиБ (повышен с 16 ТиБ к выпуску Windows). 8 и Windows Server 2012).
16 TiB - не слишком большой объем памяти; Вы можете добиться этого, запустив, например, 7 дисков по 4 ТБ каждый в RAID-6, что, безусловно, вполне доступно финансовым возможностям даже для отдельных пользователей.
То же самое было сделано с различными редакциями Windows, искусственно ограничивая объем используемой оперативной памяти, даже несмотря на то, что базовая архитектура позволяла использовать гораздо больше.
Так есть ли какие-либо предостережения в 32-битных системах и больших файлах? Я предполагаю, что некоторые 32-разрядные программы не смогут загружать файлы размером более 4 ГБ или я не прав?
Это зависит от программного обеспечения и, в меньшей степени, от того, как оно работает со своими файлами данных, так что да, если рабочие слова являются определенными 32-битными программами, то ваше предположение почти наверняка верно. Опять же, некоторые 64-битные программы могут плохо работать с большими файлами. Я сталкиваюсь с этим иногда на работе; например, Microsoft Word 2010 для меня откажется загружать любой файл, размер которого превышает 512 МБ, даже если у меня будет гораздо больше памяти, чем доступно, если только я попытаюсь его использовать.
Если программное обеспечение пытается загрузить весь файл в память одновременно (чего на самом деле не должно) и не имеет искусственных ограничений, ограничивающим фактором в современных операционных системах будет доступный размер виртуальной памяти. (Примечание: виртуальная память и подкачка - это две совершенно разные вещи. Вы также должны учитывать чрезмерную загрузку памяти.) Если, с другой стороны, программное обеспечение загружает только часть файла в память одновременно, при условии, что сама ОС предоставляет средства для доступа к частям файла за пределами 32-битного размера 4 ГБ, а файловая система может в зависимости от размера файла, фактический размер файла не должен быть проблемой, и если это так, то это скорее всего ошибка программного обеспечения пользователя.