LINUX.ORG.RU
Форум — Linux-hardware  

Где тонко там и плохо.

 , ,


0

3

Всем привет. Вопрос простой. Я переодически один раздел SSD с sata интерфейсом сохранял с помощью DD на HDD с таким же интерфейсом. Получилось разжиться SSD M2 и перевести архивирование на него. Ну..думаю.. сейчас архивирование ускорится до небес. А вот болт вам без граней. Время как было 1Гб в 10 секунд плюс минус, так и осталось. Когда же у нас разрабы до btrfs доберутся чтобы нормально его без dd бэкапить? Все что есть сейчас работает медленнее dd, а он место жрет лишнее. Вот теперь думаю как интерфейс на диске на более скоростной поменять. Самый момент был когда я первый раз в новой конфигурации сделал архив и мягко сказать о..фигел…:-) пока до меня дошло что sata тормозит.

★★★★★

Последнее исправление: SergeySVold (всего исправлений: 1)
← Нужна помощь с тачскрином
Как ядра CPU соеденены с линиями PCIe? →

где не продумано там и плохо, грубо и топорно… dd раздела со всем хламом на другой сборник хлама….
разделяй и властвуй.
выдели /home со всем хламом на отдельный раздел - его бекапишь по файлово с помощью хотя б rsync, неизменные файлы не гоняются впустую. а лучше вообще нацепи нормальный дифференциально/инкрементальный бекап. нахрена тут dd ??
ну а корень системы / (и остальное системное если выделено типа /boot/efi) копируй dd, хотя разумнее конечно использовать partclone.
да и вообще
надо развиваться и отвыкать от каменных топоров…

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)

Когда же у нас разрабы до btrfs доберутся чтобы нормально его без dd бэкапить?

Чисто тебе по большому секрету: ты уже сейчас можешь бэкапить что угодно без dd.

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

CrystalDiskMar,SSD-Z,AS SSD Benchmark и HD Tune все показали одинаковые результаты чтение - 2100 Мбайт/сек, запись - 1500 Мбайт/сек. У меня такойже модели но на 256GB уже год работает и все ок. Правда он PCIe 4

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

Не Выдержал и проверил. С SSD WD240 на HDD WD1TB все на sata

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.20526 s, 149 MB/s

c SSD WD240 на SSD M.2 Apacer512GB PCIxe3+sata

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.27825 s, 148 MB/s

Что то вообще в не понятках. На хрен . пойду домой.

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

6 Гбит/с у sata-3 ~ 0.7-0.75 Гб/с должно выходить

Нет, не должно, это не Ethernet.

https://en.wikipedia.org/wiki/SATA

Third-generation SATA interfaces run with a native transfer rate of 6.0 Gbit/s; taking 8b/10b encoding into account, the maximum uncoded transfer rate is 4.8 Gbit/s (600 MB/s)
Dimez ★★★★★
()
Ответ на: комментарий от cobold

С чего это нехорошие? Я вот с ethernet-ом путался первое время что там байт за 8бит считается а не за 10 как во всех последовательных интерфейсах. А на 10 и делить проще.

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

Скорость у тебя зависит от применяемого сжатия. У меня помимо него еще шифрование, так что скорость не очень:

zstd -T0 -b1 -e9
 1#Lorem ipsum       :  10000000 ->   3240239 (x3.086), 1250.1 MB/s, 1450.4 MB/s
 2#Lorem ipsum       :  10000000 ->   3131055 (x3.194),  747.6 MB/s, 1196.8 MB/s
 3#Lorem ipsum       :  10000000 ->   2988763 (x3.346),  300.8 MB/s, 1278.9 MB/s
 4#Lorem ipsum       :  10000000 ->   2952688 (x3.387),  295.0 MB/s, 1284.1 MB/s
 5#Lorem ipsum       :  10000000 ->   2949355 (x3.391),  149.0 MB/s, 1218.8 MB/s
 6#Lorem ipsum       :  10000000 ->   2882248 (x3.470),  101.6 MB/s, 1309.4 MB/s
 7#Lorem ipsum       :  10000000 ->   2854410 (x3.503),   83.3 MB/s, 1352.1 MB/s
 8#Lorem ipsum       :  10000000 ->   2835325 (x3.527),   62.9 MB/s, 1423.2 MB/s
 9#Lorem ipsum       :  10000000 ->   2832147 (x3.531),   53.2 MB/s, 1440.4 MB/s

При zstd-1 самая большая скорость чтения. Когда ты просто копируешь данные (cp -r тем же или rsync), то скорость их копирования будет равна последнему числу в лучшем случае.

На колонку перед ней можно забить. Скорость записи данных на диск упирается в скорость твоего соединения (данные то из сети качаются), а поэтому можно сжатие ставить 6-9, правда к большинству данных, хранимых на домашней системе сжатие не применимо, так что запредельного выигрыша от его использования не будет.

При копировании через dd тож свои приколы, связанные с падением скорости через определенное время, связанное с забитием кеша. Если у тебя два диска, то RAID-1 самое правильное решение:

sudo btrfs dev add <раздел с на апацере> /

# Далее конвертируешь файловую систему, чтобы дублировались все данные на оба диска
sudo btrfs balance start -f -sconvert=raid1 -dconvert=raid1 -mconvert=raid1 /
rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от cobold

Да ты что? Давай тогда tcp/ip-заголовки ещё исключим из подсчёта скорости. Ну и скорость для данных нормальные люди измеряют в байтах и кратных им единицах, а в битах измеряют скорость электрического канала. Биты данных сами по себе нафиг никому не сдались. Сколько нужно бит для передачи одного байта - зависит от технологии связи, где-то на доли бита больше 8 (если байты передаются непрерывным потоком), где-то 9, 10 или даже 11, если байты передаются по одному и снабжены защитой от ошибок.

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

Нет это пользовательские данные. Я же не предлагаю служебные кадры сата протокола расковырять и вычитать служебные поля. Это была бы правильная аналогия с tcp/ip внутри ethernet

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

Чего это они пользовательские? Пользователь открывает сокет и ожидает что в него сможет прийти столько-то байт за секунду, ни при какие заголовки и пакеты знать не хочет. Или хуже того, открывает файл в браузере по https и смотрит скорость скачивания.

Я согласен, что побитовое представление байта это штука нижнего уровня по сравнению с форматом tcp-пакетов, но совершенно не понимаю, на каком основании ты провёл границу служебные/пользовательские данные именно там. Скорее, всего, тебе просто так захотелось.

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

В том то и дело что не по сети а в рамках одной матери. Причем прогнал все диски CristalDiskMark скорости дисков полностью соответствует их характеристикам.

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

А покажите командную строку dd, который тормозит. Может быть действительно размер блока надо увеличить? Типа bs=64M (или даже bs=1G). Там по умолчанию очень маленькое значение, неактуальное в современной практике

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

dd if=/dev/sdb1 of=/run/media/liveuser/Apacer512/sdb1_40_11102024.img conv=noerror,sync bs=4M

Строки одинаковые практически акромя диска назначения

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

какая ФС на целевом примонтированном диске? Если там вдруг что-то реализованное через fuse в userspace, типа ntfs-3g - может забирать 100% ядра CPU и тормозить из-за этого.

И таки 4M не удивлюсь если как-то влияет на скорость (хотя так критично не должно бы…)

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

Вот хоть один грамотный человек нарисовался! Там именно ntfs-3g. До меня только сегодня дошло в процессе ковыряния инета. Один китаец мне на этот момент пальцем ткнул. Вот сижу и думаю как этот момент обойти. Мне этот архив из под Windows то же должен быть доступен. Ищу варианты. Причем в этом img может быть файловая система как btrfs так и ext4 или extFat.

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

Можно попробовать обновлённый NTFS-драйвер уровня ядра, который научился не только чтению, но и записи. https://www.phoronix.com/news/Linux-6.5-NTFS

Никакой практитки с ним не имел, так что кроме того что он етсь ничего не знаю)

GPFault ★★
()
← Нужна помощь с тачскрином
Linux-hardware
Как ядра CPU соеденены с линиями PCIe? →