LINUX.ORG.RU
Форум — Admin  

SSD пуст!

 , ,


1

4

Добрый вечер!

Месяц назад поставил на нетбук систему (на SSD), создав на нём сначала LVM, а затем 4 раздела: root, home, swap, crypt. Делал по-уму, с тримом и прочими задержками записи. Всё шло гладко до вчерашнего вечера.
Нетбук я практически не выключал, а погружал в сон. И вот вчера вместо пробуждения он выдал это и не реагировал даже на Alt+Print+B. После перезапуска на SSD не оказалось таблицы разделов.
В попытках всё вернуть были задействованы testdik и gdisk. Оба увидели два раздела: root и home, но при восстановлении они не читаются (тут видимо надо сам LVM восстанавливать, но как?).

Кто виноват и что делать?

← Каким механизмом подать сигнал при старте демона и обработать его в другом демоне?
малина сервер →

Ответ на: комментарий от fornlr

А теперь подробно и без эмоций, что плохого в задержке записи ядра на нетбуке?

Strannik-j ★★
() автор топика

создав на нём сначала LVM

В таблице разделов был создан только один раздел (типа: 8е lvm)? Если да, то создай такой же раздел fdisk'ом и запусти pvscan или vgscan -vvvv

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

root@kubuntu:/home/kubuntu# pvscan -vvvv 

#libdm-config.c:863       Setting activation/monitoring to 0
#lvmcmdline.c:1093         Processing: pvscan -vvvv
#lvmcmdline.c:1096         O_DIRECT will be used
#libdm-config.c:799       Setting global/locking_type to 1
#libdm-config.c:799       Setting global/wait_for_locks to 1
#locking/locking.c:242       File-based locking selected.
#libdm-config.c:768       Setting global/locking_dir to /run/lock/lvm
#libdm-config.c:863       Setting global/prioritise_write_locks to 1
#locking/file_locking.c:236       Locking /run/lock/lvm/P_global WB
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global:aux WB
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global WB
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global:aux
#filters/filter-persistent.c:58     Wiping cache of LVM-capable devices
...
#device/dev-cache.c:347         /dev/sda: Added to device cache
#device/dev-cache.c:344         /dev/disk/by-id/ata-TS128GSSD340_20140516B45394025368: Aliased to /dev/sda in device cache
#device/dev-cache.c:344         /dev/disk/by-id/wwn-0x5000000000000000: Aliased to /dev/sda in device cache
#device/dev-cache.c:347         /dev/sda1: Added to device cache
#device/dev-cache.c:344         /dev/disk/by-id/ata-TS128GSSD340_20140516B45394025368-part1: Aliased to /dev/sda1 in device cache
#device/dev-cache.c:344         /dev/disk/by-id/wwn-0x5000000000000000-part1: Aliased to /dev/sda1 in device cache
#device/dev-cache.c:344         /dev/disk/by-partuuid/551da180-d6ac-4d65-a8ea-91053bdde917: Aliased to /dev/sda1 in device cache
...
#cache/lvmcache.c:1601     Wiping internal VG cache
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_lvm1
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_pool
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_lvm2
#pvscan.c:268     Walking through all physical volumes
...
#device/dev-io.c:524         Opened /dev/sda RO O_DIRECT
#device/dev-io.c:271       /dev/sda: size is 250069680 sectors
#device/dev-io.c:137         /dev/sda: block size is 4096 bytes
#filters/filter.c:132         /dev/sda: Skipping: Partition table signature found
#device/dev-io.c:577         Closed /dev/sda
...
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:271       /dev/sda1: size is 250066944 sectors
#device/dev-io.c:577         Closed /dev/sda1
#device/dev-io.c:271       /dev/sda1: size is 250066944 sectors
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:137         /dev/sda1: block size is 4096 bytes
#device/dev-io.c:577         Closed /dev/sda1
#filters/filter-composite.c:31         Using /dev/sda1
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:137         /dev/sda1: block size is 4096 bytes
#label/label.c:156       /dev/sda1: lvm2 label detected at sector 1
#cache/lvmcache.c:1336         lvmcache: /dev/sda1: now in VG #orphans_lvm2 (#orphans_lvm2) with 0 mdas
#device/dev-io.c:577         Closed /dev/sda1
...
#label/label.c:266         Using cached label for /dev/sda1
#label/label.c:266         Using cached label for /dev/sda1
  PV /dev/sda1                      lvm2 [119.24 GiB]
  Total: 1 [119.24 GiB] / in use: 0 [0   ] / in no VG: 1 [119.24 GiB]
#locking/file_locking.c:74       Unlocking /run/lock/lvm/P_global
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global

root@kubuntu:/home/kubuntu# vgscan -vvvv 

#libdm-config.c:863       Setting activation/monitoring to 0
#lvmcmdline.c:1093         Processing: vgscan -vvvv
#lvmcmdline.c:1096         O_DIRECT will be used
#libdm-config.c:799       Setting global/locking_type to 1
#libdm-config.c:799       Setting global/wait_for_locks to 1
#locking/locking.c:242       File-based locking selected.
#libdm-config.c:768       Setting global/locking_dir to /run/lock/lvm
#libdm-config.c:863       Setting global/prioritise_write_locks to 1
#locking/file_locking.c:236       Locking /run/lock/lvm/P_global WB
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global:aux WB
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global WB
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global:aux
#filters/filter-persistent.c:58     Wiping cache of LVM-capable devices
...
#device/dev-cache.c:344         /dev/disk/by-id/ata-TS128GSSD340_20140516B45394025368: Aliased to /dev/sda in device cache
#device/dev-cache.c:344         /dev/disk/by-id/wwn-0x5000000000000000: Aliased to /dev/sda in device cache
#device/dev-cache.c:347         /dev/sda1: Added to device cache
#device/dev-cache.c:344         /dev/disk/by-id/ata-TS128GSSD340_20140516B45394025368-part1: Aliased to /dev/sda1 in device cache
#device/dev-cache.c:344         /dev/disk/by-id/wwn-0x5000000000000000-part1: Aliased to /dev/sda1 in device cache
#device/dev-cache.c:344         /dev/disk/by-partuuid/551da180-d6ac-4d65-a8ea-91053bdde917: Aliased to /dev/sda1 in device cache
...
#cache/lvmcache.c:1601     Wiping internal VG cache
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_lvm1
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_pool
#cache/lvmcache.c:1338         lvmcache: initialised VG #orphans_lvm2
#toollib.c:589     Finding all volume groups
...
#device/dev-io.c:524         Opened /dev/sda RO O_DIRECT
#device/dev-io.c:271       /dev/sda: size is 250069680 sectors
#device/dev-io.c:137         /dev/sda: block size is 4096 bytes
#filters/filter.c:132         /dev/sda: Skipping: Partition table signature found
#device/dev-io.c:577         Closed /dev/sda
...
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:271       /dev/sda1: size is 250066944 sectors
#device/dev-io.c:577         Closed /dev/sda1
#device/dev-io.c:271       /dev/sda1: size is 250066944 sectors
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:137         /dev/sda1: block size is 4096 bytes
#device/dev-io.c:577         Closed /dev/sda1
#filters/filter-composite.c:31         Using /dev/sda1
#device/dev-io.c:524         Opened /dev/sda1 RO O_DIRECT
#device/dev-io.c:137         /dev/sda1: block size is 4096 bytes
#label/label.c:156       /dev/sda1: lvm2 label detected at sector 1
#cache/lvmcache.c:1336         lvmcache: /dev/sda1: now in VG #orphans_lvm2 (#orphans_lvm2) with 0 mdas
#device/dev-io.c:577         Closed /dev/sda1
...
#toollib.c:593   No volume groups found
#locking/file_locking.c:74       Unlocking /run/lock/lvm/P_global
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global

Это обрезаный вывод, SSD - /dev/sda (sda1 - это lvm-раздел).

Strannik-j ★★
() автор топика
Ответ на: комментарий от TERRANZ

ссд и так надёжностью не блещет, так ты и lvm использовал

Каким макаром lvm коррелирует с надёжностью? lvm может и повышать надёжность, mirror-тома никто пока не отменял.

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

Причем сам ssd жив (ему и двух месяцев нет), и именно этот факт меня и пугает. Что, блин, произошло? Почему совершенно здоровый ссд похерил всю таблицу? И что скрывает текст на скриншоте?

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

Strannik-j ★★
() автор топика

везет тебе, а у меня TRIM отработал при подобном случае и вычистил полностью диск :) хорошо что я делаю ежедневные снапшоты.

ktk ★★★★
()
Ответ на: комментарий от Strannik-j

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

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

Один в один как у меня, исключая то, что шифрованый у меня был только один раздел.

Я тут подумал, может f2fs попробовать? Кто как считает?

Strannik-j ★★
() автор топика

Делал по-уму

И я тоже, т.е. предоставил debian-installer'у возможность решать что там и как разметить. УМВР. Не помню сколько годов.

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

я щитаю красноглазая шкалата должна аццки стродать. так что пробуй, пробуй мальчег.

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

Один в один как у меня, исключая то, что шифрованый у меня был только один раздел.

нет, у меня TRIM всё нулями забил, а у тебя что-то осталось.

ktk ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Каким механизмом подать сигнал при старте демона и обработать его в другом демоне?
Admin
малина сервер →