Размер файла отличается от /dev/zero и /dev/urandom [дубликат]
Я не думаю, что это можно сделать напрямую с помощью join . Что вы можете сделать, так это сначала извлечь файл, содержащий все ключи и столбцы 1-5, чтобы использовать его в качестве начала каждой строки. Затем вы можете использовать join , чтобы поставить два числа в конце.
Как в действительности выглядят строки, содержащие только поле соединения? Это просто поле или это поле с запятыми после? В первом случае вы могли бы сделать что-то вроде этого
awk -F , 'NF > 1 {print}' fileA fileB | cut -d, -f1-5 | sort -u | \
join -t, -o 0,1.2,1.3,1.4,1.5,2.6 - fileA | \
join -t, -o 0,1.2,1.3,1.4,1.5,1.6,2.6 - fileB
При большем размере блока существует риск получения неполных чтений. Это также часто происходит при чтении из канала, а не из блочного устройства.
Если вы ожидаете получить определенный размер (count*bs), вы также должны указать iflag=fullblock.
Это может быть необязательно для bs=1Mили меньшего размера, но в любом случае рекомендуется.
ddтакже попытается показать вам, сколько неполных чтений он получил. Копирует n+mблоков, n полных и m неполных. При копировании файлов, не кратных размеру блока, последний блок может быть неполным.
Пример:
$ dd status=progress if=/dev/urandom of=/dev/null bs=100M count=20
dd: warning: partial read (33554431 bytes); suggest iflag=fullblock
536870896 bytes (537 MB, 512 MiB) copied, 2 s, 254 MB/s
0+20 records in
0+20 records out
671088620 bytes (671 MB, 640 MiB) copied, 2.64391 s, 254 MB/s
В этом случае были получены только неполные чтения и ни одного полного 100-мегапиксельного блока. Очевидно, что /dev/urandom не хочет обрабатывать столько данных за одно чтение. Моя версия dd даже говорит вам использовать iflag=fullbockнапрямую.
С фуллблоком все ок:
$ dd status=progress if=/dev/urandom of=/dev/null bs=100M count=20 iflag=fullblock
2097152000 bytes (2.1 GB, 2.0 GiB) copied, 8 s, 255 MB/s
20+0 records in
20+0 records out
2097152000 bytes (2.1 GB, 2.0 GiB) copied, 8.22914 s, 255 MB/s
Это занимает больше времени, потому что на самом деле копируется в два раза больше данных.