Свежие комментарии

Это запросто может быть, к примеру, (кривой) антивирус. Вне всяких сомнений.

Но так как проблема юзера решена (выпуском под него персонального патча) - пока остается только любопытство "что это было"

I like to move it, move it, move it.
С ящика на ящик, места впритык, поэтому пишу на zpool на котором вообще-то бэкапы.
Подключено к контроллеру на Z68 и там два порта SATA3 (один - системный SSD, второй - часть тома) и 4 порта SATA2.
И видно, насколько эти порты разные, причем SATA2 - лучше.

(впрочем, возможно что там SATA3 вообще сделаны на каком-то левом чипе, не полезу в спеки)

Да, ahci включен с ходу, не менял.

1) Нарисовать скрипт
2) Заставить выполнить нужные действия

При том, что юзерская проблема зачинена (через open) и он с радаров пропал
Может быть некоей проблемой...

Ну, нарисовать ему dtrace скрипт, который поймает и покажет тебе эти вызовы, раз уже не ktrace/strace?

Есть. Но там еще юзер есть.

Вижу тебя продолжает беспокоить неравномерность загрузки дисков в raidz2, поэтому попробую разложить всё по полкам. Рассмотрим raidz2 из 7дисков, recordsize=1M, sectorsize=4k (ashift=12) и идеальный случай - на большом участке расположены только данные (метаданными пока пренебрегаем). Recordsize формируется так: на двух дисках контрольные суммы по 52х4k, на одном диске данные 52x4k и на четырех дисках - данные 51x4k. Получается у следующей recordsize контрольные суммы сдвинуты на три диска и так по кругу (для лучшего представления желательно нарисовать эту картинку на бумаге). Возврат контрольных сумм на исходные диски произойдёт через 7 recordsize (получается патерн расположения данных и контрольных сумм у каждого диска повторяется каждые 7 recordsize). Сам патерн имеет такую последовательность: контрольная сумма (52х4k), данные (51х4k), опять контрольная сумма (52х4k) и самый длинный непрерывный участок данных на диске - (51+52+51+51)х4k. Теперь оценим длину дорожки диска. Пусть в начале диска скорость чтения равна 180MB/s и скорость вращения 7200rpm, тогда информационная емкость дорожки в начале диска будет больше 180/120=1,5MB (больше потому что необходимо учитывать время перехода на следующую дорожку/цилиндр). Отсюда вытекает, что все диски при чтении будут задействованны, будут проходить все дорожки и вычитывать только ~71% (256/360) данных их общего количества данных на дорожке. Небольшой выигрыш видится только в случае, если контрольная сумма попадёт в конец дорожки и можно будет раньше начать переход на следующую дорожку/цилиндр, хотя и здесь есть сомнения. В итоге получаем, что верхний потолок скорости одного последовательного чтения на raidz2 из 7 дисков не будет превосходить 7*0,71*(скорость_самого_медленного_диска), то есть получили почти 5*(скорость_самого_медленного) и это в идеальном случае. На реальных данных должно быть ещё ниже :-(.
Теперь рассмотрим 6 дисков в raidz2. Ты наблюдаешь чтение только с 4 и значит верхний потолок не более 4*(скорость_самого_медленного) :-). Если происходит "не частое" смещение контрольных сумм и начинается чтение со всех дисков, то видно, что сумарная скорость чтения не изменяется :-). Поэтому всё аналогично.
Берём данные из таблицы твоего следующего поста и проверяем. Для raidz2 из 6 получаем скорость "самого медленного" 521/4=130MB/s и для raidz2 из 7 - 659/5=132MB/s. Всё сходится до +- погрешность, хотя в первом случае при чтении задействованы были 4 диска, а во втором 7 :-). Можно ещё предположить, что скорость рельного "самого медленного" WD1003FBYX была где-то на 10% выше.
Но у конфигурации из 6 есть "теоретический" ресурс. Если бы при записи смена дисков для контрольных сумм происходила для одного диска на величину больше длины дорожки (допустим 2MB), то можно было бы при соответствующем увеличении окна префетча задействовать все диски и получить условно "через-дорожечное" чередование. Это дало бы ощутимый прирост скорости последовательного чтения. В алгоритме балансировки зеркала в zfs применено "через-дорожечное" чередование, поэтому разработчикам известен этот приём и наверно есть весомые причины почему он не применён в некоторых подходящих конфигурациях raidz, хотя кто его знает ;-).
Вот как то так.

Ну по идее и интел и LSI должны сильно больше 2 гигабит уметь уж в любом случае.

Залезу туда по локоть сегодня - посмотрю и в BIOS.

Грузится так:
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: ACS-2 ATA SATA 3.x device

Подозреваю что апчхи - включен.

Я же тут где-то писал, 195-198 у быстрых и 162 у медленных.
На LSI было вроде бы чуть быстрее, типа 205 и 175.

Сегодня я в этот ящик еще раз полезу, потому что 7-й диск уже заказан, через часа полтора заберу, суну тогда LSI еще раз и еще раз посмотрю

Хочется же 6x140

Если я правильно понял - 6T диски перекочевали на адаптек? Если это так, то интересно как изменилась начальная скорость у дисков? По поводу "бардака" напишу ниже и начну новый комментарий, а то мало места :-).

Истинность пробелов я в логах не вижу, естественно, особенно после прохождения через пару E-mail клиентов.

Ну то есть вот предположение пока такое, что внутри QFile() с уникодом не все в порядке, зато вот QString::toUtf8() все делает как надо.

Мда. Возможно, конечно. Хотя в тех примерах что от юзера приходят (в комментариях выше есть) - чистая латиница, ни одного умляута я не вижу.

Ну на клиентской машине без шансов узнать.

А зависит, по всей видимости, именно от клиентского окружения.