после апгдейда с 3.4.8 на 3.7.5 обнаружилось невыносимое замедление удалений (в разы, если не десятки) на массивных операциях вроде hsh --cle или чекаута в другой бранч в kernel git. ext4, rw,relatime,discard,data=writeback соответствующий процесс безвылазно сидит в D (нет, это не издыхающий SSD, даунгрейд моментально всё ставит на место).
А запись при этом нормально идёт ? На любом SSD воспроизводится ? 2aen: это блокер для p7.
(In reply to comment #1) > А запись при этом нормально идёт ? > На любом SSD воспроизводится ? > цифр не пытался получить, но на глаз запись как запись. Собственно, такое удаление на SSD с такой строчкой монтирования -- это много-много TRIM
А этот , как его, "контроллер" что ли , может поменять ? Который в /sys/block/sd*/queue/scheduler лежит. Где-то в арчвики читал что надо noop для ssd. Просто ради эксперимента можно попробовать
(В ответ на комментарий №3) > А этот , как его, "контроллер" что ли , может поменять ? Который в > /sys/block/sd*/queue/scheduler лежит. Вот там и поменять: echo 'block/sda/queue/scheduler = deadline' >> /etc/sysfs.conf echo deadline > /sys/block/sda/queue/scheduler > Где-то в арчвики читал что надо noop для ssd. По моим чтениям, раздумьям и тестам это безбашенный оптимизм, а ставить стоит deadline. 2 lioka: а это часом не могли i/o barriers включиться?
На текущем 3.8 воспроизводится?
(В ответ на комментарий №5) > На текущем 3.8 воспроизводится? Жду ответа до 6 апреля.
(In reply to comment #6) > (В ответ на комментарий №5) > > На текущем 3.8 воспроизводится? > > Жду ответа до 6 апреля. да.
А на 3.10? (или это не блокер?)
А на 4.8?..
того железа давно нет.
исправлено временем.
