“короткое чтение” от файловой системы, когда это может произойти?
Очевидно, что в целом чтение (2) системный вызов может возвратить меньше байтов, чем, что попросили быть считанным. Однако довольно много программ предполагают, что при работе с локальные файлы, читайте (2) никогда возвраты меньше, чем, что спросили (если файл не короче, конечно).
Так, мой вопрос: на Linux, в котором случаи могут читать (2) возврат меньше, чем, что требовали при чтении из открытого файла и EOF, не встречен, и считанная сумма является несколькими килобайтами в максимуме?
Некоторые предположения:
- Полученные сигналы могут прервать чтение как этот, но не заставить его перестать работать?
- Различные файловые системы могут влиять на это поведение? Действительно ли там что-нибудь является особенным о jffs2?
5 ответов
Возвращаемое значение может быть меньше, чем нбайт , если количество оставшихся байтов в файл меньше нбайта , если Запрос read() был прерван просьбой Сигнал, или если файл является трубой, или FIFO или специальный файл и имеет меньшее количество чем байт байтов, доступных немедленно. для чтения.
Файловые системы, основанные на дисках, обычно используют непрерывное чтение, что означает, что
Работа считывания, как правило, не может быть прервана сигналом. Сетевой
Файловые системы иногда используют прерывистое чтение, которое может вернуть частичные данные или не вернуть данные.
(В случае NFS это можно настроить с помощью опции монтирования intr).
Иногда они также реализуют таймауты.
Имейте в виду, что даже /some/arbitrary/file/path может ссылаться на FIFO или специальный файл, так что то, что вы считали обычным файлом, может и не быть. Поэтому хорошая практика работы с частичными чтениями, даже если они могут быть маловероятны
.Я не уверен, но эта ситуация может возникнуть, когда у операционной системы заканчиваются страницы в кэше страниц. Можно предположить, что в этом случае будет вызван поток flush, но это зависит от эвристики, используемой в планировщике ввода/вывода. Эта ситуация может привести к тому, что при чтении будет возвращаться меньше байт.
.Я должен спросить: "Почему тебя волнует причина"? Если read может вернуть на несколько байт меньше запрошенной суммы (что, как Вы указываете, безусловно, может), то почему Вы не хотите разобраться с этой ситуацией?
.Полученный сигнал делает ошибку read() только в том случае, если он еще не прочитал ни одного байта. Иначе он вернет частичные данные.
И я думаю, что альтернативные файловые системы действительно могут возвращать короткие чтения в других ситуациях. Например, для меня имеет смысл, чтобы файловая система в сети вела себя так же, как и сетевой сокет при коротком чтении (= частом чтении).
.Если это действительно читаемый файл, то вы можете получить короткое чтение, как последнее чтение перед окончанием файла.
Как бы то ни было, обычно лучше вести себя так, будто ЛЮБОЕ ЧИТАНИЕ может быть коротким. Если то, что вы читаете, является трубкой или устройством ввода (stdin), а не файлом, вы можете получить короткое чтение, если ваш буфер больше, чем тот, что в настоящее время находится во входном буфере.
.