similar to: EXT3-fs error (devive dm-0) in start_transaction: Journal has aborted

Hi, Alfred von Campe wrote on Wed, 2 Aug 2006 09:34:06 -0400 > It's time to resurrect this thread from way back in June. I suspect this is more of a HW problem rathan a SW one. About two years ago I had a similar EXT3 fs failure case to develop on a server running Mandrake Linux. My case was due to the fact that this desktop Linux computer had two HDs, where one of them (a Quamtum, top

Errors happy in the early hours of the Morning 4 or 5 AM. every time , many directories and files can't be accessed , message "I/O error " display, all partitions become read-only no data lost and no data can be wirted ,only redress is a reboot. Distribution: REDHAT version 4 X86_64 update 5 Server Platform : IBM X 366 RAID Controller : IBM ServerRAID 8i Disks : 4*73G SAS

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

Hello folks, I have the following problem: tincd is complaining about a missing name or so but i cannot find any mistake in the configuration. It is similar to all my other tinc nodes. here are the details: # ls -l /etc/tinc/ffnw/ drwxr-xr-x 3 root root 4096 Aug 1 10:43 hosts -rw------- 1 root root 1680 Jul 31 21:54 rsa_key.priv -rw------- 1 root root

This is very strange. Everything was running fine Friday night. This morning I walk into work and find that my root file system (which is actually the only filesystem besides /boot) is not writable. Yet mount thinks it's mounted read/write: # mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) [snip] # touch foo touch: cannot touch `foo': Read-only file

All, We are encountering spurious errors with ext3. After some period of heavy IO we may see messages similiar to: EXT3-fs error (device cciss/c0d0p5) in start_transaction: Journal has aborted When this happens the filesystem is remounted read-only. If it's the root filesystem the system becomes unresponsive and must be rebooted. An fsck on the affected filesystem shows lots of corruption.

This is an issue that I have been having with one of our production servers for a couple of months, just out of no where /var goes to read only. There aren't any errors that show up in /var/log/messages nor dmesg, I checked to make sure that the drives on error option is set to continue and there isn't anything as far as I can tell wrong with the disks. Also there is plenty of disk space.

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

On 1/26/2018 12:14 AM, Siwei Liu wrote: > On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin <mst at redhat.com> wrote: >> On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote: >>> On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin <mst at redhat.com> wrote: >>>> On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote: >>>>> First

The freeze rwsem is taken by sb_start_intwrite() and dropped during the commit_ or end_transaction(). In the async case, that happens in a worker thread. Tell lockdep the calling thread is releasing ownership of the rwsem and the async thread is picking it up. Josef and I worked out a more complicated solution that made the async commit thread join and potentially get a later transaction, but

Hi! Today I switched over to devfs. I'm on Debian unstable, installed devfsd, installed a kernel with devfs support and "devfs mount on boot". Reboot, devfs is being used. All over a sudden, dmesg reports: Linux version 2.4.21-ac1 (root@hummus) (gcc version 3.3 (Debian)) #1 Sun Jun 15 19:06:13 CEST 2003 ... kjournald starting. Commit interval 5 seconds EXT3-fs: mounted

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,

Hi, I was hoping I could modify a locally mounted registry hive using regpatch and a .reg file but the -F argument seems to have no function. (Strace shows it ignores it and just operates on /var/lib/samba/private/hklm.ldb) Below is output with debug on. rfm6 at ubuntuSSDx64:cp /mnt/xp/WINDOWS/system32/config/software /tmp/software rfm6 at ubuntuSSDx64:/tmp/config$ sudo regpatch -d=10 -F

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

On Fri, Jan 26, 2018 at 8:51 AM, Samudrala, Sridhar <sridhar.samudrala at intel.com> wrote: > > > On 1/26/2018 12:14 AM, Siwei Liu wrote: >> >> On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin <mst at redhat.com> >> wrote: >>> >>> On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote: >>>> >>>> On Mon, Jan 22,

Out of the blue, dmesg on my HP Proliant w/ a SCSI disk gives loads of messages like this one: EXT3-fs error (device dm-0) in start_transaction: Journal has aborted Then the root fs goes read-only, so little else can be done on the machine. LVM locks up. At restart, fs needs a reboot to recover after fsck. The host starts up ok, then I am given some more minutes before the problem reappears.

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

On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote: >> On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote: >> >> First off, as mentioned in another thread, the model of stacking

Hello, My first PDF report from rails. When i try to render "tab.render_on(pdf)", I get that error message. Thanks any help, Helder ================================================================= TypeError in ContasController#plano singleton can''t be dumped RAILS_ROOT: script/../config/.. Application Trace | Framework Trace | Full Trace