Верхняя память (пространство пользователя) и highmem (пространство ядра)

Так как Вы заявляете, что это - домашняя работа, я дам Вам ряд подсказок, а не решения.

Можно запустить с чего-то вроде этого:

find . -type f|xargs -I%  md5sum % |sort \
 |uniq -w32 -D|cut -f3 -d' '|while read filename ; do

   # code here

done

В этом while цикл, filename будет содержать название одного из файлов, обнаруженных Вашим конвейером.

Идея состоит в том, чтобы сравнить каждого с предыдущими файлами. Чтобы сделать это, в конце цикла, добавляет текущий файл к массиву:

count=0
find . -type f|xargs -I%  md5sum % |sort \
 |uniq -w32 -D|cut -f3 -d' '|while read filename ; do

 # code here

 files[$cout]="$filename"
 count=$((count+1))
done

Все, в чем Вы нуждаетесь теперь, должно заполнить #code here :-) Вы имеете в Вашем распоряжении:

  1. файл, которому нужно сравнение: $filename
  2. файлы это должно сравниться: files массив
  3. количество файлов это должно быть сравнено с $count (не упустите ошибки диапазона),

Можно уладить все это с a while цикл, сравнивая файлы $filename и ${files[$some_counter]} на каждом шаге.


Для создания этого лучше необходимо только проверить файлы с тем же md5sum друг против друга. Для этого Вы могли:

  1. удалите cut от Вашего конвейера
  2. изменитесь read читать и в сумме md5 и в имени файла
  3. сбросьте files выстройте, когда Вы обнаруживаете, когда Вы идете дальше к другой сумме md5

Этому будет нужна еще одна переменная для отслеживания "текущую" сумму md5.


Можно сделать его еще лучше путем предотвращения избыточных сравнений. Для этого необходимо будет добавить немного больше логики, чтобы не добавлять файл к files если это уже идентично одному в том массиве.

И можно обойтись без $count переменная.

И что-то очень важное необходимо проверить (и зафиксировать при необходимости): удостоверьтесь свои работы сценария с именами файлов или именами каталогов, которые содержат пробелы.


Читайте на массивах удара.

3
02.07.2012, 07:50
1 ответ

"Верхняя память" и "низкая память" не относятся к виртуальному адресному пространству процессов, это о физической памяти вместо этого.

В виртуальном адресном пространстве процесса пространство пользователя занимает первых 3 ГБ, и ядро располагает четвертый ГБ с интервалами этого линейного адресного пространства.

Первые 896 МБ пространства ядра (не только код ядра, но и его данные также) "непосредственно" отображается на первых 896 МБ физической памяти. Это является "прямым" в том смысле, что всегда существует смещение 0xc0000000 между любым линейным адресом этой части 896 МБ пространства виртуального ядра, и его соответствующий адрес в физической памяти (обратите внимание однако, что MMU включен и что записи таблицы страниц на самом деле используются для этого).

Последняя часть 128 МБ пространства виртуального ядра - то, где отображаются некоторые части физической "верхней памяти" (> 896 МБ): таким образом это может только отобразить не больше, чем 128 МБ "верхней памяти" за один раз.

Ссылка: "Понимание Ядра Linux", третий выпуск - разделяет "8.1.3. Зоны памяти" и "8.1.6. Отображения ядра Страничных блоков Верхней памяти".

6
27.01.2020, 21:13

Теги

Похожие вопросы