From leandro at dutra.fastmail.fm Thu Apr 1 00:06:36 2004 From: leandro at dutra.fastmail.fm (=?iso-8859-1?q?Leandro_Guimar=E3es_Faria_Corsetti_Dutra?=) Date: Wed, 31 Mar 2004 21:06:36 -0300 Subject: PROBLEM: log abort over RAID5 References: <1078873638.2460.81.camel@sisko.scot.redhat.com> <1080731519.1991.3.camel@sisko.scot.redhat.com> Message-ID: Em Wed, 31 Mar 2004 12:12:01 +0100, Stephen C. Tweedie escreveu: > A _full_ checklist would include every piece of hardware in your machine, > and every module you've got compiled or loaded into the kernel, plus a ton > of privileged applications such as X. So you mean it is basically impossible, and I have to wait until more people get ext3-on-RAID5 journal aborts, including a few hackers? OK, so I've just gone back to 2.4 and will stay there for the foreseeable future. > I've been seeing some reports on raid5, yes. Current kernels look OK in > the main for most people, though there are still the occasional problems > being discovered: such is 2.6. Nothing springs to mind that particularly > matches your own symptoms, though. http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1517.html http://www.ussg.iu.edu/hypermail/linux/kernel/0401.2/0450.html http://marc.theaimsgroup.com/?l=linux-raid&m=107351745306237&w=2 This was just from the linux-kernel and linux-raid archives. When I did Google around, I found some other similar ones... -- Leandro Guimar?es Faria Corsetti Dutra Maring?, PR, BRASIL http://br.geocities.com./lgcdutra/ Soli Deo Gloria! From eagle112113 at yahoo.com Thu Apr 1 09:40:49 2004 From: eagle112113 at yahoo.com (Scorpion Yang) Date: Thu, 1 Apr 2004 01:40:49 -0800 (PST) Subject: ext3_free_data() Message-ID: <20040401094049.37281.qmail@web60907.mail.yahoo.com> Hi, why is there a window between statements "err = ext3_journal_get_write_access(handle, this_bh);" and "ext3_journal_dirty_metadata(handle, this_bh);" ? In my test, there is an error in journal_dirty_metadata: jh is null thanks! D.Yang April 1, 2004 ---------------------------------------------------------------------------------------------------------------------------------- /** * ext3_free_data - free a list of data blocks * @handle: handle for this transaction * @inode: inode we are dealing with * @this_bh: indirect buffer_head which contains *@first and *@last * @first: array of block numbers * @last: points immediately past the end of array * * We are freeing all blocks refered from that array (numbers are stored as * little-endian 32-bit) and updating @inode->i_blocks appropriately. * * We accumulate contiguous runs of blocks to free. Conveniently, if these * blocks are contiguous then releasing them at one time will only affect one * or two bitmap blocks (+ group descriptor(s) and superblock) and we won't * actually use a lot of journal space. * * @this_bh will be %NULL if @first and @last point into the inode's direct * block pointers. */ static void ext3_free_data(handle_t *handle, struct inode *inode, struct buffer_head *this_bh, u32 *first, u32 *last) { unsigned long block_to_free = 0; /* Starting block # of a run */ unsigned long count = 0; /* Number of blocks in the run */ u32 *block_to_free_p = NULL; /* Pointer into inode/ind corresponding to block_to_free */ unsigned long nr; /* Current block # */ u32 *p; /* Pointer into inode/ind for current block */ int err; if (this_bh) { /* For indirect block */ BUFFER_TRACE(this_bh, "get_write_access"); err = ext3_journal_get_write_access(handle, this_bh); /* Important: if we can't update the indirect pointers * to the blocks, we can't free them. */ if (err) return; } for (p = first; p < last; p++) { conditional_schedule(); nr = le32_to_cpu(*p); if (nr) { /* accumulate blocks to free if they're contiguous */ if (count == 0) { block_to_free = nr; block_to_free_p = p; count = 1; } else if (nr == block_to_free + count) { count++; } else { ext3_clear_blocks(handle, inode, this_bh, block_to_free, count, block_to_free_p, p); block_to_free = nr; block_to_free_p = p; count = 1; } } } if (count > 0) ext3_clear_blocks(handle, inode, this_bh, block_to_free, count, block_to_free_p, p); if (this_bh) { BUFFER_TRACE(this_bh, "call ext3_journal_dirty_metadata"); ext3_journal_dirty_metadata(handle, this_bh); } } --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today -------------- next part -------------- An HTML attachment was scrubbed... URL: From guolin at alexa.com Fri Apr 2 06:36:41 2004 From: guolin at alexa.com (Guolin Cheng) Date: Thu, 1 Apr 2004 22:36:41 -0800 Subject: Strange Fedora Booting problem: can not mount "LABEL=*" partitions Message-ID: <41089CB27BD8D24E8385C8003EDAF7AB084841@karl.alexa.com> Hi, Just got Fedora FC1 vanilla 2.4.25kernel+libata8patch booting problems, FC1 complains that it can not automatically find&found partitions specified with "LABEL=" in /etc/fstab, and then falls me into repair mode. In the repair mode I can mount it manually without any problems. More interesting are: 1) I have several partitions specified with "LABEL=*" in /etc/fstab, but FC1 always can not identify same partition even on different machines; 2) the default&upgraded ntpl kernel boots up without problems. My fstab is attached below: LABEL=/ / ext3 defaults 1 1 LABEL=/0 /0 ext3 defaults 1 2 /dev/hdc1 /1 ext3 defaults 1 2 LABEL=/alexa /alexa ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 /dev/hda7 swap swap defaults 0 0 /dev/hda6 swap swap defaults 0 0 /dev/hda8 swap swap defaults 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 ops-test1.alexa.com guolin 134% FC1 stops on partitions "LABEL=/var" on two machines, stops on partition "LABEL=/" on the 3rd machine. While the default|upgraded NTPL kernel (with SMP problem) boots without a glitch, my vanilla 2.4.25 kernel plus libata patch 2.4.25-libata8 fails with the above symptoms described. The solution to fix it is: manually run "e2fsck -y -f /dev/hd?, tune2fs -j /dev/hd?; e2label /dev/hd?