Выбор SSD

[Speccyfighter]

12309 ... его вроде как пофиксили.

Платформе ZX Spectrum неизвестен термин 'авторитетное мнение', даже если оно с kernel.org.

Код: [Выделить]

# uname -r
3.10.24-std-pae-alt1

Как видно из этого, выбора здесь никакого:

Код: [Выделить]

# cat /sys/block/sda/queue/scheduler
noop [deadline]

Убрано всё, чтобы разгрузить процессор почти до нуля.

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

Код: [Выделить]

JMicron SATA/PATA Controller [Enable]
JMicron SATA Controller Mode [IDE] # [RAID] [IDE] [AHCI]
По-серьёзному, надо бы перевести на ahci, но возможно через месяц-два сменится железо.
Так что пусть пока живёт.

Запущенный процесс '# dd if=/dev/zero ...' может заставить задуматься на старте процесс '# iotop':

Код: [Выделить]

#  dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=50000


Код: [Выделить]

# time iotop
0.10user 0.02system 0:06.62elapsed 1%CPU (0avgtext+0avgdata 7744maxresident)k
6464inputs+0outputs (2major+4446minor)pagefaults 0swaps
Как погрешность можно сбросить секунду.

У меня утверждение '12309 ... вроде как пофиксили' надолго повисло в воздухе, ввиду отсутствующего в std-pae шедулера cfq. Возможно cfq есть в led-ws, но поскольку led-ws-pae не существует, то и говорить не о чем.
А deadline, как видно по ситуации, не сумел перераспределить ресурсы I/O между двумя рутовыми запросами.
Поэтому, поживём - увидим.

И ещё, на мой взгляд:
планировщики настолько индивидуальная и интимная вещь для каждого, что решать за пользователя чему в ядре быть, а чему нет, плохая идея.

И:
Серьёзно я бы не рассматривал, но почитать наверное интересно будет.

[Speccyfighter]

Могу только предположить, что случилось после этого.

1. Не закрывая сессию TDE перешёл в root'овые vt.
2. Последовательно запустил три команды в разных теминалах:

Код: [Выделить]

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=50000


Код: [Выделить]

# iotop -b -t 0.1 -u root >> dev-zero.txt


Код: [Выделить]

# mc
См. вложение dev-zero.txt

mc вполне так ничего задумался на старте.
Завершил процессы, разглядываю файл.
Потом запускаю в гуёвой сессии:

Код: [Выделить]

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=1000
и оба-на!
Это с чего бы винчестер способный выдавать до 148МБ/с на запись максимум выдаёт 44МБ/с?
И не больше, хоть стреляй.
И лишь на коротких файлах от 100МБ и меньше, скорость на запись растёт.
См. вложение dev-zero00.txt

Ну ребут... Дащазпрям! Тоже самое.
Помогло выключение компьютера с загрузкой.
Вот сейчас другое дело:

Код: [Выделить]

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 7,96091 c, 132 MB/c

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=100
100+0 записей получено
100+0 записей отправлено
 скопировано 104857600 байт (105 MB), 0,390324 c, 269 MB/c

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=10
10+0 записей получено
10+0 записей отправлено
 скопировано 10485760 байт (10 MB), 0,0273433 c, 383 MB/c

# dd if=/dev/zero of=/root/hlam/zero.img bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 7,38079 c, 142 MB/c


[asy]

Код: [Выделить]

JMicron SATA/PATA Controller [Enable]
JMicron SATA Controller Mode [IDE] # [RAID] [IDE] [AHCI]
По-серьёзному, надо бы перевести на ahci, но возможно через месяц-два сменится железо.
Так что пусть пока живёт.

Так секундное же дело. Надо перечислить оба нужных модуля в /etc/initrd.mk в MODULES_ADD, да и переключать в BIOS, как хочешь.

[chaos_dremel]

Speccyfighter, я правильно понимаю что у Вас после записи 50ГБ нулей, жесткий выдавал ~40мб/с последовательной записи? И продолжалось это вплоть до жесткого ребута?

[Speccyfighter]

Speccyfighter, я правильно понимаю что у Вас после записи 50ГБ нулей, жесткий выдавал ~40мб/с последовательной записи? И продолжалось это вплоть до жесткого ребута?

Ага.
Судя по всему после жесткого I/O тремя рутовыми процессами с обязательным dd if=/dev/zero ... .
Причём даже тогда застряло на 44Мб/с, когда шина винчестера никем не занята и I/O тоже ничем не нагружен.

Правда тут деталь:
В компе стояло 4Х2Гб памяти. Засёк планку hynix с битым битом, где-то на 1240-ом мегабайте. Комп почти сутки на тесте стоял. Память у меня не сильно загружена, м.б. бит болтался где-то в районе кеша.
Ошибка с битым битом вылазила не сразу, а только при определённых тестах.
Могло ли повлиять, кто его знает.
И ещё когда-то замечал такую байду, которую не мог понять:
После скажем загрузки системдшного симпли с последующей загрузкой другого лайва альтов, на экране видел обломки старого. Ребут с ресетом исправлял, но как понял сам, при просто ребуте память м.б. не очищалась.
Ловил такое.

[chaos_dremel]

Где-то лет 10 назад наблюдал в лайв сессии слакса заставку от френзи (лайв BSD), которую я грузил за минуту до этого, с последующей штатной перезагрузкой.