Bug 139053 - Filesystem provides error and fails to write, fsck shows errors
Filesystem provides error and fails to write, fsck shows errors
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-12 14:02 EST by Xander D Harkness
Modified: 2016-06-07 18:45 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-19 09:58:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Xander D Harkness 2004-11-12 14:02:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041104 Firefox/1.0RC1

Description of problem:
I have an Volume Group spanning three hard drives.  Every day I get
hard drive errors and I cannot write to the volume group.

I run fsck and get the following errors:

sck -y /dev/backup/data
fsck 1.32 (09-Nov-2002)
e2fsck 1.32 (09-Nov-2002)
/dev/backup/data contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 66060326 (Attempt to read block from filesystem
resulted in short read) while doing inode scan.  Ignore error? yes

Force rewrite? yes

Error reading block 67993639 (Attempt to read block from filesystem
resulted in short read) while doing inode scan.  Ignore error? yes

Force rewrite? yes

Error reading block 67994238 (Attempt to read block from filesystem
resulted in short read) while reading indirect blocks ofinode
33996818.  Ignore error? yes

Force rewrite? yes

Inode 33996818, i_blocks is 1200, should be 104.  Fix? yes

I have not tried re-installing to recreate the problems.

vgdisplay  -v
--- Volume group ---
VG Name               backup
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               1
MAX LV Size           2 TB
Max PV                256
Cur PV                3
Act PV                3
VG Size               562.38 GB
PE Size               32 MB
Total PE              17996
Alloc PE / Size       17996 / 562.38 GB
Free  PE / Size       0 / 0
VG UUID               lQXumX-wf0E-YcVU-vFrX-OIg6-YcEP-sVPNdP

--- Logical volume ---
LV Name                /dev/backup/data
VG Name                backup
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 1
LV Size                562.38 GB
Current LE             17996
Allocated LE           17996
Allocation             next free
Read ahead sectors     1024
Block device           58:0


--- Physical volumes ---
PV Name (#)           /dev/hdc1 (3)
PV Status             available / allocatable
Total PE / Free PE    6076 / 0

PV Name (#)           /dev/hdd1 (2)
PV Status             available / allocatable
Total PE / Free PE    5960 / 0

PV Name (#)           /dev/hdb1 (1)
PV Status             available / allocatable
Total PE / Free PE    5960 / 0


Version-Release number of selected component (if applicable):
kernel-2.4.21-20.EL

How reproducible:
Always

Steps to Reproduce:
1.I have a VG that I read and write to daily
2. When it refuses to allow writes I have to unmount the LV and run fsck
3. Mount LV partition again and it will work for a short while.
    

Actual Results:  Errors reoccur and I have to fsck

Expected Results:  The ard drives should run with fewer errors.

Additional info:
Comment 1 Ernie Petrides 2004-11-12 18:12:41 EST
Are there errors in /var/log/messages from the disk driver
regarding i/o failures on the drive(s) in question?
Comment 2 Tom Coughlan 2004-12-22 09:43:26 EST
Please post /var/log/messages, showing boot messages, and any i/o
errors  that the driver may be reporting. 

Also, try running the badblocks utility on each disk. 
Comment 3 Tom Coughlan 2005-09-19 09:58:32 EDT
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product.

Note You need to log in before you can comment on or make changes to this bug.