dead hard drive - lvm

[milomak]

i have a lvm partition (no redunancy)

300gb + 2tb disks (it’s a media pc so i am not to concerned about all the data - save for config files)

300gb has failed per smartctl. debian install on it. something like a 100gb debian parttion and the 200gb balance added to the lvm.

i think i had just about 300gb free on the lvm.

let’s assume that i have enough free space to remove the pv that has failed; and i buy a new disk to add on; could i get this pc to reboot with the installed debian?

as i typed this it dawned on me that the debian partition with the config files i might want is dead isn’t it?

[p.H]

300gb has failed per smartctl

Is the system still running ?
Can you post the output of

Code: Select all

smartctl -a /dev/"the drive"

i think i had just about 300gb free on the lvm.

Can you post the output of "pvs" and "vgs" ?

could i get this pc to reboot with the installed debian?

Not sure I understand your question.

[cynwulf]

If the 300GB drive has failed, and you have no redundancy, then unless I'm "missing the wood for the trees" here, you've lost the 100GB partition which contained the OS, plus the remaining 200GB which was part of the LVM.

[milomak]

If the 300GB drive has failed, and you have no redundancy, then unless I'm "missing the wood for the trees" here, you've lost the 100GB partition which contained the OS, plus the remaining 200GB which was part of the LVM.

that's pretty much what i thought. was throwwing a hail mary really.

[p.H]

If the 300GB drive has failed

Yeah, "if". But we do not know if the drive really failed. All the OP said is "failed per smartcl", but that does not mean much. Clarifications are needed and were requested.

[milomak]

so i eventually booted the system from a livecd

there drive is there (i can mount and have copied the settings i would want when i reintsall onto a new drive) and the lvm is still fine (that is the portion that is on the failing drive doesn't seem to be causing any lvm issues) for the moment. obviously smart fears the drive will be gone any time soon.

i'll post pvs and vgs

[p.H]

I'm more interested in the output of smartcl.

[milomak]

I'm more interested in the output of smartcl.

i have that more readily at hand - https://pastebin.com/VLuq4pPF

[p.H]

Code: Select all

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   133   133   140    Pre-fail  Always   FAILING_NOW 561
196 Reallocated_Event_Count 0x0032   192   192   000    Old_age   Always       -       8
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       29

The drive has too many reallocated sectors, and worse, unreadable used sectors. Time to replace it.

[milomak]

for completeness sake

# pvs

Code: Select all

  PV         VG     Fmt  Attr PSize   PFree
  /dev/sda1  pvr lvm2 a--   <2.73t    0 
  /dev/sdb2  pvr lvm2 a--  624.41g    0 

# vgs

Code: Select all

  VG     #PV #LV #SN Attr   VSize  VFree
  pvr      2   1   0 wz--n- <3.34t    0 

[milomak]

things are not as rosy as i thought they might be

# resize2fs -p /dev/pvr/pvr 2730G

Code: Select all

resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/pvr/pvr to 715653120 (4k) blocks.
Begin pass 2 (max = 122653549)
Relocating blocks             XXXXXXXXXXXXXXXresize2fs: Attempt to read block from filesystem resulted in short read while trying to resize /dev/pvr/pvr
Please run 'e2fsck -fy /dev/pvr/pvr' to fix the filesystem
after the aborted resize operation.

# e2fsck -fy /dev/pvr/pvr

Code: Select all

e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/pvr/pvr: 18642/224067584 files (6.7% non-contiguous), 667248174/896251904 blocks

# resize2fs -p /dev/pvr/pvr 2730G

Code: Select all

resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/pvr/pvr to 715653120 (4k) blocks.
Begin pass 2 (max = 122653549)
Relocating blocks             XXXXXXXXXXXXXXXresize2fs: Attempt to read block from filesystem resulted in short read while trying to resize /dev/pvr/pvr
Please run 'e2fsck -fy /dev/pvr/pvr' to fix the filesystem
after the aborted resize operation.

[p.H]

I guess resize2fs hit one of the unreadable sectors (current_pending_sector).
You could try to run e2fsck -c to isolate such bad blocks but it may delete the files these blocks are allocated to.

[milomak]

I guess resize2fs hit one of the unreadable sectors (current_pending_sector).
You could try to run e2fsck -c to isolate such bad blocks but it may delete the files these blocks are allocated to.

tried e2fsck -fyc

it hits a bad sector then hangs

thankfully i've been able to get what i would want to keep so can replace the failing drive and reinstall from scratch if it comes to that

[p.H]

Some SSD and hard drives seem to just hang after failing to read a number of bad sectors and won't respond until a hard reset. Great behaviour...

[yodamin]

The hanging on a bad sector happened to me or at least I thought it did - I shut down the system, removed the hard drive and banged it again my desk a couple times (not lightly but not like a hammer either pretend you dropped it from about 4-5 inches above your desk kinda thing) to dislodge the head (I KNOW risky) and though worked enough for me to copy 119GB out of 187GB that as a potential loss.

The banging to unstick the head was a LAST resort before I tossed it into the recycle bin kinda thing and it worked - kinda sorta.
The end user was happy to get what he got.

[milomak]

so it's probably unlikely i wont be able to save this lvm?

i'll do a vgcfgbackup anyway. remove the problematic disk. reinstall on the new disk. and see if i can get the lvm going again.