Когда какая-то другая программа печатает foo
в /dev/pts/9
, связь между ttys, оболочка не участвует в обмене, она не может знать, сколько символов было напечатано или даже если был напечатан какой-либо символ. Оболочка по-прежнему считает, что нет символов для стирания. На самом деле, если вы напечатаете foo
на терминале и попытаетесь стереть его клавишей Backspace, это не сработает. Оболочка не пытается стереть то, чего, по ее мнению, нет.
Попробуйте в терминале, где вы использовали команду --norc --noprofile:
bash-4.3$ printf 'some text'
чтобы получить:
some textbash-4.3$
В этот момент возврат ничего не удалит. Также ctrl-u
ничего не сотрет. Если вы наберете несколько символов (, до 11 из них)ctrl-u
удалит только то, что было введено (, как и возврат ). Но когда символов больше 11,команда ctrl-u
вернется к тому, что она считает началом строки (более быстрый способ стереть много символов ), который оставит это приглашение:
some textb
Это можно считать ошибкой IMO (, все еще присутствующей в bash 5.0 ). Но меняется на 20 (18 для OP )символов в bash -5 если опции--norc
--noprofile
не используются (Я не пытался найти причину, не такой уж и важный вопрос ИМНшО ).
Запуск с data=journal отличается от COW, потому что он записывает все данные дважды каждый раз -один раз в журнал, фиксирует транзакцию, а затем делает контрольную точку в файловой системе. и освобожден от журнала. Файловая система COW выделяет новые блоки для каждой записи, записывает в эти новые блоки, фиксирует транзакцию, затем (в конце концов )освобождает старые блоки (по модулю моментальных снимков ).
Для накопителей SMR была разработана серия патчей ext4, которые, по сути, переводили data=journal в режим структурированной файловой системы -журнала, где журнал был очень большим и не закреплял метаданные и страницы данных в ОЗУ. Блоки в журнале потенциально могли бы жить там долгое время без каких-либо контрольных точек в файловой системе, пока файловая система не станет «заполненной» журналом, и журналу придется проверять старые транзакции. Это приведет либо к окончательной записи блоков в файловую систему, либо к -повторному журналированию в новую транзакцию.
Эта серия исправлений SMR доступна по адресу :
.https://github.com/tytso/ext4-patch-queue/blob/master/series