Бесплатный CRLF в Предмете: строка - почему это там, и действительно ли это законно?
Если это - система в жестком реальном времени, то необходимо удостовериться, что у Вас есть некоторые резервные диски, локально должен один сбой (если у Вас нет некоторого контракта на поддержку на аппаратных средствах, которые говорят, что можно получить заменяющий тот-же-день, но даже затем локальную запчасть стоит иметь).
При игнорировании, что (или принятие шести дисков не считает запчасти, у Вас мог бы быть легкий доступ к) я предположу, что RAID10 (три RAID1s, вложенные в RAID0) по RAID5 для производительности, обосновывает, что Вы упоминаете. Или если пространство нисколько не является проблемой и дублированием, и rebuild-on-drive-failure время является большим беспокойством, то Вы могли бы даже считать два RAID1s с тремя дисками вложенными в RAID0 (но это - излишество в большинстве целей, хотя это позволило бы двум дискам на каждом участке R1 перестать работать одновременно при поддержании массива).
Существует другая опция хотя: три отдельных массива RAID1 (или возможно два RAID10 выстраивают, если Ваш контроллер поддерживает RAID10 с 3 дисками (RAID1E, как некоторые контроллеры называют его)). Таким образом, можно распространить VMs по различным шпинделям, таким образом, они будут конкурировать друг с другом намного меньше для пропускной способности IO. Два VMs на различных массивах RAID1 могут весело перегружать свои виртуальные диски без большого влияния на скорость отклика друг друга или VM на третьем массиве. Конечно, это может закончить тем, что было расточительно мудрый пространством: Вы можете закончить с большим свободным пространством на одном массиве, но не хотите использовать его, поскольку уже существуют интенсивно использующие средства ввода-вывода VMs в постоянном употреблении на том массиве, например (хотя в этом случае, если бы у Вас был единый массив VM, Вы вставили бы то пространство, конкурировал бы за доступ IO как этот так или иначе), или можно закончить с 25 ГБ, свободными на каждом массиве, но нуждаться в 50 ГБ для нового VM.
Эта техника может иметь большое значение с базирующимися дисками spinning-disk-and-arm при балансировке VMs между правом дисков. Это все еще имеет значение на SSD также, но меньше поскольку у Вас нет главного перемещения и проблем waiting-for-the-right-sector-to-pass-by, вызывающих дополнительную задержку уничтожения производительности. Хотя, поскольку я сказал выше, это может быть больше работы для управления. В варианте использования Вы описываете, Вы могли бы поместить, это слегка загрузило sharepoint сервер и ведущее устройство сборки на одном массиве и разработке VMs на другом (возможный один массив каждый, если у Вас есть три массива и никакой другой активный VMs). Как нуждается в изменении, можно всегда перемещать VMs вокруг массивов для изменения баланса загрузки с небольшим временем простоя (никакое время простоя вообще, если выбранное решение для виртуализации поддерживает живые миграции между локальными хранилищами данных).
Ну, если я понимаю RFC 822, они допустимы в определенных случаях, я думаю, что это артефакт из времен маленьких экранов с разрешением 24x80 ..
Эти разделы кажутся довольно четкими. Предметы можно сворачивать, а сворачивание - это символ CRLF плюс LWSP (линейный пробел) ... возможно, они были заменены, Wietse (в списках постфиксов) знает свои RFC наизнанку, если вам нужен окончательный ответ.
3.1.1. LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted. Thus, the single line
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
can be represented as:
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
and
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
and
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.
Note: While the standard permits folding wherever linear-
white-space is permitted, it is recommended that struc-
tured fields, such as those containing addresses, limit
folding to higher-level syntactic breaks. For address
fields, it is recommended that such folding occur
between addresses, after the separating comma.
3.1.2. STRUCTURE OF HEADER FIELDS
Once a field has been unfolded, it may be viewed as being com-
posed of a field-name followed by a colon (":"), followed by a
field-body, and terminated by a carriage-return/line-feed.
The field-name must be composed of printable ASCII characters
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of any
ASCII characters, except CR or LF. (While CR and/or LF may be
present in the actual text, they are removed by the action of
unfolding the field.)
Certain field-bodies of headers may be interpreted according
to an internal syntax that some systems may wish to parse.
These fields are called "structured fields". Examples
include fields containing dates and addresses. Other fields,
such as "Subject" and "Comments", are regarded simply as
strings of text.
Note: Any field which has a field-body that is defined as
other than simply <text> is to be treated as a struc-
tured field.
Field-names, unstructured field bodies and structured
field bodies each are scanned by their own, independent
"lexical" analyzers.
3.1.3. UNSTRUCTURED FIELD BODIES
For some fields, such as "Subject" and "Comments", no struc-
turing is assumed, and they are treated simply as <text>s, as
in the message body. Rules of folding apply to these fields,
so that such field bodies which occupy several lines must
therefore have the second and successive lines indented by at
least one LWSP-char.
Правка автора : Надеюсь, NickW простит меня за добавление примечания о том, что RFC822 был отменен RFC2822, но новый RFC говорит примерно то же самое в его разделе 2.2. 3 , и явно подтверждает, что такое сворачивание должно быть удалено перед выполнением любой дальнейшей обработки: состоящий из имени поля, двоеточия и тела поля. За удобство, однако, и иметь дело с символом 998/78 ограничений на строку, часть тела поля заголовка может быть разбитым на многострочное представление; это называется «складной». Общее правило заключается в том, что везде, где этот стандарт позволяет для складывания пробелов (а не просто символов WSP) CRLF может быть вставлен перед любым WSP. Например, поле заголовка:
Тема: Это тест
можно представить как:
Тема: Это
это тест
Примечание: хотя тела структурированных полей определены таким образом, что
сворачивание может происходить между многими лексическими токенами (и даже внутри некоторых лексических токенов), сворачивание ДОЛЖНО быть ограничено
размещение CRLF в синтаксических разрывах более высокого уровня. Например, если тело поля определено как значения, разделенные запятыми, рекомендуется, чтобы сворачивание происходило после запятой, разделяющей структурированные элементы, вместо других мест, где поле может быть свернуто, даже если это разрешено в другом месте.
Процесс перехода от этого свернутого многострочного представления поля заголовка к его однолинейному представлению называется «разворачиванием». Развертывание выполняется простым удалением любого CRLF, за которым сразу следует WSP. Каждое поле заголовка следует обрабатывать в развернутой форме для дальнейшей синтаксической и семантической оценки.
Это не умаляет того факта, что NickW безошибочно указал мне на то, что мне нужно было знать,
Сервер Sendmail (SendMail) накладывает ограничения на длину строки, но они намного выше (990 байт или более для почтовых программ smtp).
SendMail! = SendEmail
Насколько я понимаю, Nagios по умолчанию использует клиент SendEmail для отправки писем. Похоже, что почтовый клиент, который вы используете в Nagios, накладывает такие «жесткие» ограничения на длину заголовка / строки темы электронного письма.
Проверьте и сообщите о клиенте электронной почты, настроенном в файле конфигурации commands.cfg .
(Настройки notify-host-by-email и notify-service-by-email ).