Неверный размер раздела на новом диске
Помимо всего прочего, проверкаcat-добавит дополнительную нагрузку на производительность и создаст путаницу в отношении того, какое использование catна самом деле бесполезно, ИМХО, потому что такие проверки могут быть неэффективными и создавать проблемы с законным catиспользованием.
Когда команды имеют дело со стандартными потоками, они должны заботиться только о чтении/записи в стандартные файловые дескрипторы. Команды могут знать, является ли стандартный ввод доступным для поиска/искания или нет, что указывает на канал или файл.
Если мы добавим к этой смеси проверку того, какой процесс на самом деле предоставляет это содержимое стандартного ввода, нам нужно будет найти процесс на другой стороне конвейера и применить соответствующую оптимизацию. Это можно сделать с точки зрения самой оболочки, как показано в сообщении SuperUser Кайла Джонса, и с точки зрения оболочки
(find /proc -type l | xargs ls -l | fgrep 'pipe:[20043922]') 2>/dev/null
, как показано в связанном посте. Это еще 3 команды (, так что дополнительные fork()s и exec()s )и рекурсивные обходы (так много readdir()вызовов ).
С точки зрения исходного кода C и оболочки, оболочка уже знает дочерний процесс, поэтому нет необходимости в рекурсии, но как мы узнаем, когда оптимизировать, а когда catна самом деле бесполезно? На самом деле существуют полезные применения cat , такие как
# adding header and footer to file
( cmd; cat file; cmd ) | cmd
# tr command does not accept files as arguments
cat log1 log2 log3 | tr '[:upper:]' '[:lower:]'
Вероятно, добавление такой оптимизации в оболочку было бы расточительством и ненужными накладными расходами. Как уже упоминалось в ответе Кусаланды, UUOC больше связан с отсутствием у пользователя понимания того, как лучше всего комбинировать команды для достижения наилучших результатов.
Похоже, у вас неправильное представление об отношениях между разделами и файловыми системами. Ваш раздел на самом деле имеет правильный размер, но ваша файловая система - нет.
Когда вы запустили pv < /dev/sda1 > /dev/sdc1, вы байт за байтом скопировали файловую систему из sda1в sdc1. Файловая система была создана в sda1, поэтому mkfs.ext4заставила файловую систему занимать точный размер sda1. Однако sdc1больше, чем sda1. Таким образом, в результате у вас есть файловая система размером 10 ТБ внутри раздела размером 12 ТБ.
Решение состоит в том, чтобы использовать resize2fsдля изменения размера файловой системы таким образом, чтобы она занимала весь раздел. Вы можете передать точный желаемый размер файловой системы в resize2fs, но в этом нет необходимости, если вы просто хотите изменить размер до размера раздела. Когда /dev/sdc1размонтирован, просто запустите resize2fs /dev/sdc1от имени пользователя root, и он должен изменить размер вашей файловой системы до 12 ТБ.
Примечание:
Вы должны экономно использовать этот тип копирования файловой системы; и оригинал, и копия будут иметь одинаковый UUID. Если оба раздела находятся в системе одновременно, идентификаторы перестают быть уникальными.
Таким образом, либо используйте этот метод, когда вы собираетесь стереть исходный диск (, т. е. вы просто перемещаете раздел на новый диск, а не копируете его ), либо если вы планируете вручную изменить исходный диск. UUID копируемого раздела.