I have an external esata HD (the WD20NPVX) connected to the laptop via an esata cable to the esata port of the laptop.
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
Both /dev/sda and /dev/sdb are brand new (less than a couple of months old).
The error file is at
https://www.sendspace.com/file/ym076o
Thanx,
JD
On 08/23/2014 02:38 PM, jd1008 wrote:
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
I took a quick look at the errors and really don't like all those mentions of inodes that are doubly allocated. Have you tried using fsck on the partition?
On 08/23/2014 04:02 PM, Joe Zeff wrote:
On 08/23/2014 02:38 PM, jd1008 wrote:
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
I took a quick look at the errors and really don't like all those mentions of inodes that are doubly allocated. Have you tried using fsck on the partition?
So, it is not clear to me why there are all these errors, especially since ext4 is supposed to, by design, protect metadata's integrity in the face of such HW problems (which I am unsure what those HW problems are).
I will look for a way, such that whenever such inode errors occur, 1. mark the fs for a check upon reboot. 2. force immediate reboot.
On Aug 23, 2014, at 6:54 PM, jd1008 jd1008@gmail.com wrote:
On 08/23/2014 04:02 PM, Joe Zeff wrote:
On 08/23/2014 02:38 PM, jd1008 wrote:
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
I took a quick look at the errors and really don't like all those mentions of inodes that are doubly allocated. Have you tried using fsck on the partition?
So, it is not clear to me why there are all these errors, especially since ext4 is supposed to, by design, protect metadata's integrity in the face of such HW problems (which I am unsure what those HW problems are).
Well, no filesystem is impervious to hardware problems. Even if you have metadata and journal checksumming enabled, which isn't a default still, there is no guarantee.
Gist is, simple mount option -o journal_checksum for journal checksumming. For full metadata checksumming you need e2fsprogs 1.43. Current in F21 is 1.42.11-2, and it doesn't support mkfs.ext4 -O metadata_csum,64bit.
https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
Chris Murphy
On 08/26/2014 08:44 PM, Chris Murphy wrote:
On Aug 23, 2014, at 6:54 PM, jd1008 jd1008@gmail.com wrote:
So, it is not clear to me why there are all these errors, especially since ext4 is supposed to, by design, protect metadata's integrity in the face of such HW problems (which I am unsure what those HW problems are).
Well, no filesystem is impervious to hardware problems. Even if you have metadata and journal checksumming enabled, which isn't a default still, there is no guarantee.
Gist is, simple mount option -o journal_checksum for journal checksumming. For full metadata checksumming you need e2fsprogs 1.43. Current in F21 is 1.42.11-2, and it doesn't support mkfs.ext4 -O metadata_csum,64bit.
https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
Chris Murphy
Well, that's a shame! At least after I had done the fsck, I lost no files as lost+found was empty. But that does not mean I did not lose file data in dirty buffers.
On Aug 26, 2014, at 9:24 PM, jd1008 jd1008@gmail.com wrote:
On 08/26/2014 08:44 PM, Chris Murphy wrote:
On Aug 23, 2014, at 6:54 PM, jd1008 jd1008@gmail.com wrote:
So, it is not clear to me why there are all these errors, especially since ext4 is supposed to, by design, protect metadata's integrity in the face of such HW problems (which I am unsure what those HW problems are).
Well, no filesystem is impervious to hardware problems. Even if you have metadata and journal checksumming enabled, which isn't a default still, there is no guarantee.
Gist is, simple mount option -o journal_checksum for journal checksumming. For full metadata checksumming you need e2fsprogs 1.43. Current in F21 is 1.42.11-2, and it doesn't support mkfs.ext4 -O metadata_csum,64bit.
https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
Chris Murphy
Well, that's a shame! At least after I had done the fsck, I lost no files as lost+found was empty. But that does not mean I did not lose file data in dirty buffers.
Well, files can be lost but not found, in which case they won't be in lost+found.
Chris Murphy
On 23.08.2014, jd1008 wrote:
You have some old inodes in the inode hash list which have the same inode number. In addition, your filesystem metadata are corrupted.
I assume you have a backup of all your important data on this partition? If not, try to copy whats important to you first. After that, boot from an external medium (e.g. a CD/DVD/USB-stick) and run e2fsck on this partition. Be prepared to find a bunch of files in lost+found.
On 24.08.2014, Heinz Diehl wrote:
After that, boot from an external medium (e.g. a CD/DVD/USB-stick)..
You could burn the image onto a CD, or copy it to an USB-stick. One way to create a bootable USB-stick is to run isohybrid on the .iso image (isohybrid is in the "syslinux" package), and then cat'ing it to the stick. e.g.:
1. isohybrid sysresccd-image.iso 2. cat sysresccd-image.iso > /dev/sdX (where sdx is your USB-stick)
Alternatively, you could use a Fedora install or live CD/DVD and boot into the rescue system.
On 08/24/2014 12:06 AM, Heinz Diehl wrote:
On 24.08.2014, Heinz Diehl wrote:
After that, boot from an external medium (e.g. a CD/DVD/USB-stick)..
You could burn the image onto a CD, or copy it to an USB-stick. One way to create a bootable USB-stick is to run isohybrid on the .iso image (isohybrid is in the "syslinux" package), and then cat'ing it to the stick. e.g.:
- isohybrid sysresccd-image.iso
- cat sysresccd-image.iso > /dev/sdX (where sdx is your USB-stick)
Alternatively, you could use a Fedora install or live CD/DVD and boot into the rescue system.
Thanx Heinz.
I have done that an cleaned both sdb3 and sda3. However, I found no files in /sdb3/lost+found and also no files in /lost+found (/ is /dev/sda3)
At this point I do not have any EXT4-fs error messages in the output of dmesg and in the file /var/log/messages.
On Aug 23, 2014, at 3:38 PM, jd1008 jd1008@gmail.com wrote:
I have an external esata HD (the WD20NPVX) connected to the laptop via an esata cable to the esata port of the laptop.
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
Both /dev/sda and /dev/sdb are brand new (less than a couple of months old).
The error file is at
A more complete dmesg is best, it might reveal hardware or driver problems responsible for causing this issue in the first place. After the fact, you can get this from journalctl for all past boots with this imperfect command.
journalctl -l -k | grep -i 'ata|sdba|sdb|ext4' | grep -vi selinux
Chris Murphy
On 08/26/2014 08:31 PM, Chris Murphy wrote:
On Aug 23, 2014, at 3:38 PM, jd1008 jd1008@gmail.com wrote:
I have an external esata HD (the WD20NPVX) connected to the laptop via an esata cable to the esata port of the laptop.
I am getting ext4 errors for that device (/dev/sdb3 which is only mounted partition on that drive), and even getting ext4 errors on /dev/sda3 which is the root partition.
Both /dev/sda and /dev/sdb are brand new (less than a couple of months old).
The error file is at
A more complete dmesg is best, it might reveal hardware or driver problems responsible for causing this issue in the first place. After the fact, you can get this from journalctl for all past boots with this imperfect command.
journalctl -l -k | grep -i 'ata|sdba|sdb|ext4' | grep -vi selinux
Chris Murphy
Thanx Chris. The problems went away after I forced fsck on a followup boot. /sdb3/lost+found contained no recovered files after the fsck finished.
-
Chris Murphy -
Heinz Diehl -
JD -
Joe Zeff