LINUX.ORG.RU
ФорумAdmin

Запись на домашний ноут-нас овер cifs/nfs не показывает прогресс

 , ,


1

1

Юзаю старый ноут как нас. Работаем в локальной сети. Все описанное ниже касается преимущественно больших файлов(фильмов).

При чтение с этого «наса» скорость максимально возможная - 9.5-11МБ/с для 100Mb ethernet подключения, по которому этот нас к роутеру подключен. Это касается любого опробованного протокола: samba, ftp, sshfs, nfs.

Проблема заключается в том, что при попытке записывать на этот сервак половина протоколов выполняют запись на экстремально низких скоростях(1.5-2МБ/с) - sshfs, ftp, samba over gvfs-smb. Вторая же половина(cifs, nfs) вроде бы выполняет загрузку на такой же максимальной скорости, что и скачивание, но не показывает прогресс!

Когда я пытаюсь выгрузить на нас файл размером 500МБ, doublecommander или thunar открывают диалог с прогрессом и зависают, не показывая изменение прогресса и отвисают примерно через минуту(как если бы закачивали файл со скоростью 10МБ/с).

Если попытаться выгрузить файлы через mc или pv - они сначала покажут резкий скачок прогресса до 100% и скорость копирования 300МБ/с, ну а следующую минуту висят как и их гуи собраться.

Почему при быстрой записи не показывается прогресс и как это можно исправить?



Последнее исправление: hxss (всего исправлений: 1)

Меня смущают фразы «примерно» надо не примерно, выполните time cp from to и дальше посчитайте что реально получилось. Тоже повторить используя scp. Тоже используя команду ftp.
Но учитывая что «Юзаю старый ноут как нас» больше ставлю на дохлый ноут. Но никак не на сетевые фс. У того же ftp оверхеда никакого.

Если попытаться выгрузить файлы через mc

mc - сначала кэширует а потом заливает, поэтому такой эффект.

anc ★★★★★
()
Ответ на: комментарий от anc

mc - сначала кэширует а потом заливает, поэтому такой эффект.

когда я через mc заливаю по ssh или ftp, он нормально показывает прогресс. Другая проблема, что там скорость почему то маленькая(ssh еще могу понять).

hxss
() автор топика
Ответ на: комментарий от hxss

Смотрите начало моего комментария. Тестировать надо «в родной песочнице» :) У уж потом думать на всякую гуйню &etc.

anc ★★★★★
()
Ответ на: комментарий от anc

Тут какая то странность произошла. Результаты тестов из первого сообщения я получал запуская таймер на телефоне(не знал про команду time) и получалось оно в лучших случай 50сек, минута, 1:15. Поскольку я их не записывал - отсюда и «примерно».

Но вчера начал тестировать по человечески через time и сначала меня порадовал nfs своими 6 минутами 3 раза подряд для файла 476МБ, а потом и мой главный инструмент cifs - 3:30, 3:40, 3:50 для того же файла. При этом в своих первых тестах, которые показывали около минуты я уверен, т.к. все время сидел с таймером в руках и ждал - не мог ошибиться.

Получается, что все протоколы разом просели. Следовательно проблема в железке. Но в какой именно и почему она проседает временами? Сейчас запустил на насе проверку на плохие сектора(хотя журналы чисты, но лучше сразу отбросить опасения). Подскажите, что еще можно проверить и где рыть. Во вчерашних тестах(3-6 минут) я даже отключал торренты на насе, которые являлись по сути главными пожирателями ресурсов. И могу сказать, что в целом при копирование файлов на нас через cifs всегда получал адекватные результаты(опять же на глаз, но я бы заметил, если бы у меня 500МБ переливалось 3 минуты).

hxss
() автор топика
Ответ на: комментарий от anc

ЗЫ Запустите предварительно smartctl -t long /dev/you-device на каждом и только после окончания тестов смотрите выхлоп смарта.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от hxss

Load_Cycle_Count 1042039

Запредельно для любого харда.

G-Sense_Error_Rate 1117

Вы что им в бадминтон играете? :)

Current_Pending_Sector 3

Примета, если больше нуля - К смерти. :)

anc ★★★★★
()
Ответ на: комментарий от anc

спасибо за расшифровку. В принципе от этого старичка рад получить даже то, что есть. Хотелось лишь понять причину тормозов при записи.

hxss
() автор топика
Ответ на: комментарий от anc

Вы что им в бадминтон играете? :)

после начала использования его в качестве наса он стоит в шкафу на своем боку прикрепленный к стенке, чтобы не упал. Очень редко его доставал. То, что он не лежит как обычный ноут могло стать причиной, даже если 90% времени он неподвижно стоит?

hxss
() автор топика
Ответ на: комментарий от hxss

Хотелось лишь понять причину тормозов при записи.

Уже написал, Load_Cycle_Count просто запредельно. Для тех же wd с «любовью» парковать головы, емнип 700 тыс. уже максимум для смерти. Хотя зависит от моделей, честного говоря не помню у какой и сколько, начинается с 300тыс, т.е. больше 300тыс. это уже «беда».

То, что он не лежит как обычный ноут могло стать причиной, даже если 90% времени он неподвижно стоит?

Харду пофигу на вертикальное расположение.

Итого: меняйте хард.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.