Почему я получаю 3 048 МБ от 64 МБ флэш-памяти?

По крайней мере 3 разных вещи могли объяснить, почему Вы передали больше данных, чем, возможно, возможно было сохранено на STB:

• Редкие файлы: Файлы всегда, кажется, содержат непрерывную последовательность байтов от запуска времени к текущей длине файла. Но можно создать (обычно двоичный файл) файл и только записать в определенные диапазоны байта. В этом случае пустые дыры между этими диапазонами байта (которые никогда не писались в), кажется, содержат байты с 0 значениями, когда считано. Файловые системы обычно замечают, когда программное обеспечение создает эти "дыры" и на самом деле не хранит дыры на диске. Таким образом можно создать 1 000 000-байтовый файл, записать единственный байт в положении 999999 и отметить, что файл составляет почти один мегабайт в размере, но только использует единственный блок дискового пространства.

  Определенные виды базы данных или индексных файлов могли бы обычно быть редкими, если формат файла призывает, чтобы определенные части файла были при определенных байтовых смещениях, но не все заполнено в.

  Копировальные устройства файла не могут сказать, что файл был редок в местоположении запуска, таким образом, они просто читают целый файл, поскольку поток байтов формирует источник и пишет тот же поток байтов месту назначения. Так как каждый байт файла записан в месте назначения, файловая система места назначения не создает редкий файл.

  Если Вы подозреваете, что редкие файлы в наборе данных заставляют это увеличиваться в размере, попробуйте --sparse опция к rsync. Это воспользовавшись ситуацией создаст редкие файлы на месте назначения каждый раз, когда были большие выполнения байтов с 0 значениями в источнике. (Это не может сказать, исходный файл, было на самом деле редко, только потенциально редок, но это делает это редким на месте назначения так или иначе.)

  Ваш STB, вероятно, содержит внутреннюю базу данных некоторого вида, который мог быть реализован с одним или несколькими редкими файлами. Ищите очень большие файлы в исходной файловой системе, в особенности файлы, которые больше, чем сумма устройства хранения данных на STB. Это должно быть редким.

• Вещи смонтированы больше чем в одном месте. Встроенные системы как STBs часто имеют странное расположение файловой системы вследствие того, что у них может быть соединение только для чтения и разделов чтения-записи, которые являются частью распределения программного обеспечения производителя и пользовательских данных, соответственно, различных типов файловых систем, разработанных для использования на необработанной флэш-памяти (не блочные устройства), разделы загрузчика, смонтированные объединением файловые системы, которые позволяют очень простое внедрение функций сброса фабрики, электронные диски для корректного выживания потерь мощности без повреждения файловой системы, и т.д... В результате фактическое, то же содержание могло бы казаться смонтированным в нескольких различных независимых местоположениях (например, в исходной фабрикой форме, как объединение монтируется, связывают, монтируется для других целей...),

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

• Жесткие ссылки: FTP не распознает жесткие ссылки, поэтому если Вы попросите, чтобы это скопировало две ссылки на тот же файл, то это скопирует файл дважды, и это поднимет дважды пространство на целевой стороне. Если файл имеет больше чем 2 ссылки, умножьтесь соответственно.

  Для помощи с этим попробуйте rsync's --hard-links опция.

Обратите внимание, что в два из трех случаев, я рекомендовал использовать rsync для копирования файлов. Это только возможно, если у Вас есть доступ оболочки к STB, и rsync установлен (или можно установить его), или если STB предлагает rsync как протокол передачи файлов (STB, вероятно, не делает, но некоторые устройства NAS, проданные для домашнего использования, делают).

Если можно использовать его вообще, rsync является отличным способом скопировать большие объемы данных от одной системы до другого. Мало того, что это имеет опции решить два из этих трех упомянутых выше проблем (или возможно все 3? Посмотрите на --one-file-system) но это очень удобно для возобновления прерванной копии.

В условиях Windows Вы не просто скопировали c: диск, Вы также скопировали все виды файлов, которые не являются дисковыми файлами, но вместо этого устройствами, и Вы много раз копировали некоторые файлы. Вероятно, включая целое дисковое содержание и дамп RAM несколько раз.

На Linux и других подобных Unix системах, почти все - файл. В дополнение к регулярным файлам и каталогам, существуют символьные ссылки (указатели на другие файлы) и файлы устройств, которые представляют устройства (диски, разделы, RAM, последовательные порты, и т.д.). Существуют также специальные файловые системы, которые не хранятся на диске, но позволяют данным доступа приложений о системе: /proc (procfs) и /sys (sysfs).

Среди устройств в /dev, существуют даже бесконечные файлы — файлы, которые можно продолжать читать навсегда. Существует /dev/zero, который содержит столько пустых байтов, сколько Вы хотите читать из него. Существует также /dev/urandom, который содержит столько случайных байтов, сколько Вы хотите читать из него — так для получения n случайных байтов, Вы читаете n байты из /dev/urandom.

При использовании программы FTP для передачи целого дерева файловой системы, это скопировало все и вероятно или копировало большую сумму вещей, которые могут быть получены из /proc, или более вероятно бесконечный объем данных от /dev.

Дальнейшее чтение:

• Что делает файлы устройств в/dev на самом деле делают?
• Делая Загрузочный USB, проблемы, копирующие/proc
• Что происходит, когда я открываюсь и читаю из/proc?
• Какие точки монтирования существуют в типичной системе Linux?

Если у Вас есть некоторый способ соединиться с полем кроме FTP, например, командная строка SSH, используйте это вместо FTP, который не знает о специальных файлах. Выполните команду df видеть, какие файловые системы присутствуют. Можно сделать резервное копирование корневой файловой системы с командой

rsync -a -x root@settopbox:/ settopbox.backup

(Отметьте -x опция сказать rsync программе не пересекать файловые системы.)

Корневая файловая система не могла бы быть интересной для резервного копирования, некоторые устройства настраиваются с корневой файловой системой только для чтения и другой файловой системой чтения-записи, содержащей настройки. Отправьте вывод команд df и mount если Вы нуждаетесь в помощи, выясняя который (s) для резервного копирования.

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

find /dev -type b
ls -l /dev /dev/* | grep '^b'

Если Вы не уверены, что устройства означают, отправляют вывод этих команд.

Причина состоит в том, потому что Linux имеет что-то позвонившее proc файловая система.

proc смонтирован на /proc и представляет в структурах данных ядра. Один такой объект /proc/kcore который является двухуровневым изображением ядра памяти ядра. Т.е. вся память, используемая в системе включая виртуальную память.

Вот пример на моей рабочей станции:

$ cat /proc/meminfo | grep MemTotal
MemTotal:        3507728 kB
$ ls -lh /proc/kcore
-r-------- 1 root root 128T 2012-09-21 17:24 /proc/kcore

Поскольку Вы видите, что у меня только есть 4 ГБ RAM. В то время как /proc/kcore огромные 128 ТБ! Это - значительно больше (приблизительно в 32,000 раз больше) память, чем я имею.