4

My RAID1 array /dev/md1 is rebuilding after one of the disks has been replaced. Problem : the source disk has Unrecoverable Errors, and my only choice if I do not want to lose the whole data set (no backup, no excuse) is to patiently write to the faulty sectors with hdparm --write-sector 0123456789 --yes-i-know-what-i-am-doing /dev/sde (my source disk) so that the process can keep on. I know that some of my files are going to be corrupted because I'm writing zeroes in some of the sectors they are stored in. Now I need to identify these files with debugfs and treat them accordingly.

My volume layout is as follows :

Relevant possibly corrupted file is "here" --+
... but what is its inode ?                  |
                                             v
+-----------------------------------------------+
|                Ext4 filesystem                |
+-----------------------------------------------+
|                     LVM LV                    |
+------------------------+----------------------+
|         LVM PV         |        LVM PV        |
+------------------------+----------------------+
|       /dev/md127       |       /dev/md1       |
|                        |                      |
|<- 1953524992 sectors ->|<-1953522848 sectors->|
+-----------+------------+-----------+----------+
|  /dev/sdd |  /dev/sdc  | /dev/sdb  | /dev/sde |
+-----------+------------+-----------+----------+
                                             ^
                                             |
Problematic sector 1697876848 on /dev/sde ---+

So far, I "blanked out" sectors 1697876848, 1524606517, 1524609475, etc. on /dev/sde and restarted recovery each time to let it finish.

Considering the different offsets (RAID + LVM), how can I calculate the inodes and identify the affected files ?

Hoggins
  • 41
  • 3
  • possible duplicate: http://serverfault.com/questions/315700/how-to-determine-which-file-inode-occupies-a-given-sector – neutrinus Sep 22 '15 at 21:37
  • Actually @neutrinus, the issue you mention is quite alike (same tools, same methodology), except that my setup is more complicated, as it involves various offsets and block size calculations due to different layers such as RAID1 and LVM. I couldn't find what I need there. – Hoggins Sep 22 '15 at 21:44
  • The first link resolved the idea of partitions, here are LVMs: http://serverfault.com/questions/510895/find-file-by-block-number-on-ext3-fs-on-lvm Raid1 should be just a copy so no need to recalculate offsets. – neutrinus Sep 24 '15 at 14:11
  • Of course, RAID1 is just a copy. But I have two, so let's assume my bad sector is `1697876848` of `/dev/md1`, and not of `/dev/sde`. As you mentioned, there is no difference here. But shouldn't we consider that my Logical Volume is made of two devices, `/dev/md127` and `/dev/md1`, and so, to determine where my file is on the LVM, shouldn't I somehow take the total number of sectors of `/dev/md127` into account, as an offset ? – Hoggins Sep 24 '15 at 17:49
  • ... updated the original question with sector counts and "file position", for my own reference, as well as for trying to pinpoint the actual problem here : LVM layout makes the two `md127` and `md1` block devices forming a JBOD "concatenated" disk. It makes it more difficult for me to find the file, even with explanations from issue http://serverfault.com/questions/510895/find-file-by-block-number-on-ext3-fs-on-lvm. – Hoggins Sep 26 '15 at 17:59

0 Answers0