Проблемы с диском и порядок монтирования

1. может и умирает, а может кабель плохой или питание. Проверь. (есть смарт тест для кабеля)

2. выбирай диски, на которые гарантия 5+ лет.

1. может и умирает, а может кабель плохой или питание. Проверь. (есть смарт тест для кабеля)

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

А че такого? Аварийное отключение — перепад напряжения, стукнул при неприпаркованных головках, мало ли.

Но попробуй просто кабель переткнуть. Может пыль или еще что. Еще бывают варианты, когда БП не держит ток — либо дохнет, либо повесил на линию со всякими вентиляторами с регуляторами... У меня как-то было так — переключаю вентиляторы на повышенное напряжение рычажком, диски отваливаются...

Ну например то, что 197 Current_Pending_Sector растет. Уже 1176. И до этого отключения такого не было. Но попробую завтра с кабелями конечно...

И еще меня напрягает то что он теперь монтируется медленно. Не успевает примонтироваться к тому времени как его же забиндить надо.

С современным systemd из fstab'a генерируются юниты, которые выполняются параллельно. Какого-то прямого способа указать зависимости нет. Выход - зависимые операции выносить в отдельный юнит. Самое простое и прозрачное - логику вынести в bash скрипт(ы), а уже его запуск(остановку) осуществлять через юнит.

П.С. пришли к единообразию, простоте и отсутствию велосипедов и костылей с вводом systemd. Ага...

Ты не прав:

1. зависимости между mount-юнитами расставляются автоматически, бинды учитываются;
2. любые юниты можно дополнять, в том числе автогенерируемые и в том числе на предмет зависимостей.

Так что да, пришли к единообразию. Кто ж мог подумать, что люди с почти религиозной яростью ополчатся против нового софта, станут показательно игнорировать маны и все проблемы по-прежнему будут пытаться решить с помощью местечковых хаков (а потом сетовать на неполноценность оного софта, питая положительную обратную связь).

Вполне реальная задача. Монтировать sda1 в каталог «1» и sda2 в каталог «2», после этого объединить их в общий каталог «3» с помощью aufs.

Systemd, без написания отдельного юнита на процесс объединения «1» и «2», вполне могло объединить их до монтирования sda1, sda2. В итоге, получалась тыква.

Пришлось писать юнит на процесс объединения каталогов, указывая необходимые зависимости, автоматически ничего не учитывалось. Возможно, bind, как распространенный случай и запихнули в systemd, но судя по результатам ТС'а (если предположение о наличии у него systemd верное), работает оно не очень.

если предположение о наличии у него systemd верное

верное, верное

работает оно не очень

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

люди с почти религиозной яростью ополчатся против нового софта, станут показательно игнорировать маны

Ничего особого против systemd не имею, но при попытке сделать что-то сложнее самых простых примеров упирался в стену ограничений systemd (маны курил, видеолекции с лора смотрел, арче-вики читал и.т.д.). И, спасибо, что можно весь функционал, за исключением зависимостей вынести в скрипты. Хоть какой-то способ заставить систему выполнить то, что требуется.

Systemd, без написания отдельного юнита на процесс объединения «1» и «2», вполне могло объединить их до монтирования sda1, sda2.

Это делается путём явного указания недостающих зависимостей в .mount-юните (для чего есть аж два способа, о которых ты, конечно же, не слышал). Здесь совершенно необязательно писать свой велосипед и потом жаловаться на systemd, что он-де не гибкий.

bind, как распространенный случай и запихнули в systemd

bind действительно обрабатывается автоматически, как распространённый случай, но это не отменяет вышесказанного.

Покажи fstab (или как ты там биндишь) и вывод systemctl show -p Wants,Requires,Before,After,WantedBy,RequiredBy,RequiresMountsFor <путь> для путей к обоим точкам монтирования (исходной и той, куда биндишь).

// ня, пятая звезда

Все понятно.

198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       34

Срочно тырить все данные которые на диски еще живые, а диск - в мусорку

Нечего там тырить. Все ценное из бэкапа востановил. Фильмицо перекачаю. Ну музло скопировал, но диск очень медленно работает - всё копировать вломы. Чо за параметр?

> systemctl
fish: Unknown command “systemctl”
systemctl: команда не найдена

А выдержки из fstab в стартовом сообщении.

Это делается путём явного указания недостающих зависимостей в .mount-юните (для чего есть аж два способа, о которых ты, конечно же, не слышал)

Ну, почему же не слышал. Слышал, все настроил, работает.

По теме, ТС'у тоже надо осваивать кактус и его особенности, перезагружать систему не комильфо.

Сектора, которые не удалось перераспределить(reallocate). Если их число или число current pending sectors продолжает расти - диску явно пора на свалку

Понятно. Спасибо. Т.е. использовать его уже даже как флэшку нихрена не выйдет? Ну пусть тогда в столе поваляется (вдруг что-то забыл ценное на нем), а потом на магнитики пойдет ;)

что купить на замену?

отсортировал в порядке «не стоит это брать». Или гуглить статистику в наше время уже не судьба?

Seagate
Toshiba
WD

Да погуглил и взял в итоге WD. Хитачи как-то уж дороговаты...

Нет, ну ты же говоришь, что «написал отдельный юнит». А можно и не писать, просто дописать зависимости. И только попробуй скажи, что это костыль.

> systemctl
fish: Unknown command “systemctl”
systemctl: команда не найдена

Тогда

если предположение о наличии у него systemd верное

верное, верное

Нет, неверное.

А можно и не писать, просто дописать зависимости.

просто

Согласен, давай попробуем... /etc/fstab (монтирование жёстких дисков):

UUID=0b239431-a9cf-414e-b4df-a31a3be8e1da  /var/mnt/hitachi-3tb-[9FA9034E] ext4 defaults,noatime,nodiratime 0 0
UUID=8560a6f0-37f0-4646-9280-363f9d3863c9  /var/mnt/toshiba-3tb-[63D9B162] ext4 defaults,noatime,nodiratime 0 0

Объединение, согласно, мануалу и раз, через x-systemd.requires-mounts-for:

none /mnt/backup/local.archives/ aufs br:/var/mnt/hitachi-3tb-[9FA9034E]=rw:/var/mnt/toshiba-3tb-[63D9B162]=rw,create=mfs,sum,x-systemd.requires-mounts-for=/var/mnt/toshiba-3tb-[63D9B162],x-systemd.requires-mounts-for=/var/mnt/hitachi-3tb-[9FA9034E] 0 0

После перезагрузки смотрим, что показывает df -h и видим, что объединения нет:

none                                              34G          19G   14G           59% /mnt/backup/local.archives
/dev/sdd1                                        2,7T         1,2T  1,6T           43% /var/mnt/hitachi-3tb-[9FA9034E]
/dev/sdc1                                        2,7T         321G  2,4T           12% /var/mnt/toshiba-3tb-[63D9B162]

Смотрим, что за юнит сгенерировал systemd

root@backup-storage:/run/systemd/generator# cat /run/systemd/generator/mnt-backup-local.archives.mount 
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Mount]
What=none
Where=/mnt/backup/local.archives
Type=aufs
Options=br:/var/mnt/hitachi-3tb-[9FA9034E]=rw:/var/mnt/toshiba-3tb-[63D9B162]=rw,create=mfs,sum,x-systemd.requires-mounts-for=/var/mnt/toshiba-3tb-[63D9B162],x-systemd.requires-mounts-for=/var/mnt/hitachi-3tb-[9FA9034E]

Видно, что зависимостей никаких не распознано, x-systemd.requires-mounts-for ушлов в параметры FS.

С какой стороны подойти к этой шайтан-машине, чтобы «просто» прописав зависимости в опциях fstab всё заработало.

Через отдельный юнит всё «просто» работает.

[Unit]
Description=Union via aufs 3tb hdd
Requires = var-mnt-hitachi\x2d3tb\x2d\x5b9FA9034E\x5d.mount var-mnt-toshiba\x2d3tb\x2d\x5b63D9B162\x5d.mount
After    = var-mnt-hitachi\x2d3tb\x2d\x5b9FA9034E\x5d.mount var-mnt-toshiba\x2d3tb\x2d\x5b63D9B162\x5d.mount

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/var/mnt/union.sh
ExecStop=/var/mnt/disunion.sh

[Install]
WantedBy = multi-user.target

union.sh:

#! /bin/bash

mount -t aufs -o br:/var/mnt/hitachi-3tb-\[9FA9034E\]=rw:/var/mnt/toshiba-3tb-\[63D9B162\]=rw,create=mfs,sum none /mnt/backup/local.archives/

systemctl enable mnt-backup-local.archives.service

В debian stable нельзя в fstab прописать зависимости, ибо, в нём systemd 215, а опции «x-systemd.{after,requires-mounts-for}=» появились в systemd 220. Вопрос закрыт.

может кабель плохой

Может и плохой, но диску от этого лучше уже не станет

198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 34

Я же не просто так написал про два способа, да?

Верно, опции x-systemd.* появились не так давно, но ты всегда можешь создать файл с именем вида /etc/systemd/system/mnt-backup-local.archives.mount.d/чтонибудь.conf и вписать в него директиву RequiresMountsFor=.

Это уже нюансы, закроем оффтоп.

Нет, неверное.

Да? А в 14.04 еще не systemd?

Не-а.