Re: recovering corrupt file system

--===============1294855252231657049==
Content-Type: multipart/alternative; boundary=001a113fb8ea22d8db0524e6db01

--001a113fb8ea22d8db0524e6db01
Content-Type: text/plain; charset=UTF-8

well, the next place to go, if fsck isn't enough would be to to try
debugfs(1)
man debugfs.

On Wed, Nov 18, 2015 at 8:39 PM, Boylan, Ross <[email protected]> wrote:

> I guess some of the trouble was that the virtual disk was mounted
> read-only at the VM level.  When I mounted read/write I was able to do
> fsck, which gave messages about replaying the logs and a couple messages
> about changing the inode counts (sorry, don't have the exact words).  Then
> I ran fsck -f, which didn't report any problems.  Then I mounted it, and
> everything seems OK.
>
> I'm still interested in the general question about how to diagnose and
> recover from file system errors, since I have another virtual machine that
> was backed by a failing real disk.
> ________________________________________
> From: Boylan, Ross
> Sent: Wednesday, November 18, 2015 4:35 PM
> To: [email protected]
> Subject: recovering corrupt file system
>
> Any recommendations for tools to diagnose and recover problems on an ext4
> file system?
>
> In particular:
> root@jessie01:~# mount -o ro /dev/markov02/root /mnt/markov02
> mount: wrong fs type, bad option, bad superblock on
> /dev/mapper/markov02-root,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
> and e2fsck says
> root@jessie01:~# e2fsck /dev/markov02/root
> e2fsck 1.42.12 (29-Aug-2014)
> /dev/markov02/root: recovering journal
> Superblock needs_recovery flag is clear, but journal has data.
>
> markov02/root is an LVM volume, built on partitions from 2 disks in a
> virtual machine.  The initial symptom was that the VM the disks were in
> originally would only get as far as busybox when it started.  However, I
> think the filesystem was OK even after that, since it was visible in
> busybox and in another VM.  I think virt-manager might have overwritten on
> of the disks because I left "allocate entire disk now" checked when I moved
> one of the disks between machines.
>
> I'm making copies of the virtual disks now.
> Ross Boylan
>
> _______________________________________________
> Ext3-users mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/ext3-users
>



-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away

--001a113fb8ea22d8db0524e6db01
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">well, the next place to go, if fsck isn&#39;t enough would=
 be to to try debugfs(1)<div>man debugfs.</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Wed, Nov 18, 2015 at 8:39 PM, Boylan=
, Ross <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I guess some of the trouble was that the virtual disk was mou=
nted read-only at the VM level.=C2=A0 When I mounted read/write I was able =
to do fsck, which gave messages about replaying the logs and a couple messa=
ges about changing the inode counts (sorry, don&#39;t have the exact words)=
.=C2=A0 Then I ran fsck -f, which didn&#39;t report any problems.=C2=A0 The=
n I mounted it, and everything seems OK.<br>
<br>
I&#39;m still interested in the general question about how to diagnose and =
recover from file system errors, since I have another virtual machine that =
was backed by a failing real disk.<br>
________________________________________<br>
From: Boylan, Ross<br>
Sent: Wednesday, November 18, 2015 4:35 PM<br>
To: <a href=3D"mailto:[email protected]">[email protected]</a><br>
Subject: recovering corrupt file system<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Any recommendations for tools to diagnose and recover problems on an ext4 f=
ile system?<br>
<br>
In particular:<br>
root@jessie01:~# mount -o ro /dev/markov02/root /mnt/markov02<br>
mount: wrong fs type, bad option, bad superblock on /dev/mapper/markov02-ro=
ot,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0missing codepage or helper program, or other err=
or<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0In some cases useful info is found in syslog - t=
ry<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0dmesg | tail or so.<br>
and e2fsck says<br>
root@jessie01:~# e2fsck /dev/markov02/root<br>
e2fsck 1.42.12 (29-Aug-2014)<br>
/dev/markov02/root: recovering journal<br>
Superblock needs_recovery flag is clear, but journal has data.<br>
<br>
markov02/root is an LVM volume, built on partitions from 2 disks in a virtu=
al machine.=C2=A0 The initial symptom was that the VM the disks were in ori=
ginally would only get as far as busybox when it started.=C2=A0 However, I =
think the filesystem was OK even after that, since it was visible in busybo=
x and in another VM.=C2=A0 I think virt-manager might have overwritten on o=
f the disks because I left &quot;allocate entire disk now&quot; checked whe=
n I moved one of the disks between machines.<br>
<br>
I&#39;m making copies of the virtual disks now.<br>
Ross Boylan<br>
<br>
_______________________________________________<br>
Ext3-users mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.redhat.com/mailman/listinfo/ext3-users" rel=3D"noref=
errer" target=3D"_blank">https://www.redhat.com/mailman/listinfo/ext3-users=
</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">Stephen Samuel <a href=3D"http://www.bcgreen=
.com" target=3D"_blank">http://www.bcgreen.com</a>=C2=A0 Software, like lov=
e, <br>778-861-7641=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 grows when you give it awa=
y</div>
</div>

--001a113fb8ea22d8db0524e6db01--


--===============1294855252231657049==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ext3-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/ext3-users
--===============1294855252231657049==--