search for: start_transact

...: 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 EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in ext3_create: IO failure EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in start_transaction: Journal ha...

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 performed because the file system is...

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, 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

My recently installed CentOS 4.3 system (which is the kickstart server for other systems -- see other thread) is currently hung. I can ping it, but can't do much of anything else. When I switch to one of the virtual consoles, I can briefly see the "login:" prompt, but then that window immediately fills with up with the following message: EXT3-fs error (devive dm-0) in

...ocks - offset=0, in ode=1601332598, rec_len=24932, name_len=116 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 EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)): ext3_readdir: bad entry in directory #191618: directory entry across blocks - offset=0, inode=1601332598, rec_len=24932, name_len=116 EXT3-fs error (device ide0(3,2))...

...eaddir: 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 Remounting filesystem read-only EXT3-fs error (device hda3) in start_transaction: Journal has aborted EXT3-fs error (device hda3) in start_transaction: Journal has aborted [...] I hit a similar problem yesterday, but lost some details so I couldn't make a proper bug report. However, it did mean that the partition got fully fscked, so I think these errors are ext3 gettin...

...al on device sdg1. Nov 9 01:13:13 kasse kernel: ext3_abort called. Nov 9 01:13:13 kasse kernel: EXT3-fs error (device sdg1): ext3_journal_start_sb: Detected aborted journal Nov 9 01:13:13 kasse kernel: Remounting filesystem read-only Nov 9 01:13:41 kasse kernel: EXT3-fs error (device sdg1) in start_transaction: Journal has aborted Nov 9 01:13:41 kasse kernel: EXT3-fs error (device sdg1) in start_transaction: Journal has aborted Nov 9 01:15:05 kasse kernel: usb 1-1.1: reset high speed USB device using address 13 Nov 9 01:15:10 kasse kernel: usb 1-1.1: control timeout on ep0out Nov 9 01:15:15 kass...

...ootDomainNamingContext attr: configurationNamingContext attr: schemaNamingContext attr: defaultNamingContext control: <NONE> ldb: ldb_trace_request: (tdb)->search ldb_wrap open of /var/lib/samba/private/hklm.ldb ldb: start ldb transaction (nesting: 0) ldb: ldb_trace_request: (tdb)->start_transaction ldb: start ldb transaction error: (null) ldb: ldb_trace_request: ADD dn: @ATTRIBUTES changetype: add key: CASE_INSENSITIVE value: CASE_INSENSITIVE control: <NONE> ldb: ldb_trace_request: (tdb)->add ldb: ldb_trace_request: (tdb)->prepare_commit ldb: commit ldb transaction (nesting...

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. Any ideas on what we can do to help isolate this problem? We have 64 n...

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.

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. This is stock CentOS 4.4, never have gotten...

...ct 6 16:10:25 nou kernel: Aborting journal on device ataraid(114,2). Oct 6 16:10:25 nou kernel: Remounting filesystem read-only Oct 6 16:10:25 nou kernel: EXT3-fs error (device ataraid(114,2)) in ext3_delete_inode: IO failure Oct 6 16:10:25 nou kernel: EXT3-fs error (device ataraid(114,2)) in start_transaction: Journal has aborted Oct 6 16:10:25 nou kernel: EXT3-fs error (device ataraid(114,2)) in ext3_delete_inode: Journal has aborted Oct 6 16:10:25 nou kernel: EXT3-fs error (device ataraid(114,2)) in start_transaction: Journal has aborted Oct 6 16:10:25 nou kernel: EXT3-fs error (device ataraid...

...o singleton can''t be dumped RAILS_ROOT: script/../config/.. Application Trace | Framework Trace | Full Trace /var/lib/gems/1.8/gems/transaction-simple-1.4.0/lib/transaction/simple.rb:129:in `dump'' /var/lib/gems/1.8/gems/transaction-simple-1.4.0/lib/transaction/simple.rb:129:in `start_transaction'' /var/lib/gems/1.8/gems/transaction-simple-1.4.0/lib/transaction/simple/group.rb:102:in `start_transaction'' /var/lib/gems/1.8/gems/transaction-simple-1.4.0/lib/transaction/simple/group.rb:102:in `each'' /var/lib/gems/1.8/gems/transaction-simple-1.4.0/lib/transaction/sim...

..., reporting Input/Output error. The file-system itself was in read-only mode. Soon no file under / was accessible. fdisk /dev/cciss/c0d0 (the disk containing /) reported that the device is not valid. The console was full of this message repeating: "EXT3-fs error (device /dev/cciss/c0d0) in start_transaction: Journal has aborted" I booted the machine. fsck did not report anything, and the computer seemed to work fine. After a day the problem repeated. I booted again. The BIOS reported an error: "POST Error: 1727-Drive Array - New Logical Drive(s) Attachment Detected" The boot...

...ex = true + else + logger.debug "deferred ferret_create/update: #{self.class.name} : #{self.id}" + end true end alias :ferret_update :ferret_create @@ -522,6 +527,21 @@ end true end + + def at_start_transaction(name = nil) + @defer_for_transaction = true + end + + def at_abort_transaction(name = nil) + @defer_for_transaction = false + @ferret_reindex = false + end + + def at_commit_transaction(name = nil) + @defer_for_transaction = false +...

...bad entry in directory #14370410: rec_len % 4 != 0 - offset=0, inode=1309281588, rec_len=16761, name_len=78 Aborting journal on device dm-4. ext3_abort called. EXT3-fs error (device dm-4): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only EXT3-fs error (device dm-4) in start_transaction: Journal has aborted EXT3-fs error (device dm-4) in ext3_create: IO failure __journal_remove_journal_head: freeing b_committed_data __journal_remove_journal_head: freeing b_committed_data

The WARN_ON() in start_transaction() was triggered while balancing. The cause is btrfs_relocate_chunk() started a transaction and then called iput() on the inode that stores free space cache, and iput() called btrfs_start_transaction() again. Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by: Li Zefan <li...

...682082] [<ffffffffa00ee967>] record_root_in_trans.part.30+0x97/0x100 [btrfs] [376007.682090] [<ffffffffa00ee9f4>] record_root_in_trans+0x24/0x30 [btrfs] [376007.682098] [<ffffffffa00efeb1>] btrfs_record_root_in_trans+0x51/0x80 [btrfs] [376007.682106] [<ffffffffa00f13d6>] start_transaction.part.35+0x86/0x560 [btrfs] [376007.682109] [<ffffffff8132c197>] ? apparmor_capable+0x27/0x80 [376007.682117] [<ffffffffa00f18d9>] start_transaction+0x29/0x30 [btrfs] [376007.682125] [<ffffffffa00f19a7>] btrfs_join_transaction+0x17/0x20 [btrfs] [376007.682133] [<ffffffffa...