LINUX.ORG.RU

Вынести битый диск из LVM

 ,


2

3

В томе LVM начал сыпаться один из дисков. Смарт закричал что всё плохо и я попытался вывести диск из тома и перенести его данные на другой. Однако, перенос не удался именно из-за того, что диск уже сыпется:

root@serv:~# pvmove /dev/sdd5
  /dev/sdd: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301819904: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301901824: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756146962432: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756147019776: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140767232: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140824576: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 4096: Input/output error
  Detected pvmove in progress for /dev/sdd5.
  /dev/sdd5: Moved: 100.00%
  LVM command executed by lvmpolld failed.
  For more information see lvmpolld messages in syslog or lvmpolld log file.

root@serv:~# dmesg
[134924.726640] sd 5:0:0:0: [sdd] tag#3 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[134924.726643] sd 5:0:0:0: [sdd] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[134924.726644] print_req_error: I/O error, dev sdd, sector 0
[134924.726766] sd 5:0:0:0: [sdd] tag#4 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[134924.726768] sd 5:0:0:0: [sdd] tag#4 CDB: Read(10) 28 00 ae a8 7a 80 00 00 08 00
[134924.726768] print_req_error: I/O error, dev sdd, sector 2930276992
[134924.726799] sd 5:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[134924.726800] sd 5:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 ae a8 7b 20 00 00 08 00
[134924.726801] print_req_error: I/O error, dev sdd, sector 2930277152

fsck на lvm говорит что ему норм

root@serv:~# fsck /dev/vg/data
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/mapper/vg-data: clean, 411201/457859072 files, 1188671125/1831406592 blocks

Как мне вывести диск из lvm, перенеся те данные, что еще не побились?

Физического доступа к машине нет. Раздел не системный, отмонтировать могу.

SATA-кабель пошевели или поменяй и питание проверь. Диск скорее всего в порядке.

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

Физического доступа к машине нет.

Диск - сигейт на 1.5Т с 73000 часов пробега и исчерпанным Reallocation Count. С чего ему быть в порядке?

pinus_nigra
() автор топика

Смонтировать, скопировать файлы, отмонтировать, выкинуть из группы томов.

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

Попо-дробнее пожалуйста.

Что смонтировать, отдельный раздел? Так это кусок лвм, как его смонтировать?

pinus_nigra
() автор топика
Ответ на: комментарий от Atlant
root@serv:~# pvs -o+pv_used
  /dev/sdd: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301819904: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301901824: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756146962432: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756147019776: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140767232: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140824576: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 4096: Input/output error
  PV         VG Fmt  Attr PSize    PFree    Used
  /dev/sda3  vg lvm2 a--   931.32g <227.11g  704.21g
  /dev/sda4  vg lvm2 a--   931.32g <238.29g  693.03g
  /dev/sdb5  vg lvm2 a--  <938.96g       0  <938.96g
  /dev/sdb6  vg lvm2 a--   924.05g       0   924.05g
  /dev/sdc1  vg lvm2 a--  <893.99g       0  <893.99g
  /dev/sdc2  vg lvm2 a--   878.90g       0   878.90g
  /dev/sdc3  vg lvm2 a--  <976.56g       0  <976.56g
  /dev/sdc4  vg lvm2 a--  <976.56g       0  <976.56g
  /dev/sdd5  vg lvm2 a--   704.21g   11.18g  693.03g
  /dev/sdd6     lvm2 ---  <693.04g <693.04g       0

Видно, что sdd6 я вывел из обращения, а с sdd5 фокус не удался. Причем ещё вчера эта команда Input/output error не репортила.

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

кх я не могу редактировать сообщение?

sda3 и sda4 - разделы, добавленные в лвм перед началом переноса. sdd6 успешно смигрировал на sda4, а sdd5 не смог на sda3. Причем занятый размер на sda3 соответствует размеру sdd5. Это что, значит «почти смог»?

pinus_nigra
() автор топика

Тут лучше попытаться скопировать файловую систему, чем копировать физический раздел. Файловая система будет меньше чем физический раздел, меньше вероятность попасть на нечитаемый блок. Файловую систему предварительно перевести в режим «только для чтения».

anonymous
()

Ошибки:

  1. fsck ты неправильно запускал, но это хорошо, т.к. очень опасно делать fsck на умирающем диске.

  2. При pvmove ты не указал pv назначения, оно могло тебе данные с битого на битый перенести.

Что делать:

Рейда никакого нет, правильно?

Вариант 1: смонтировать фс и перенести файлы cp -a/rsync. Файлы с ошибками восстановить из бекапа.

Вариант 2: склонировать умирающий диск через GNU ddrescue.

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

Файловую систему на логическом томе.

anonymous
()
Ответ на: комментарий от legolegs

Я за второй вариант. Только не диск, а pv с диска. Тома того диска, конечно временно тормознуть надо.

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

lvs -o+devices

root@serv:~# lvs -o+devices
  LV   VG Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  data vg -wI-a----- 6.82t                                                     /dev/sdc3(0)
  data vg -wI-a----- 6.82t                                                     /dev/sdc4(0)
  data vg -wI-a----- 6.82t                                                     /dev/sdc1(0)
  data vg -wI-a----- 6.82t                                                     /dev/sdc2(0)
  data vg -wI-a----- 6.82t                                                     /dev/sdb5(0)
  data vg -wI-a----- 6.82t                                                     /dev/sdb6(0)
  data vg -wI-a----- 6.82t                                                     /dev/sda3(0)
  data vg -wI-a----- 6.82t                                                     pvmove0(0)
pinus_nigra
() автор топика
Ответ на: комментарий от legolegs

Рейда нет.

Вариант 1: смонтировать фс и перенести файлы cp -a/rsync

Всю фc целиком? Столько свободного места нет. Можно ли вытащить данные с конкретного диска, бывшего частью LVM? Как вообще в этом lvm файлы раскладываются? Есть страйпинг между устройствами или каждый файл целиком на одном лежит?

И если можно, то как потом корректно этот диск вывести из lvm?

Вариант 2: склонировать умирающий диск через GNU ddrescue.

Это нужен чистый диск, которого в машине тоже нет.

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

Бодаться с дохлым диском надо чтобы его корректно удалить из тома и на него больше ничего не пыталось записаться.

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

Это невозможно, по-причине его дохлости

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

Это нужен чистый диск, которого в машине тоже нет.

Можешь попробовать урезать pv на других дисках, создать там разделы и склонировать туда pv. Можно и извратиться - склонировать pv в lv. Можешь вручную перенести блоки и вручную заполнить карту соответствия сегментов, но не верю, что сможешь, и не стал бы я без бэкапа такое делать.

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

Надо снести LV, потом убрать с этого диска PV, после чего заменить диск. После замены диска вернуть PV, создать lv и распаковать данные из бэкапа. В будущем использовать RAID или хотя бы мониторить смарт и менять диски до исчерпания подменного фонда секторов.

Deleted
()
Ответ на: комментарий от pinus_nigra

lvs -o+devices

Я не эксперт в lvm.

В листинге отсутствует проблемный /dev/sdd5 (если только это диск/раздел проблемный). Он как бы успешно скопировался.

Кроме тома pvmove0. «Я не эксперт»… Но этот том, вроде бы, создается как копия текущего копируемого блока (обычно размером 4 МБ, размер экстента). То есть у тебя /dev/sdd5 полностью скопировался кроме этого сбойного блока-экстента.

Тебе надо как-то создать/скопировать/восстановить этот экстент. Но тут я не советчик, как можно восстановить сбойный блок. Возможно, он не используется файловой системой, и его можно форсированно удалить.

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

Еще: посмотри все тома, включи подробный вывод, почитай маны lvm: pvs --all --verbose -o+pv_used <и другие интересные опции>

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

В листинге отсутствует проблемный /dev/sdd5 (если только это диск/раздел проблемный). Он как бы успешно скопировался.

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

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

Твоя задача: как можно больше узнать про pvmove0. Что это, где он физически находится, сколько там данных, каких данных, что с этими данными можно сделать (скопировать, восстановить, безнаказанно потерять или придется помучаться).

Я не хочу вспоминать lvm и копаться вместо тебя в манах. Будь добр, сделай это сам.

anonymous
()
Ответ на: комментарий от boowai

Можешь попробовать урезать pv на других дисках, создать там разделы и склонировать туда pv.

Вообще у меня еще есть неиспользуемый терабайтный раздел, даже два:

root@serv:~# pvs --all --verbose -o+pv_used
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
  /dev/sdd: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301819904: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 1500301901824: Input/output error
    /dev/sdd: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756146962432: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 756147019776: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd5: read failed after 0 of 4096 at 4096: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140767232: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 744140824576: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdd6: read failed after 0 of 4096 at 4096: Input/output error
  PV           VG Fmt  Attr PSize    PFree    DevSize  PV UUID                                Used
  /dev/sda1            ---        0        0    93.13g                                              0
  /dev/sda2            ---        0        0    14.90g                                              0
  /dev/sda3    vg lvm2 a--   931.32g <227.11g  931.32g Aakehs-3DxK-OXF7-hNMH-E320-ULCw-cmggjB  704.21g
  /dev/sda4    vg lvm2 a--   931.32g <238.29g  931.32g Lp9Pic-qNT1-w8PT-Sy0M-VGdJ-DDIG-DS0Fqc  693.03g
  /dev/sda5            ---        0        0   931.32g                                              0
  /dev/sda6            ---        0        0   824.02g                                              0
  /dev/sdb5    vg lvm2 a--  <938.96g       0  <938.96g LgrucF-WmCV-aMzo-Q7u2-FLBw-oq96-buK20a <938.96g
  /dev/sdb6    vg lvm2 a--   924.05g       0   924.05g lX1k6R-1PVu-mqFz-eIHt-YH7o-6vGs-bIRAL3  924.05g
  /dev/sdc1    vg lvm2 a--  <893.99g       0   893.99g cARUch-LQ26-C0A5-0jKD-8NGJ-DEPo-SmGjuy <893.99g
  /dev/sdc2    vg lvm2 a--   878.90g       0  <878.91g WxGPpB-tOxG-ruRO-maBI-zZcT-sYBs-Y19PFy  878.90g
  /dev/sdc3    vg lvm2 a--  <976.56g       0   976.56g qE9UwX-uWLD-BnBb-QES0-YFPE-202G-qOqICW <976.56g
  /dev/sdc4    vg lvm2 a--  <976.56g       0   976.56g Wjaq5k-5ike-03DS-EP2G-xf5A-iM6M-r3vto1 <976.56g
  /dev/sdd             ---        0        0     1.36t                                              0
  /dev/sdd5    vg lvm2 a--   704.21g   11.18g <704.22g dXwH69-XSIF-nTJ6-KliZ-gtrL-ZeRs-Z3Bpzs  693.03g
  /dev/sdd6       lvm2 ---  <693.04g <693.04g <693.04g qNotvS-7ACr-5WTg-rDMq-UniS-SCvk-fs02Uf       0
  /dev/vg/data         ---        0        0     6.82t                                              0

sda5 и sda6 сейчас никак не используются, могу попробовать вытащить данные туда. ddrescue никогда не использовал, результатом ее работы является некий имидж? Как мне его потом подключать в LVM?

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

Не надо тебе искать еще 7 терабайт дисков, чтобы скопировать, как тебе советуют. Ты тупо не найдешь столько, не скопируешь такой объем без пробем с проблемных дисков (включая проблемы со временем). А проблем нахватаешь больше. Тебе надо копать именно направлении pvmove0. Думаю, как только избавишься от него, ты без проблем отключишь свой проблемный диск.

anonymous
()
Ответ на: комментарий от pinus_nigra

Ddrescue делает блочную копию. Хоть в файл, хоть в раздел, лишь бы адресовалось(потоки не умеет). Отличается от обычного dd тем, что составляет карту блоков, поэтому можно сначала быстро склонировать большими кусками и пропустить ошибочные, а потом пройтись тщательно по ошибочным. На сайте их есть примеры.

В результате у тебя будет дубль pv, lvm при сканировании найдет его и даже не заметит разницы. Но, чтобы избежать конфликта, надо избавиться от оригинала, или в конфиг lvm прописать исключение sdd из сканирования.

boowai ★★★★
()

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

Вот скажи, зачем ты использовал LVM? Тебе ума не хватило для ZFS/BTRFS?

Тупость и глупость порождает таких как ты. Скоро все данные потеряешь. )))

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

Скоро все данные потеряешь. )))

Я бы посмотрел как zfs и btrfs вышли бы из такой ситуации без избыточности. Думаю, невостановимо легли бы раньше, так как у них чуть-чуть нерабочее состояние не отличается от полностью нерабочей.

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

Тупость и глупость порождает таких как ты. Скоро все данные потеряешь. )))

Тупость и глупость порождает такие советы. Здесь нужно 1. Иметь бэкап. 2. Если имеет смысл - создавать отказоустойчивость избыточностью. 3. Мониторинг, чтобы предупредить проблемы.

Deleted
()
Ответ на: комментарий от Deleted
  1. Иметь бэкап. 2. Если имеет смысл - создавать отказоустойчивость избыточностью. 3. Мониторинг, чтобы предупредить проблемы.

Еще один дурачек. Иди в школу.

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

Аргументов нет. Жаль, хреновый ты анонимус. Правильный анонимус бы не обосрался, а по полочкам меня раскатал.

Deleted
()
Ответ на: комментарий от pinus_nigra
  1. Покажи lvs -ao lv_name,lv_size,lv_attr,raid_sync_action,sync_percent,devices

  2. У тебя диск умирает, ты рискуешь потерей данных всего массива, если не принять меры - развалится весь /dev/vg/data и есть риск потерять все данные и долго и дорого их выколупывать. Тут не должно быть этого детского сада «нет места», «нет запасного диска».

  3. pvmove - это по сути такой временный raid1, который синкается, затем сразу удаляется. Он, похоже, по-прежнему синкаектся, дрюча умирающий диск.

  4. ddrescue делает две вещи: побайтовую копию с нулями там, где не удалось прочитать из-за ошибок и файл лога с картой проблемных мест.

  5. Моя рекомендация такая: отмонтировать /dev/vg/data, как-то остановить pvmove, больной диск и хороший пустой воткнуть в другую машину и там склонировать через ddrescue.

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

Нехорошо сперва просить помощи, а потом ответившего обзывать дебилом, но тут я других вариантов как-то и не вижу, увы.

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

У тебя диск умирает, ты рискуешь потерей данных всего массива

Это печально.

Тут не должно быть этого детского сада «нет места», «нет запасного диска».

Машина стоит в моей питерской квартире, а я зимую в юго-восточной азии. В машине нет места и нет запасного диска. И до марта в квартире никто не появится.

Сам дурак, что не поменял древний диск давным-давно? Не спорю. Виноват застой в технологиях: раньше место заканчивалось быстрее и диски в сторадже менялись чаще. А сейчас эта полторашка - самая старая в массиве и у нее Power_On_Hours - 73000 часов. Конечно, так жить нельзя.

Покажи lvs -ao lv_name,lv_size,lv_attr,raid_sync_action,sync_percent,devices

root@serv:~# lvs -ao lv_name,lv_size,lv_attr,raid_sync_action,sync_percent,devices
  LV        LSize   Attr       SyncAction Cpy%Sync Devices
  data        6.82t -wI-a-----                     /dev/sdc3(0)
  data        6.82t -wI-a-----                     /dev/sdc4(0)
  data        6.82t -wI-a-----                     /dev/sdc1(0)
  data        6.82t -wI-a-----                     /dev/sdc2(0)
  data        6.82t -wI-a-----                     /dev/sdb5(0)
  data        6.82t -wI-a-----                     /dev/sdb6(0)
  data        6.82t -wI-a-----                     /dev/sda3(0)
  data        6.82t -wI-a-----                     pvmove0(0)
  [pvmove0] 693.03g p-C-aom---            100.00   /dev/sdd5(0),/dev/sda4(0)
pinus_nigra
() автор топика
Ответ на: комментарий от pinus_nigra

Ого, у тебя pvmove застрял. Хорошая новость что на 100%, правда на самом деле это может быть 99.9%.

legolegs ★★★★★
()
Ответ на: комментарий от pinus_nigra
  data        6.82t -wI-a-----                     pvmove0(0)
  [pvmove0] 693.03g p-C-aom---            100.00   /dev/sdd5(0),/dev/sda4(0)

Останови перемещение pvmove --abort

После этого всё, что переместилось, будет на sda4, то что не перенеслось (бедблоки), останется sdd5 (если не извращался с атомарностью pvmove).

После остановки посмотри lvs -a -o+devices. Еще можно посмотреть pvdisplay /dev/sdd5 - покажет сколько не перенеслось.

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

И да. Если не хочешь сам читать маны по lvm, то скажи (заплати) кому-нибудь другому сделать, что ты сам не хочешь или не умеешь.

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

man pvmove

–abort

Abort any pvmove operations in progress ......
segments that have been moved will remain on the destination PV, while
unmoved segments will remain on the source PV.

Дальше придется заняться хирургией. Либо занулить оставшиеся блоки, чтобы диск их заремапил и дал закончить повторный pvmove или попытаться спасти данные ddrescue или в конторе data recovery.

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

Дальше придется заняться хирургией.

А до этого что, не хирургия над терабайтной тушей?

Остановить перемещение в любом случае надо, иначе так и будет дрочить битый диск, пока полностью не добъет.

А после остановки будет препарировать только те куски, которые не перместились.

Хотя, врядли он что-то сделает. Тупо без понимания вводит подкинутые команды. Можно подсунуть команду, которая похерит все данные. Будет ему урок на будущее.

anonymous
()

По сети на другой сервер залить не вариант? Скорость интернета какая по договору?

Могу одолжить 1,5 тб места.

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

Всё, сливайте воду. Машину пришлось перегрузить и из ребута она не вышла. Видимо, просит нажать any key to continue. Так что я улыбаюсь и машу массиву на прощание. В марте буду смотреть, что от него осталось.

Всем спасибо за участие.

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

Диск - сигейт

Seagate это не диск, а насмешка.

С ZFS заменить (вывести из RAIDZ невозможно; из RAID-1 можно, если в зеркале более двух дисков) диск было бы проще, с LVM уже не помню как и что, но там тоже не так сложно. С зашифрованными дисками чуть больше телодвижений.

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

О хирургии. Я забыл о возможности клонировать в разреженный файл, если pv почти не занят. Для ddrescue можно было составить карту по информации о сегментах, клонировать с --sparse.

boowai ★★★★
()
15 марта 2020 г.
Ответ на: комментарий от legolegs

Если кому интересно - я приехал с зимовки, готовясь выкачивать все данные заново с порнолаба бэкапа. Но случилось внезапное - яничегонеделал, оносамопочинилось.

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

root@serv:~# pvs -o+pv_used
  PV         VG Fmt  Attr PSize    PFree    Used
  /dev/sda3  vg lvm2 a--   931.32g <227.11g  704.21g
  /dev/sda4  vg lvm2 a--   931.32g <238.29g  693.03g
  /dev/sdb5  vg lvm2 a--  <938.96g       0  <938.96g
  /dev/sdb6  vg lvm2 a--   924.05g       0   924.05g
  /dev/sdc1  vg lvm2 a--  <893.99g       0  <893.99g
  /dev/sdc2  vg lvm2 a--   878.90g       0   878.90g
  /dev/sdc3  vg lvm2 a--  <976.56g       0  <976.56g
  /dev/sdc4  vg lvm2 a--  <976.56g       0  <976.56g
  /dev/sdd5  vg lvm2 a--   704.21g  704.21g       0
  /dev/sdd6     lvm2 ---  <693.04g <693.04g       0

Какие-то файлы наверное побились, но с этим буду разбираться по ходу пьесы.

Так что всем спасибо за помощь, такая вот внезапная история узбека.

Теперь не знаю даже, продолжать ли использовать LVM. Будь тут отдельные разделы со своими точками монтирования /data1, /data2 итд - шаманить пришлось бы меньше. С другой стороны, решение в свое время нарезать диски +/- терабайтными кусками и оставить несколько свободных в итоге оказалось правильным. Что посоветуете?

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

lvm стандартно советуют поверх отказоустойчивого массива. Но, если у вас есть резервная копия, то может и оставить как есть.

Или можно mhddfs для объединения /data1, /data2, ... , но FUSE.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.