similar to: EXT3-FS error and VM going Read-Only..

hi all, I installed v3.2 from source and now dom0 is booting well. But when I tried to start domU it shows the following error message and seems hanging. EXT3-fs: mounted filesystem with ordered data mode. EXT3-fs warning: mounting unchecked fs, running e2fsck is recommended EXT3 FS on hda1, internal journal device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com

I was creating some directories (mkdir xxxx) while cd'ed to a mounted LV. The first couple of directories were created but subsequent attempts give the following error: #mkdir: cannot create directory `xxxxx': Input/output error The contents of /var/log/messages shows this: Aug 5 10:48:57 inet05 kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Aug 5 10:48:57

Wondering if anyone here might better be able to diagnose an issue we're seeing, or point me to some guidelines for this sort of thing. There are two machines with identical hardware, both running Red Hat 7.3's stock SMP kernel (required due to third party software). Both have come down with the same symptoms after having run fine for a number of months. The initial errors were these:

I got a I/O error on one of my disks that caused the journal to abort (error below) and be mounted in read only mode. I rebooted and the file system check ran automatically and resolved the error. I did some searching around and couldn't find a likely cause (the disk is a virtual disk, shared from a SAN for VMWare ESXi5.0). An hour after bringing the system back up, we got another one.

We have several large ext3 file system partitions. One of them sets itself to read-only after getting journel problems. I understand that's a good thing, but obviously I need to correct the problem so that it will stop locking itself. Here are some details; OS is Redhat EL4 x86_64 running on a SunFire v40z, kernel is 2.6.9-42.0.2.ELsmp. The disk storage in question is external, via

I had a busy mailserver fail on me the other day. Below is what was printed in dmesg. We first suspected a hardware failure (raid controller or something else), so we moved the drives to another (identical hardware) machine and ran fsck. Fsck complained ("short read while reading inode") and asked if I wanted to ignore and rewrite (which I did). After booting up again, the problem came

Dear All Problem with ext3 fs on 3ware 9500S controller: Dec 7 05:59:50 stams kernel: EXT3-fs error (device sda1): ext3_add_entry: bad entry in directory #145998372: rec_len is smaller than minim al - offset=0, inode=0, rec_len=0, name_len=0 Dec 7 05:59:50 stams kernel: Aborting journal on device sda1. Dec 7 05:59:50 stams kernel: ext3_abort called. Dec 7 05:59:50 stams kernel: EXT3-fs

Hi, I'm running a production server (Debian Sarge install) whose root filesystem (a software raid 1 array of 2 partitions of IDE drive) exhibited the following problem: Oct 28 06:00:06 server2 kernel: attempt to access beyond end of device Oct 28 06:00:06 server2 kernel: md2: rw=1, want=3050401328, limit=16353920 [...] a few of the above line snipped, want is different each time Oct 28

Hi all. I have two hosts with drbd: kmod-drbd83-8.3.8-1.el5.centos drbd83-8.3.8-1.el5.centos and kernel (CentOS 5.7): 2.6.18-308.4.1.el5 After a recent upgrade of kernel I have had two sitiuations when my ext3 filesystem on /dev/drbd0 became read-only. I've checked disks with smartctl -t long, they are ok. There are no messages with disks problems in /var/log/messages | dmesg. I've made

I'm looking for some recommendations on where to go with a problem i'm running across. A filesystem under load put itself in readonly mode and the following can be found under dmesg.. any suggestions on root cause? hardware wise it's got a pair of PATA drives connected to a 3ware card in RAID10 configuration. EXT3-fs error (device dm-4): ext3_add_entry: bad entry in directory

Hi - relatively inexperienced user here. I installed CentOS 5.2 yesterday (http install via a mirror, worked brilliantly), as well as a new Seagate 1Tb USB external HDD (from the new Xtreme line), for backup/media storage. Using fdisk I put two primary partitions on the Seagate, /dev/sde1 and /dev/sde2 (roughly half the drive each). Then I used mkfs.ext3 on both to create ext3 filesystems

I recently set up a new system to run backuppc on centOS 5 with the archive stored on a raid1 of 750 gig SATA drives created with 3 members with one specified as "missing". Once a week I add the 3rd partition, let it sync, then remove it. I've had a similar system working for a long time using a firewire drive as the 3rd member, so I don't think the raid setup is the cause

Hello all. I'm using RedHat 7.2 now and haven't have any problems until today. I can still boot into the system at this time, but cannot load X at all. I'm getting the following error message when I try to run fsck. /contains a file system with errors, check forced. Pass 1: Checking inodes, blocks and sizes Error reading block 1277964 (Attempt to read block from filesystem resulted

A mysql database file was copied over to a new box running Fedora Core 1. The kernel was updated to the latest Fedora release. However mysqld complains about corrupted tables. The kernel was then updated to 2.6.5 mysqld still complains about corrupted tables. Hardware: Dual PIII 800. 3ware RAID dmesg: ... ... ... EXT3-fs error (device sdb1): ext3_free_blocks: Freeing blocks not in

I recently came across an enormous cluster of x86 clone machines running fedora core 1 (2.4.24) which have typically all intel or amd have VIA IDE chipsets. They frequently experience corrupted journals rendering the ext3 partition in read-only mode. More important than recovering the filesystem, I am interested in finding the root of the problem. The common hardware that all of these

Hi, Sorry for the need of the long winded email. Looking for some answers to the following. I am setting up a xen PV domU on top of a LVM partitioned DRBD device. Everything was going just fine until I tried to test the filesystems in the domU. Here is my setup; Dom0 OS: CentOS release 5 (Final) Kernel: 2.6.18-8.1.4.el5.centos.plusxen Xen: xen-3.0.3-25.0.3.el5 DRBD:

Hi! I noticed yet another dying IBM drive in one of my servers, producing IDE + "standard" ext3 error messages (happened during the start of a new journal methinks): ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device ide5(57,1)) in ext3_reserve_inode_write: Journal has aborted which clearly shows that

ext3 is having big problems on my x86-64 system. An ext3 partition has just gone crazy, with the following messages in dmesg: EXT3-fs error (device hda3): ext3_readdir: bad entry in directory #4603905: rec_len % 4 != 0 - offset=0, inode=2507704792, rec_len=42, name_len=0 Aborting journal on device hda3. ext3_abort called. EXT3-fs abort (device hda3): ext3_journal_start: Detected aborted journal

Hi all, I'm running a pretty updated CentOS4 x86_64 server (Still on kernel 2.6.9-42.0.2, but appart from that fully up to date against the official repos) with a USB-disk attached (the USB-disk is a 750G Seagate disk in a Seagate enclosure) over a USB hub. I've noticed several times that after longish periods of activity, the disk drops out (log from last time, below). In this case,

Hello everyone, I'm new to the list and I hope I'm not repeating something that was already asked for. I had been using the stock kernel that came with Mandrake 8.1 which is kernel 2.4.8-26mdk (not sure what things are applied to a stock 2.4.8) I have my root partition /dev/hda1 on ext3 Mandrake took care of all this, by putting the ext3 module in initrd. I just dl'ed 2.4.13