Hi Andreas, Thanks a lot for taking the time to answer my plea for help. :) On Tue, Oct 10, 2017 at 1:36 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > If the problem is only one of the partition being misaligned compared > to the logical volume, you can run the "findsuper" utility which is > part of e2fsprogs *sources* (it isn't built and packaged by default). > It will scan your block device and print out the ext2/3/4 superblocks > that it finds, along with the *byte* offset of each one found. You > can use this to determine where the start of the filesystem should be. I will give this a try, thanks. Although I don't really had any issue to mount the filesystem r/o, which seems to indicate that there is no misalignment issue, right? > This is made *much* more complex if you have other LVs on the same > storage, and the LV was increased in size over multiple iterations, > resulting in a fragmented allocation of PEs. Just one LV there. >> $ ls /vol >> ls: cannot access backup: Input/output error >> drwxr-xr-x 2 root root 4096 Sep 28 11:10 . >> drwxr-xr-x 4 root root 4096 Sep 14 2013 .. >> -????????? ? ? ? ? ? backup >> [...] >> >> I re-remounted read-only as soon as I realized my mistake, but the >> filesystem stayed mounted r/w for a few minutes. > > It sounds like this replayed a corrupted journal over the rest of your > filesystem, leading to further corruption. Ah I see. So even of no process was actively writing to the filesystem, simply remounting it read-write made it replay an old journal? I know I shouldn't have done that, but I really didn't expect so much impact: there's probably only around 15-20% of the original data left... :( > My only recommendation would be to update to the latest e2fsprogs, > since it usually fixes important issues found in older versions. Will make sure to use the latest one. > Seems unlikely, unless you have an LVM snapshot. I so wish, but I don't. :( > e2fsck is good at recovering what files are available, much better > than other filesystem recovery tools, but it can only work with the > data it has. So, another question: given e2fsck doesn't complain about a missing or damaged superblock, is there any reason why running it with an alternative superblock (with -b) would yield different results? Thanks! -- Kilian
