similar to: EXT3 Problem.

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

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

Dear xen-users, in the last two days, two different domUs on two different dom0s had suddenly corrupted filesystems which let to total data loss on both domUs. I have never suffered under this failure before and I guess it is related to XEN. Both domUs were running for long time without any problems and I am pretty sure, that the hard drives are fine (checked with smart checks).

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

All, I know that there is no official port to Kernel 2.4.4, thus I may not get any help, however I am hoping someone could point me in the right direction for my problem. I am currently forced to use kernel 2.4.4 for reasons out of my control (embedded board). Here are the exact versions of everything I'm running: ExT3 Version: ext3-2.4-0.9.6-248 Util Version: util-linux-2.11f.tar.bz2 e2fs

Hey, I've a problem with an ext3 filesystem and don't know how to fix it or find the failure :( The Hardware: Tyan mainboard, AMD Athlon CPU, ARECA ARC-1120 RaidController Raid5 with 400GB Seagate HD's, 756 MB Ram, other harddisks for system, network and avm isdn controller. Couse of the filesystem problems I run memtest and found one bad memory module which I replaced yet. The

I've been trying to use fsck to recover a corrupted filesystem. It appears the original superblock is corrupted too, as it has an inode count of 0. When I start fsck with -b 32760, it uses the alternate superblock and proceeds. However, it restarts from the beginning a couple of times and after the second restart it doesn't use the alternate superblock, stopping instead as it can't

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,

Hi, I recently upgraded one of my fileservers from 2.4.16 to 2.4.18 plus the ext3-cvs.patch that Andrew Morton pointed me to for addressing and assertion failure. Since then I have been getting lots of errors like: May 21 14:07:03 glass kernel: EXT3-fs error (device md(9,0)): ext3_add_entry: bad entry in directory #2945366: rec_len %% 4 != 0 - offset=0, inode=1886221359, rec_len=24927,

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

A change was made to ext3 in 2.4.20-pre9 which will cause the filesystem to run ext3_mark_inode_dirty() against a freed inode. This will occur when an application attempts to add a new file/directory to the filesystem and encounters space or inode exhaustion. The results of this are unpredictable. Usually, nothing happens. But it can cause random memory corruption on SMP, and the kernel will

Hello ext3-users, I tested ext3 on a Linux for S/390 with several stress and benchmark test tests and faced a kernel bug message. The console showed the following output: Message from syslogd@boeaet34 at Fri Aug 3 11:34:16 2001 ... boeaet34 kernel: Assertion failure in journal_forget() at transaction.c:1184: "! jh->b_committed_data" I tried the Patch from

While compiling two kernels and untarring a third, my root fs was remounted r/w and I got the following in dmesg (kernel 2.4.19-pre9): EXT3-fs error (device ide0(3,2)) in ext3_new_inode: error 28 Aborting journal on device ide0(3,2). ext3_abort called EXT3-fs abort (device ide0(3,2)): ext3_journal_start: Detected aborted journal. Remounting filesystem read-only Remounting filesystem read-only

Just wondering if someone could help me debug this: I was moving data from an ATARAID (via Promise FastTrack100 Controller) into the LVM device below: 58,1: # cat /proc/lvm/VGs/foo3/LVs/bar name: /dev/foo3/bar size: 476315648 access: 3 status: 1 number: 0 open: 1 allocation: 0 device: 58:01 # /sbin/pvscan pvscan -- reading all physical volumes

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 recently bought 2 different USB flash disks. These are some cheap no-name devices. Their parameters: bytes C/H/S ID 4194304512 509/255/63 Vendor: Generic Model: USB Flash Drive Rev: 1.00 ANSI SCSI revision: 02 4288676352 1023/132/62 Vendor: USB Model: USB 2.0 Rev: 1.00 ANSI SCSI revision: 02 When I put a FAT32 filesystem on them,

This patch adds jbd_lock_bh_state() and jbd_unlock_bh_state() around accessses to jh->b_committed_data. Fixes oss bugzilla#1131 http://oss.oracle.com/bugzilla/show_bug.cgi?id=1131 Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com> --- fs/ocfs2/suballoc.c | 28 ++++++++++++++++++++++++---- 1 files changed, 24 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/suballoc.c

On Monday August 4, akpm@osdl.org wrote: > Daniel Jacobowitz <dan@debian.org> wrote: > > > > I came back this morning and found: > > EXT3-fs error (device md0) in start_transaction: Journal has aborted > > EXT3-fs error (device md0) in start_transaction: Journal has aborted > > EXT3-fs error (device md0) in start_transaction: Journal has aborted >

[sorry if this isn't threaded right... I just subscribed] Theodore Ts'o wrote: > > There are two reasons for the reserve. One is to reserve space on the > partition containing /var and /etc for log files, etc. The other is > to avoid the performance degredation when the last 5-10% of the disk > space is used. (BSD actually reserves 10% by default.) Given that > the

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