similar to: problems with rh 7.2

hello! i'm using redhat 7.2 with ext3 as my primary fs on kernel 2.4.17 + grsecurity + acl after 2-3 days of uptime i'm expiriencing problems... i attached below excert from my system logs. machine stops responing for a few seconds and after then it looks, like it's in normal operation again. the only problem is load, which is incrementing constantly, but cpu is 99% idle... after

Hello ext3-users, we have an oopsy situation here: we have 4 machines: 3 client nodes, 1 master: the master holds a fairly big repository of small files. The repo's current size is ~40GB with ~1.2 M files in ~100 directories. Now, we like to rsync changes from the master to the client nodes, which is working perfectly for 2 nodes, but our 3rd node oopses "sometimes", rendering

The system stopped responding to ssh but still responded to ping. The logs showed this error: (its long) Feb 4 00:08:08 server1 kernel: gdmgreeter: page allocation failure. order:0, mode:0x50 Feb 4 00:08:08 server1 kernel: [<c014f863>] __alloc_pages+0x28b/0x29d Feb 4 00:08:08 server1 kernel: [<c014b70f>] find_or_create_page+0x39/0x72 Feb 4 00:08:08 server1 kernel:

Hi, I got the OOPS below on my laptop running vanilla 2.4.20-ac2; I had to copy it byhand so it may not be 100% accurate. It hasn't happened again, and this is the first problem I've had with this kernel (or any other kernel, for that matter.) Anyway, I'm not sure, if a) this is actually an ext3 problem, b) OOPS reports of 2.4.20-ac2 are of any interest, so I won't bother with

Today our server had seriuos problems, we had to reinitiate it and run fsck manually. Dou you think it's an ext3, kernel (vanilla 2.4.19) or hardware bug? The errors were (from syslog): -------------------------------- Oct 6 16:10:25 nou kernel: attempt to access beyond end of device Oct 6 16:10:25 nou kernel: 72:02: rw=0, want=230266240, limit=4882432 Oct 6 16:10:25 nou kernel: attempt

Hi, We have encountered another funny with ext3 on 2.4. Like the kernel NFS server, we have a routine in InterMezzo that does something like looking up an inode by inode number. (compare intermezzo's presto_ilookup or knfsd's nfsfh_iget) Effectively both of these routines do ilookup() { inode = iget(sb, ino) if (inode->i_nlink==0) iput(inode); .... } We find that

I guess this could be filed under the 'shot myself in the foot' section, but I figured I'd report it anyways.. Kernel 2.5.50-bk6, x86, preempt, PIIX IDE, ext3 fs. I dd'ed the first part of a ext3 partition to tmp, then mounted it via loopback. (the image passed a fsck, except for warning about corrupt part. table or superblock) I tried to 'cd' into a directory within

I recently rebooted one of my machines and was greeted with a message about one of my ext3 partitions having some errors. I dutifully started e2fsck on the partition, but after a few hours of some useful messages about fixing inodes, it then started printing out lists of ascending numbers which I'm not sure how to interpret. The first time I noticed this, these numbers were in the 4000000

One of our servers (false) just oopsed. In the middle of lunch. Any advise? On console: false kernel: Assertion failure in journal_start() at transaction.c line 245: "handle->h_transaction->t_journal == journal" In kernel log (ran it through ksymoops): Nov 13 12:35:37 false kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Nov 13 12:35:37

On a 2.4.17 (MontaVista 2.1) kernel using ext3, I recently starting seeing the error EXT3-fs error (device ide1(22,1)) in start_transaction: Readonly filesystem EXT3-fs error (device ide1(22,1)) in ext3_delete_inode: Readonly filesystem on a file system within 10-20 seconds after remounting it r/o. Apparemtly a write is being deferred past the remount point and then runs into problems when it is

Hi, I'm running redhat 9 (kernel 2.4.20-8) as a heavy file server using ext3 file system. The server hang once a week and I found the following my log in /var/log/messages It looks like some ext3 quota problem. Anyone has similar experience ? Any suggestion ? Unable to handle kernel paging request at virtual address ffffffff printing eip: ffffffff *pde = 00001067 *pte = 00000000

Simon May <simon@imsl.es> wrote: > We use kernel 2.4.18 with a slackware linux dist. > e2fsprogs version 1.29 > > you will see that sendmail was the application that lead to the error > at the time the machine was doing a weekly new letter to clients > which puts it under abit of load but not a lot really > the machine has a 1 Gb processor and 768 Mb RAM so is

Jun 29 11:30:05 ns kernel: Assertion failure in __journal_file_buffer() at transaction.c:1935: "jh->b_jlist < 9" Jun 29 11:30:05 ns kernel: invalid operand: 0000 Jun 29 11:30:05 ns kernel: CPU: 0 Jun 29 11:30:05 ns kernel: EIP: 0010:[__journal_file_buffer+54/400] Not tainted Jun 29 11:30:05 ns kernel: EFLAGS: 00010282 Jun 29 11:30:05 ns kernel: eax: 00000059 ebx:

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

Fix "h_buffer_credits<0" assert failure during truncate. The bug occurs when the "i_blocks" count in the file's inode overflows past 2^31. That works fine most of the time, because i_blocks is an unsigned long, and should go up to 2^32; but there's a place in truncate where ext3 calculates the size of the next transaction chunk for the delete, and that mistakenly

Am using RedHat 7.3 with software raid. it was crashing from time to time so i desided to investigate. after running some stress tests on it it died with a kernel message (see below). it might not be ext3 related but since I was running redhat with ext2 for some time without problems (not on the same machine) I thought it might have somthing to do with the fs. Any ideas. I'll try converting

Hi, Running MySQL Cluster datanode (a process of large memory which checkpoints data to disk periodically) on a 2xXeon Dell PowerEdge SC1425 (2.6.9-5.ELsmp#1 SMP x86_64), and recieved this notice in /var/log/messages. The datanode process crashed, and using the partition after this seemed to hang processes, eg ls /data/ would hang. Reboot fixed this, boot.log states that the partition was clean,

Hi, Doing the following I can generate an assertion in ext3 0.0.7a. I have an ext3 filesystem on /foo. I export /foo via nfs. I then mount via localhost:/foo onto /mnt. Start up a dd to generate a file on the nfs mount. (cd /mnt; dd if=/dev/zero of=./dd.out bs=1024k), then on the localhost filesystem /foo I rm the file. rm -f /foo/dd.out. This results in "ext3_free_inode: bit already

This caused a crash on a 2.6.10-1.12_FC2smp kernel May 19 09:56:35 spf1 kernel: Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:361: "drop_count != 0 || cleanup_ret != 0" May 19 09:56:35 spf1 kernel: ------------[ cut here ]------------ May 19 09:56:37 spf1 kernel: kernel BUG at fs/jbd/checkpoint.c:361! May 19 09:56:37 spf1 kernel: invalid operand: 0000 [#1] May 19

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