From cytron at bol.com.br Thu Jul 1 19:18:24 2004 From: cytron at bol.com.br (cytron) Date: Thu, 1 Jul 2004 16:18:24 -0300 Subject: I run mkfs.ext3 in hda1 but I want to make undo. How do it? Message-ID: Hello linuxers!!! I have a problem. I did format using mkfs.ext3 in /dev/hda1, and it's wrong. I want to format hda2. Now I lost all datas. How can I recover my hda1??? __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - ? gr?tis! http://antipopup.uol.com.br/ From davids at webmaster.com Thu Jul 1 21:16:43 2004 From: davids at webmaster.com (David Schwartz) Date: Thu, 1 Jul 2004 14:16:43 -0700 Subject: I run mkfs.ext3 in hda1 but I want to make undo. How do it? In-Reply-To: Message-ID: > Hello linuxers!!! > > I have a problem. I did format using mkfs.ext3 > in /dev/hda1, and it's wrong. I want to format hda2. > > Now I lost all datas. How can I recover my hda1??? Restore from your most recent backup. DS From cytron at bol.com.br Thu Jul 1 17:13:51 2004 From: cytron at bol.com.br (cytron) Date: Thu, 1 Jul 2004 14:13:51 -0300 Subject: I run mkfs.ext3 in a partition and I want make undo, how do it? Message-ID: I use mkfs.ext3 in /dev/hda1, but was to use in /dev/hda3. Exist recover for this? How to do? __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - ? gr?tis! http://antipopup.uol.com.br/ From raines at nmr.mgh.harvard.edu Fri Jul 2 21:23:42 2004 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Fri, 2 Jul 2004 17:23:42 -0400 (EDT) Subject: file size and actually blocks do not match Message-ID: I have a disk where serveral files have a file size that is much bigger then the space they actually use. THe file size is bogus. In the example below, the size is reported as 4.2MB but the file is really supposed to be on 116K which is true accoring to du and the block list from debugfs. However, doing a 'cat |wc' file actually gives me 4.2MB bytes. Where are those extra bytes coming from since the inode certainly does not have the blocks! Doing a fcsk does not fix the situation as shown below. This is on a RH7.3 machine running a 2.4.20 kernel root at 1[bh-sm5-per-006]# debugfs /dev/hda4 debugfs 1.35-WIP (31-Jan-2004) debugfs: stat users/greve/fbirn-hp-fsfast/dunc-data/dunc-101.1/bold/bh-sm5-per-006/beta_008.bfloat Inode: 5980769 Type: regular Mode: 0777 Flags: 0x0 Generation: 4199683 297 User: 5652 Group: 5652 Size: 4243456 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 232 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x406066ae -- Tue Mar 23 11:32:46 2004 atime: 0x40e5b58c -- Fri Jul 2 15:20:44 2004 mtime: 0x406066ae -- Tue Mar 23 11:32:46 2004 BLOCKS: (0):19431070, (1-2):19431076-19431077, (3):19431079, (4):19431130, (5):19431136, (6-11):24618332-24618337, (IND):24618338, (12-27):24618339-24618354 TOTAL: 29 debugfs: quit root at 1[/]# umount /mnt/greve/old/4 root at 1[/]# e2fsck -y /dev/hda4 e2fsck 1.35-WIP (31-Jan-2004) /dev/hda4: clean, 1467459/18448384 files, 33585486/36871183 blocks (check after next mount) root at 1[/]# e2fsck -y -f /dev/hda4 e2fsck 1.35-WIP (31-Jan-2004) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda4: 1467459/18448384 files (6.4% non-contiguous), 33585486/36871183 blocks root at 1[/]# mount /dev/hda4 /mnt/greve/old/4 root at 1[/]# debugfs /dev/hda4 debugfs 1.35-WIP (31-Jan-2004) debugfs: stat users/greve/fbirn-hp-fsfast/dunc-data/dunc-101.1/bold/bh-sm5-per-006/beta_008.bfloat Inode: 5980769 Type: regular Mode: 0777 Flags: 0x0 Generation: 4199683 297 User: 5652 Group: 5652 Size: 4243456 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 232 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x406066ae -- Tue Mar 23 11:32:46 2004 atime: 0x40e5b58c -- Fri Jul 2 15:20:44 2004 mtime: 0x406066ae -- Tue Mar 23 11:32:46 2004 BLOCKS: (0):19431070, (1-2):19431076-19431077, (3):19431079, (4):19431130, (5):19431136, (6-11):24618332-24618337, (IND):24618338, (12-27):24618339-24618354 TOTAL: 29 debugfs: -- --------------------------------------------------------------- Paul Raines email: raines at nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA From raines at nmr.mgh.harvard.edu Fri Jul 2 23:45:20 2004 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Fri, 2 Jul 2004 19:45:20 -0400 (EDT) Subject: file size and actually blocks do not match In-Reply-To: <40E5EAD9.7040707@kadzban.is-a-geek.net> Message-ID: The files are not (at least supposed to be) sparse files. They are a format called bfloat. There are about 1000 of them in that directory and suddenly 8 seem corrupt with the too big size. -- --------------------------------------------------------------- Paul Raines email: raines at nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA From alex at alex.org.uk Sat Jul 3 11:43:49 2004 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 03 Jul 2004 12:43:49 +0100 Subject: 2.4.24 I/O error breakage Message-ID: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> Twice in the past week (when things have previously been fine for a year), a server has locked up spewing forth a continuous stream of ext3 write errors. This is to a bog-standard IDE disk, only thing on the controller, etc. Nothing EVER hits the logs. Not a single error. Every process that accesses the disk seems to fail. It looks like ext3 is failing every I/O request. If the machine is rebooted, it comes up completely clean. I am prepared to believe I have a bad disk that occasionally pops up the odd IDE error, but given it takes pretty intensive activity (busy mail server) without failing, I don't believe it is riddled with errors. I speculate that either a) After one I/O error, ext3 or the IDE layer is returning I/O errors for every request (something is not resetting some error condition), or b) Something is hanging the IDE bus, which only a reboot cures. Is (a) a known possibility? If not, is (b) possible? I am upgrading to 2.4.26-rc2, to see if that fixes things. What further information should I look for (or post here) to help me (or you) debug this further? Alex From daniel at rimspace.net Sat Jul 3 13:02:21 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Sat, 03 Jul 2004 23:02:21 +1000 Subject: 2.4.24 I/O error breakage References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> Message-ID: <87brixb5wi.fsf@enki.rimspace.net> On 3 Jul 2004, Alex Bligh wrote: > Twice in the past week (when things have previously been fine for a > year), a server has locked up spewing forth a continuous stream of > ext3 write errors. This is to a bog-standard IDE disk, only thing > on the controller, etc. I have had this sort of behavior on a system for some time, which resolved itself as a faulty IDE cable in the end. > Nothing EVER hits the logs. Not a single error. Every process that > accesses the disk seems to fail. It looks like ext3 is failing every > I/O request. When the system generated (sufficient) corruption, it would trigger the default action of remounting the filesystem read-only, which cause a good deal of follow on failure; perhaps this is the case here? Regards, Daniel -- Fetters of gold are still fetters, and the softest lining can never make them so easy as liberty. -- Mary Astell, _An Essay in Defence of the Female Sex_, 1696 From fabian.frederick at skynet.be Sat Jul 3 13:12:41 2004 From: fabian.frederick at skynet.be (FabF) Date: Sat, 03 Jul 2004 15:12:41 +0200 Subject: 2.4.24 I/O error breakage In-Reply-To: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> Message-ID: <1088860360.2431.6.camel@localhost.localdomain> On Sat, 2004-07-03 at 13:43, Alex Bligh wrote: > Twice in the past week (when things have previously been fine for a > year), a server has locked up spewing forth a continuous stream of > ext3 write errors. This is to a bog-standard IDE disk, only thing > on the controller, etc. > > Nothing EVER hits the logs. Not a single error. Every process that > accesses the disk seems to fail. It looks like ext3 is failing every > I/O request. > > If the machine is rebooted, it comes up completely clean. > > I am prepared to believe I have a bad disk that occasionally pops up > the odd IDE error, but given it takes pretty intensive activity (busy > mail server) without failing, I don't believe it is riddled with errors. > > I speculate that either > a) After one I/O error, ext3 or the IDE layer is returning I/O errors > for every request (something is not resetting some error condition), > or > b) Something is hanging the IDE bus, which only a reboot cures. > > Is (a) a known possibility? If not, is (b) possible? > > I am upgrading to 2.4.26-rc2, to see if that fixes things. What further > information should I look for (or post here) to help me (or you) debug this > further? > > Alex dumpe2fs -h could help ... maybe. From bryan at kadzban.is-a-geek.net Fri Jul 2 23:08:09 2004 From: bryan at kadzban.is-a-geek.net (Bryan Kadzban) Date: Fri, 02 Jul 2004 19:08:09 -0400 Subject: file size and actually blocks do not match In-Reply-To: References: Message-ID: <40E5EAD9.7040707@kadzban.is-a-geek.net> Paul Raines wrote: > I have a disk where serveral files have a file size that is much bigger > then the space they actually use. THe file size is bogus. In the example > below, the size is reported as 4.2MB but the file is really supposed to be > on 116K which is true accoring to du and the block list from debugfs. Sparse file? $ dd if=/dev/zero of=testfile seek=1M count=1 bs=1024 1+0 records in 1+0 records out $ ls -l testfile -rw-r--r-- 1 1073742848 Jul 2 19:04 testfile $ du -h testfile 12K testfile $ wc testfile 0 0 1073742848 testfile $ This file contains 1 gig of empty space, then 1K of zeros. The gig of empty space reads as zeros to most programs (including wc), but the zeros aren't actually stored on disk, because they've never been written to. That's why it's sparse. From sct at redhat.com Tue Jul 6 14:38:36 2004 From: sct at redhat.com (Stephen C. Tweedie) Date: 06 Jul 2004 15:38:36 +0100 Subject: 2.4.24 I/O error breakage In-Reply-To: <87brixb5wi.fsf@enki.rimspace.net> References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> <87brixb5wi.fsf@enki.rimspace.net> Message-ID: <1089124716.1959.108.camel@sisko.scot.redhat.com> Hi, On Sat, 2004-07-03 at 14:02, Daniel Pittman wrote: > > Nothing EVER hits the logs. Not a single error. Every process that > > accesses the disk seems to fail. It looks like ext3 is failing every > > I/O request. > > When the system generated (sufficient) corruption, it would trigger the > default action of remounting the filesystem read-only, which cause a > good deal of follow on failure; perhaps this is the case here? Right. That has been the standard behaviour of ext2 and ext3 on certain critical corruptions for a long time. On ext3, it is usually accompanied by log messages about the journal aborting; all future writes get the EROFS fs-is-readonly error. Of course, if this hits the partition with /var on it, your logs stop being recorded too. Serial or network console is invaluable in debugging such cases. (I use ttywatch to monitor serial console on all my test boxes.) --Stephen From nhammler at scc.co.at Tue Jul 6 15:02:12 2004 From: nhammler at scc.co.at (Niki Hammler) Date: Tue, 6 Jul 2004 17:02:12 +0200 Subject: Overwriting ext2 Partition with ext3 Message-ID: <00b401c4636a$38be5f20$83c8a8c0@nikinotebook> Hi, Suppose you have an ext2 Partition at 14GB which is 80-90% full. Most files are smaller than 1 MB (there are just 20 or so which are over 100MB where 800MB is the biggest one). Block size etc - everything is default. Now you do this: mke2fs -j /device Important is the "-j" switch. What happens without the "-j" switch? All superblocks and inodes are overwritten. Is this true?? If so, the data isn't lost but the meta info. Is there a chance to restore some of the data? Suppose, the block size is 4KB. Then I could easily restore every file which is less or equal 4K. Is this true? If a file is bigger is there a chance of restoring some data? Now suppose doing it with the "-j" switch. This adds a journal. Where is this journal written and how big is it? If the journal is written and the beginning of the drive, there is a chance, that not all of the meta data isn't destroyed. Is this true? Is there a chance to recover some of the data? Is there a tool for examining ext2 partitions WITHOUT meta info? So that it could be possible to recover some of the data? Yes, this happend to me. I typed mke2fs instead of tune2fs. I know, I should have a backup. Damn! However, can you tell me if it is theoretically possible to recover data maybe even with meta info (file name)? Then I would give my harddrive to a professional recover company. AND, maybe important: I have a textfile containing all files (and dirs) on the harddrive with full path and size in kilobytes. I've done this few days ago with find. But the files are not in right order, they are ordered by size. Can anybody help me?? Thanks a lot! Niki From alex at alex.org.uk Tue Jul 6 15:10:38 2004 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 06 Jul 2004 16:10:38 +0100 Subject: 2.4.24 I/O error breakage In-Reply-To: <1089124716.1959.108.camel@sisko.scot.redhat.com> References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> <87brixb5wi.fsf@enki.rimspace.net> <1089124716.1959.108.camel@sisko.scot.redhat.com> Message-ID: <717A478F38F2C5091B3206A3@[192.168.0.5]> --On 06 July 2004 15:38 +0100 "Stephen C. Tweedie" wrote: > Right. That has been the standard behaviour of ext2 and ext3 on certain > critical corruptions for a long time. On ext3, it is usually > accompanied by log messages about the journal aborting; all future > writes get the EROFS fs-is-readonly error. > > Of course, if this hits the partition with /var on it, your logs stop > being recorded too. Can this happen due to a /single/ corruption? I would have thought I would see the controller/drive being reset and a retry or two before this happened. Time for serial console anyway I guess. Alex From sct at redhat.com Tue Jul 6 16:24:36 2004 From: sct at redhat.com (Stephen C. Tweedie) Date: 06 Jul 2004 17:24:36 +0100 Subject: 2.4.24 I/O error breakage In-Reply-To: <717A478F38F2C5091B3206A3@[192.168.0.5]> References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> <87brixb5wi.fsf@enki.rimspace.net> <1089124716.1959.108.camel@sisko.scot.redhat.com> <717A478F38F2C5091B3206A3@[192.168.0.5]> Message-ID: <1089131076.1959.125.camel@sisko.scot.redhat.com> Hi, On Tue, 2004-07-06 at 16:10, Alex Bligh wrote: > > Of course, if this hits the partition with /var on it, your logs stop > > being recorded too. > > Can this happen due to a /single/ corruption? I would have thought I > would see the controller/drive being reset and a retry or two before > this happened. "corruption" and "drive retry" indicate two completely different things. Corruption can happen silently whenever anything on the _long_ path between platter and memory doesn't get copied right --- it can be software, or bad CPU, memory, cache, controller, cable, disk etc. If the drive is unable to read a sector, then yes, you'd expect e retry. But any other sort of corruption isn't detectable at the time so there's no retry involved. Corruption that hits the journal itself can cause an instant journal abort. One or two other cases can, too. Most cases where the drive is simply unable to read a block will _not_ cause an abort (EIO hitting the journal itself is an exception, though.) --Stephen From daniel at rimspace.net Wed Jul 7 06:01:38 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Wed, 07 Jul 2004 16:01:38 +1000 Subject: 2.4.24 I/O error breakage References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> <87brixb5wi.fsf@enki.rimspace.net> <1089124716.1959.108.camel@sisko.scot.redhat.com> <717A478F38F2C5091B3206A3@[192.168.0.5]> Message-ID: <87oemsgxtp.fsf@enki.rimspace.net> On 7 Jul 2004, Alex Bligh wrote: > --On 06 July 2004 15:38 +0100 "Stephen C. Tweedie" wrote: > >> Right. That has been the standard behaviour of ext2 and ext3 on certain >> critical corruptions for a long time. On ext3, it is usually >> accompanied by log messages about the journal aborting; all future >> writes get the EROFS fs-is-readonly error. >> >> Of course, if this hits the partition with /var on it, your logs stop >> being recorded too. > > Can this happen due to a /single/ corruption? I would have thought I > would see the controller/drive being reset and a retry or two before > this happened. As Stephen correctly points out, "corruption" means "broken filesystem data" in the case I was talking about, and it can happen anywhere. You may want to investigate 'netconsole', if you have it in a suitable kernel, which I found very helpful -- it let me trap the oops without needing to find a suitable serial cable. So long as your network card is still working, anyway. :) Daniel -- Fortune rarely accompanies anyone to the door. -- Balthasar Gracian From alex at alex.org.uk Wed Jul 7 08:31:02 2004 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 07 Jul 2004 09:31:02 +0100 Subject: 2.4.24 I/O error breakage In-Reply-To: <87oemsgxtp.fsf@enki.rimspace.net> References: <30B0B5CA0F833BF27BDD2D52@[192.168.0.5]> <87brixb5wi.fsf@enki.rimspace.net> <1089124716.1959.108.camel@sisko.scot.redhat.com> <717A478F38F2C5091B3206A3@[192.168.0.5]> <87oemsgxtp.fsf@enki.rimspace.net> Message-ID: <72BCACF88B3E02E449875E3F@[192.168.20.66]> --On 07 July 2004 16:01 +1000 Daniel Pittman wrote: > You may want to investigate 'netconsole', if you have it in a suitable > kernel, which I found very helpful -- it let me trap the oops without > needing to find a suitable serial cable. So long as your network card is > still working, anyway. :) Yes it does & will do; summary: more date required :-) Thanks all. Alex From evilninja at gmx.net Wed Jul 7 10:23:15 2004 From: evilninja at gmx.net (evilninja) Date: Wed, 07 Jul 2004 12:23:15 +0200 Subject: Overwriting ext2 Partition with ext3 In-Reply-To: <00b401c4636a$38be5f20$83c8a8c0@nikinotebook> References: <00b401c4636a$38be5f20$83c8a8c0@nikinotebook> Message-ID: <40EBCF13.6090505@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Niki Hammler schrieb: > mke2fs -j /device > > Important is the "-j" switch. > > What happens without the "-j" switch? All superblocks and inodes > are overwritten. Is this true?? i don't think, that all inodes are overwritten. mkfs.?fs is pretty fast, so it's creating the superblock and the journal (-j) only. > However, can you tell me if it is theoretically possible to recover data > maybe even with meta info (file name)? > Then I would give my harddrive to a professional recover company. we had a case here, where *something* has corrupted our shiny RAID-5 ext3fs. also we felt safe having a RAID-5, a fsck has moved a lot to lost+found, leaving nothing in the normal dir-tree. we were still missing a lot important files. we then tried several ext2/ext3 recovery tools (e2undel, recover, playing with debugfs), but all seem to fail. we happend to have a windoze machine around and we had some more luck with a tool called "R-Linux": http://www.data-recovery-software.net/Linux_Recovery.shtml and despite the usual "it's impossible to recover data from ext3" we were able to recover a lot of files, that didn't make it to lost+found. Christian. - -- BOFH excuse #405: Sysadmins unavailable because they are in a meeting talking about why they are unavailable so much. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA688TC/PVm5+NVoYRAmSxAKC9qtVDxepGudWnkgVQ5bj/WJ+cfwCgz4qG jbL6zBFgZHoHfDMa7shynlU= =LYB4 -----END PGP SIGNATURE----- From matts at ksu.edu Wed Jul 7 19:29:51 2004 From: matts at ksu.edu (Matt Stegman) Date: Wed, 7 Jul 2004 14:29:51 -0500 (CDT) Subject: Overwriting ext2 Partition with ext3 In-Reply-To: <40EBCF13.6090505@gmx.net> Message-ID: On Wed, 7 Jul 2004, evilninja wrote: > Niki Hammler schrieb: > > mke2fs -j /device > > > > Important is the "-j" switch. > > > > What happens without the "-j" switch? All superblocks and inodes > > are overwritten. Is this true?? > > i don't think, that all inodes are overwritten. mkfs.?fs is pretty fast, > so it's creating the superblock and the journal (-j) only. It looks to me like the manpage says default options will overwrite superblocks, group descriptors, block & inode bitmaps, and inode table. If it didn't overwrite inodes, an fsck run immediately after mkfs would find old inode data. Maybe disconnected inodes if you had a filesystem on the device previously, maybe random data. There is a -S switch for mke2fs. It tells it not to overwrite the bitmaps and inode table. Data blocks should have been left alone, assuming you haven't written anything new to the filesystem (except wherever the journal is written; I believe it's a regular file, and debugfs should be able provide you with a block map). So pretty much I think the only way you'll be able to recover your data is grepping through the block device. -- Matt Stegman From norberto.merchan at stl.es Thu Jul 8 11:27:04 2004 From: norberto.merchan at stl.es (Norberto =?iso-8859-15?q?Mech=E1n=20Pedrajas?=) Date: Thu, 8 Jul 2004 13:27:04 +0200 Subject: /.journal ext3 on a flash Message-ID: <200407081127.i68BRnl11952@zurbaran.stl.es> Hi, I'm formatting a flash with ext3, but I need to move the journaling file (/.journal) in the flash to prevent it's corruption. In previous message I read that it's possible (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), but I can't find any /.journal in my ext3 fs. How can move the journaling file in the flash without /.journal file?? Thanks From fabian.frederick at skynet.be Thu Jul 8 11:39:16 2004 From: fabian.frederick at skynet.be (FabF) Date: Thu, 08 Jul 2004 13:39:16 +0200 Subject: /.journal ext3 on a flash In-Reply-To: <200407081127.i68BRnl11952@zurbaran.stl.es> References: <200407081127.i68BRnl11952@zurbaran.stl.es> Message-ID: <1089286756.3691.61.camel@localhost.localdomain> On Thu, 2004-07-08 at 13:27, Norberto Mech?n Pedrajas wrote: > Hi, > I'm formatting a flash with ext3, but I need to move the journaling file > (/.journal) in the flash to prevent it's corruption. mkfs -t ext3 /dev/xxx does copy journal file in /dev/xxx already.You don't see it coz it's hidden.If you can mount device in ext3, journal is obviously in there. Regards, FabF > > In previous message I read that it's possible > (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), but I > can't find any /.journal in my ext3 fs. > How can move the journaling file in the flash without /.journal file?? > Thanks > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users > From fabian.frederick at skynet.be Thu Jul 8 11:44:51 2004 From: fabian.frederick at skynet.be (FabF) Date: Thu, 08 Jul 2004 13:44:51 +0200 Subject: /.journal ext3 on a flash In-Reply-To: <200407081127.i68BRnl11952@zurbaran.stl.es> References: <200407081127.i68BRnl11952@zurbaran.stl.es> Message-ID: <1089287090.3691.63.camel@localhost.localdomain> On Thu, 2004-07-08 at 13:27, Norberto Mech?n Pedrajas wrote: > Hi, > I'm formatting a flash with ext3, but I need to move the journaling file > (/.journal) in the flash to prevent it's corruption. > > In previous message I read that it's possible > (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), but I > can't find any /.journal in my ext3 fs. > How can move the journaling file in the flash without /.journal file?? ...and there's no way to have journal in another device AFAIK .... Regards, FabF From cpwright at cpwright.com Thu Jul 8 12:34:55 2004 From: cpwright at cpwright.com (Charles P. Wright) Date: Thu, 08 Jul 2004 08:34:55 -0400 Subject: /.journal ext3 on a flash In-Reply-To: <1089287090.3691.63.camel@localhost.localdomain> References: <200407081127.i68BRnl11952@zurbaran.stl.es> <1089287090.3691.63.camel@localhost.localdomain> Message-ID: <1089290095.30733.2.camel@polarbear.fsl.cs.sunysb.edu> You can set the device at file system creation time with mke2fs. Check the man page, but something like this should work: mke2fs -O journal_device /dev/flash mke2fs -j -J device=/dev/flash /dev/hdaX You can change an existing file system using tune2fs. Charles On Thu, 2004-07-08 at 07:44, FabF wrote: > On Thu, 2004-07-08 at 13:27, Norberto Mech?n Pedrajas wrote: > > Hi, > > I'm formatting a flash with ext3, but I need to move the journaling file > > (/.journal) in the flash to prevent it's corruption. > > > > In previous message I read that it's possible > > (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), but I > > can't find any /.journal in my ext3 fs. > > How can move the journaling file in the flash without /.journal file?? > ...and there's no way to have journal in another device AFAIK .... > > Regards, > FabF > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From daniel at rimspace.net Thu Jul 8 12:14:56 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 08 Jul 2004 22:14:56 +1000 Subject: /.journal ext3 on a flash References: <200407081127.i68BRnl11952@zurbaran.stl.es> Message-ID: <87briqd7b3.fsf@enki.rimspace.net> On 8 Jul 2004, Norberto Mech wrote: > I'm formatting a flash with ext3, but I need to move the journaling file > (/.journal) in the flash to prevent it's corruption. > > In previous message I read that it's possible > (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), but I > can't find any /.journal in my ext3 fs. The journal lives as inode 8, and is usually not linked to any directory entry anywhere. The '.journal' file is a relic of the past, pretty much, with ext3 these days. Running e2fsck on an unmounted ext3 filesystem will hide the journal, removing that entry, as well. > How can move the journaling file in the flash without /.journal file?? You would need something to move around the blocks associated with inode 8, without needing to touch the filename. To achieve this, I would suggest that you implement an interface to "relocate" a block in an ext3 filesystem; that interface could then achieve your goal (with careful locking) as well as implementing online defragmentation and, potentially, other valuable filesystem operations. Achieving this, safely, is left as an exercise for the student. ;) Daniel -- If a joke is worth telling, it's worth telling once. -- Ollie MacNoonan From daniel at rimspace.net Thu Jul 8 12:15:38 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 08 Jul 2004 22:15:38 +1000 Subject: /.journal ext3 on a flash References: <200407081127.i68BRnl11952@zurbaran.stl.es> <1089287090.3691.63.camel@localhost.localdomain> Message-ID: <877jted79x.fsf@enki.rimspace.net> On 8 Jul 2004, FabF wrote: > On Thu, 2004-07-08 at 13:27, Norberto Mech??n Pedrajas wrote: >> Hi, >> I'm formatting a flash with ext3, but I need to move the journaling file >> (/.journal) in the flash to prevent it's corruption. >> >> In previous message I read that it's possible >> (https://www.redhat.com/archives/ext3-users/2004-March/msg00009.html), >> but I can't find any /.journal in my ext3 fs. How can move the >> journaling file in the flash without /.journal file?? > > ...and there's no way to have journal in another device AFAIK .... ext3 did, and does, support external journals; see 'mke2fs -J device=' Daniel -- 99 dreams I have had / In every one a red balloon It's all over and I'm standing pretty / In this dust that was a city If I could find a souvenir / Just to prove the world was here -- Nina, _99 Red Balloons_ From dchan at veritas.com Thu Jul 8 23:42:03 2004 From: dchan at veritas.com (david x chan) Date: Thu, 08 Jul 2004 16:42:03 -0700 Subject: O-direct on ext3 file ssytem Message-ID: <40EDDBCB.6090402@veritas.com> Hi, Does anybody know whether the ext3 file system support Direct_io? if so, how do you enable it? I went through the man page of mount, and it did not mention such option? my system is running : Red Hat Enterprise Linux AS release 3 (Taroon Update 2) Kernel 2.4.21-15.ELsmp on an i686 Thanks much!!! David. From evilninja at gmx.net Fri Jul 9 12:02:47 2004 From: evilninja at gmx.net (evilninja) Date: Fri, 09 Jul 2004 14:02:47 +0200 Subject: O-direct on ext3 file ssytem In-Reply-To: <40EDDBCB.6090402@veritas.com> References: <40EDDBCB.6090402@veritas.com> Message-ID: <40EE8967.8030502@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 david x chan schrieb: > > > Hi, > > Does anybody know whether the ext3 file system > support Direct_io? if so, how do you enable it? > I went through the man page of mount, and it did > not mention such option? there was an announcement on lkml, but the patch was not taken to mainline i think: http://seclists.org/lists/linux-kernel/2003/Jun/3705.html Christian. - -- BOFH excuse #374: It's the InterNIC's fault. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7olnC/PVm5+NVoYRAr6RAJ9GKNf0jWzhpZOH+OEH2MzrB7GxYACgtejk s9PXr6Cp8MEhP4Iv2gcsv3w= =PR10 -----END PGP SIGNATURE----- From m.c.p at gmx.net Fri Jul 9 12:22:25 2004 From: m.c.p at gmx.net (Marc-Christian Petersen) Date: Fri, 9 Jul 2004 14:22:25 +0200 Subject: O-direct on ext3 file ssytem In-Reply-To: <40EDDBCB.6090402@veritas.com> References: <40EDDBCB.6090402@veritas.com> Message-ID: <200407091422.25831@WOLK> On Friday 09 July 2004 01:42, david x chan wrote: Hi David, > Does anybody know whether the ext3 file system > support Direct_io? if so, how do you enable it? > I went through the man page of mount, and it did > not mention such option? ext3 supports direct i/o, but not in 2.4 mainline. It was added in 2.6. Further direct i/o isn't a mount option. Please read http://lse.sourceforge.net/io/aio.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/1213.html for example. > my system is running : > Red Hat Enterprise Linux AS release 3 (Taroon Update > 2) > Kernel 2.4.21-15.ELsmp on an i686 2.4-aa, 2.4-suse, 2.4-wolk tree and some others have it, 2.4-rh kernels do not have it. -- ciao, Marc From dchan_95035 at yahoo.com Thu Jul 8 22:15:46 2004 From: dchan_95035 at yahoo.com (David Chan) Date: Thu, 8 Jul 2004 15:15:46 -0700 (PDT) Subject: directio for ext3 file system Message-ID: <20040708221546.90573.qmail@web12101.mail.yahoo.com> Hi, Does anybody know whether the ext3 file system support Direct_io? if so, how do you enable it? I went through the man page of mount, and it did not mention such option? my system is running : Red Hat Enterprise Linux AS release 3 (Taroon Update 2) Kernel 2.4.21-15.ELsmp on an i686 Thanks much!!! David. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From sct at redhat.com Fri Jul 9 15:24:39 2004 From: sct at redhat.com (Stephen C. Tweedie) Date: 09 Jul 2004 16:24:39 +0100 Subject: O-direct on ext3 file ssytem In-Reply-To: <200407091422.25831@WOLK> References: <40EDDBCB.6090402@veritas.com> <200407091422.25831@WOLK> Message-ID: <1089386679.2856.84.camel@sisko.scot.redhat.com> Hi, On Fri, 2004-07-09 at 13:22, Marc-Christian Petersen wrote: > ext3 supports direct i/o, but not in 2.4 mainline. It was added in 2.6. > > my system is running : > > Red Hat Enterprise Linux AS release 3 (Taroon Update > > 2) > > Kernel 2.4.21-15.ELsmp on an i686 > > 2.4-aa, 2.4-suse, 2.4-wolk tree and some others have it, 2.4-rh kernels do not > have it. 2.4 RHL kernels did not; RHEL 3 does, so 2.4.21-15.EL will have it. --Stephen From dchan at veritas.com Fri Jul 9 20:32:28 2004 From: dchan at veritas.com (david x chan) Date: Fri, 09 Jul 2004 13:32:28 -0700 Subject: O-direct on ext3 file ssytem References: <40EDDBCB.6090402@veritas.com> <200407091422.25831@WOLK> <1089386679.2856.84.camel@sisko.scot.redhat.com> Message-ID: <40EF00DC.2000700@veritas.com> Thanks much to all !! I now have enough information to move on . Best Regards, David. Stephen C. Tweedie wrote: >Hi, > >On Fri, 2004-07-09 at 13:22, Marc-Christian Petersen wrote: > > > >>ext3 supports direct i/o, but not in 2.4 mainline. It was added in 2.6. >> >> > > > >>>my system is running : >>>Red Hat Enterprise Linux AS release 3 (Taroon Update >>>2) >>>Kernel 2.4.21-15.ELsmp on an i686 >>> >>> >>2.4-aa, 2.4-suse, 2.4-wolk tree and some others have it, 2.4-rh kernels do not >>have it. >> >> > >2.4 RHL kernels did not; RHEL 3 does, so 2.4.21-15.EL will have it. > >--Stephen > > > >_______________________________________________ >Ext3-users mailing list >Ext3-users at redhat.com >https://www.redhat.com/mailman/listinfo/ext3-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmc4slack-jfs at yahoo.com Sun Jul 11 23:54:17 2004 From: cmc4slack-jfs at yahoo.com (cmc4slack-jfs at yahoo.com) Date: Sun, 11 Jul 2004 16:54:17 -0700 (PDT) Subject: mixing ext3 and reiserfs on slackware 10 Message-ID: <20040711235417.26820.qmail@web80806.mail.yahoo.com> Will I run into any problems mixing ReiserFS and ext3 on my slackware linux box? I'm using ReiserFS and LVM on the current version, thinking of mixing it up a bit with slackware 10, again with LVM. Thanks for any advice! ===== Christopher Mark Conn http://storm.cadcam.iupui.edu/~cmcgoat Austin, Texas, USA From akpm at osdl.org Mon Jul 12 00:51:26 2004 From: akpm at osdl.org (Andrew Morton) Date: Sun, 11 Jul 2004 17:51:26 -0700 Subject: O-direct on ext3 file ssytem In-Reply-To: <1089386679.2856.84.camel@sisko.scot.redhat.com> References: <40EDDBCB.6090402@veritas.com> <200407091422.25831@WOLK> <1089386679.2856.84.camel@sisko.scot.redhat.com> Message-ID: <20040711175126.678750c8.akpm@osdl.org> "Stephen C. Tweedie" wrote: > > Hi, > > On Fri, 2004-07-09 at 13:22, Marc-Christian Petersen wrote: > > > ext3 supports direct i/o, but not in 2.4 mainline. It was added in 2.6. > > > > my system is running : > > > Red Hat Enterprise Linux AS release 3 (Taroon Update > > > 2) > > > Kernel 2.4.21-15.ELsmp on an i686 > > > > 2.4-aa, 2.4-suse, 2.4-wolk tree and some others have it, 2.4-rh kernels do not > > have it. > > 2.4 RHL kernels did not; RHEL 3 does, so 2.4.21-15.EL will have it. > oop, nobody told me that. You might need to add this fix: ext3_direct_io_get_blocks() is misinterpreting the return value from ext3_journal_extend(), and is consequently running out of buffer credits and going BUG on tremendously large direct-io writes. Fix that up. Also, I note that the really large direct-io writes can hold a transaction open for the entire duration, which can be minutes. This violates ext3's attempt to commit data at regular intervals. Fix that up by looking at the transaction state: if it's T_LOCKED, shut off the current handle so the pending commit can complete. Signed-off-by: Andrew Morton --- 25-akpm/fs/ext3/inode.c | 28 ++++++++++++++++++++++------ 1 files changed, 22 insertions(+), 6 deletions(-) diff -puN fs/ext3/inode.c~ext3-direct-io-credits-overflow-fix fs/ext3/inode.c --- 25/fs/ext3/inode.c~ext3-direct-io-credits-overflow-fix 2004-06-27 00:19:37.609592016 -0700 +++ 25-akpm/fs/ext3/inode.c 2004-06-27 00:19:37.616590952 -0700 @@ -881,26 +881,42 @@ ext3_direct_io_get_blocks(struct inode * handle_t *handle = journal_current_handle(); int ret = 0; - if (handle && handle->h_buffer_credits <= EXT3_RESERVE_TRANS_BLOCKS) { + if (!handle) + goto get_block; /* A read */ + + if (handle->h_transaction->t_state == T_LOCKED) { + /* + * Huge direct-io writes can hold off commits for long + * periods of time. Let this commit run. + */ + ext3_journal_stop(handle); + handle = ext3_journal_start(inode, DIO_CREDITS); + if (IS_ERR(handle)) + ret = PTR_ERR(handle); + goto get_block; + } + + if (handle->h_buffer_credits <= EXT3_RESERVE_TRANS_BLOCKS) { /* * Getting low on buffer credits... */ - if (!ext3_journal_extend(handle, DIO_CREDITS)) { + ret = ext3_journal_extend(handle, DIO_CREDITS); + if (ret > 0) { /* - * Couldn't extend the transaction. Start a new one + * Couldn't extend the transaction. Start a new one. */ ret = ext3_journal_restart(handle, DIO_CREDITS); } } + +get_block: if (ret == 0) ret = ext3_get_block_handle(handle, inode, iblock, bh_result, create, 0); - if (ret == 0) - bh_result->b_size = (1 << inode->i_blkbits); + bh_result->b_size = (1 << inode->i_blkbits); return ret; } - /* * `handle' can be NULL if create is zero */ _ From yusufg at outblaze.com Wed Jul 14 04:26:15 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 14 Jul 2004 12:26:15 +0800 Subject: Anybody using a UMEM MM5415 NVRAM card for external journal on 2.6 Message-ID: <20040714042615.GA12945@outblaze.com> Hi, I was wondering if anybody was using a UMEM NVRAM card [the MM5415 family] as an external journal for ext3. According to the help text in 2.6.7 config, it doesn't have a major number assigned so it chooses one dynamically. It suggests to use 'devfs' (which I thought was deprecated in 2.6.x) or look in /proc/devices. I was wondering if anybody was using this card and what they were doing to get round the major number moratorium Regards, Yusuf From bryan at kdzbn.homelinux.net Wed Jul 14 10:59:53 2004 From: bryan at kdzbn.homelinux.net (Bryan Kadzban) Date: Wed, 14 Jul 2004 06:59:53 -0400 Subject: Anybody using a UMEM MM5415 NVRAM card for external journal on 2.6 In-Reply-To: <20040714042615.GA12945@outblaze.com> References: <20040714042615.GA12945@outblaze.com> Message-ID: <40F51229.9020809@kdzbn.homelinux.net> Yusuf Goolamabbas wrote: > According to the help text in 2.6.7 config, it doesn't have a major > number assigned so it chooses one dynamically. It suggests to use > 'devfs' (which I thought was deprecated in 2.6.x) or look in > /proc/devices. > > I was wondering if anybody was using this card and what they were > doing to get round the major number moratorium I'm not using it, but I'd use udev to create the device nodes (since I do use udev). It's like devfs, only entirely in userspace. http://www.linuxfromscratch.org/lfs/view/unstable/chapter06/udev.html http://www.reactivated.net/udevrules.php The existing docs aren't all that great on it, but the second link (Writing udev Rules) is helpful if you don't want to download and use the LFS permissions and rules files, because you'll have to write some of your own permissions and rules. From simon.oliver at umist.ac.uk Wed Jul 14 12:56:34 2004 From: simon.oliver at umist.ac.uk (Simon Oliver) Date: Wed, 14 Jul 2004 13:56:34 +0100 Subject: ext3 performance with hardware RAID5 Message-ID: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> I'm setting up a new fileserver. It has two RAID controllers, a PERC 3/DI providing mirrored system disks and a PERC 3/DC providing a 1TB RAID5 volume consisting of eight 144GB U160 drives. This will serve NFS, Samba and sftp clients for about 200 users. The logical drive was created with the following settings: RAID = 5 stripe size = 32kb write policy = wrback read policy = adaptive cache policy = CachedIO #stripes = 8 I intend to revisit the effects of stripe size and read/write/cache policies at a later stage, but any advice on selecting the appropriate parameters is greatly appreciated. I considered other file systems but have chosen ext3 for various reasons not discussed here. When creating the file system I used the following options: -O sparse_super -O dir_index -R stride=8 -O sparse_super because I don't want to waste too much space -O dir_index because this is supposed to help file listing performance with Samba shares -R stride=8 because of the 32kb stripe size (4kb*8=32kb) The next stage in my plan is to optimise file system performance. I've decided to use bonnie++ (local execution) for the initial tests. I will then extend the tests to factor in network file system performance (via NFS and Samba) with multiple simultaneous loads. I decided to investigate the use of an external log device. I have read that it can improve performance for RAID 5 volumes, especially when the log file is on a separate mirrored volume. I have also read that using data=journal can further improve performance for applications such as NFS. For these tests I created a 256MB partition in the mirrored disk set for the log device: /dev/sdb6. The RAID5 volume is a 500GB partition: /dev/sda1. Here is a summary of the results: Log location: - log location does not affect the file system performance as measured by the sequential output and sequential input tests - random seek rate improves with an external log (25%) - log location affects the random create "create" test results and has a massive impact on the random create "read" and "delete" test results Data journaling: - data journaling does not affect sequential input or random seek test results - data journaling significantly reduces the performance of the file system with regard to sequential output, sequential create and random create (between 25% and 56% decrease). - data journaling improves file system performance in only one area, the random create "delete" rate. Writeback journaling: - data=writeback has few performance benefits over data=ordered: - sequential create "read" (50% faster) - random create "delete" (100% faster) - data=writeback under performed for the random create "create" and "read" tests Please provide feedback on these results, especially on the significance of the random create tests. I would also like to hear any suggestions on how I might further improve file system performance or my test methodology. The tests... # internal log mkfs.ext3 -v -O sparse_super -O dir_index -R stride=8 /dev/sda1 mount -t ext3 /dev/sda1 /mnt mkdir -m 777 /mnt/t bonnie++ -u nobody:nobody -d /mnt/t -s 4g -m ss1 -n128:20000:16:512 Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ss1 4G 28235 94 38522 28 17222 8 22257 61 40274 10 598.0 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 128:20000:16/512 1566 17 11216 24 9255 43 1872 20 500 1 101 1 ss1,4G,28235,94,38522,28,17222,8,22257,61,40274,10,598.0,1,128:20000:16/512, 1566,17,11216,24,9255,43,1872,20,500,1,101,1 # external log mke2fs -v -s 4096 -O journal_dev /dev/sdb6 mkfs.ext3 -v -j -J device=/dev/sdb6 -O sparse_super -O dir_index -R stride=8 /dev/sda1 mount -t ext3 /dev/sda1 /mnt mkdir -m 777 /mnt/t bonnie++ -u nobody:nobody -d /mnt/t -s 4g -m ss1 -n128:20000:16:512 Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ss1 4G 28557 95 38721 28 17354 8 22077 60 40036 10 742.7 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 128:20000:16/512 1558 17 24247 51 20063 92 2512 28 39603 100 8696 48 ss1,4G,28557,95,38721,28,17354,8,22077,60,40036,10,742.7,1,128:20000:16/512, 1558,17,24247,51,20063,92,2512,28,39603,100,8696,48 # external data log mke2fs -v -s 4096 -O journal_dev /dev/sdb6 mkfs.ext3 -v -j -J device=/dev/sdb6 -O sparse_super -O dir_index -R stride=8 /dev/sda1 mount -t ext3 -o data=journal /dev/sda1 /mnt mkdir -m 777 /mnt/t bonnie++ -u nobody:nobody -d /mnt/t -s 4g -m ss1 -n128:20000:16:512 Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ss1 4G 12369 47 17023 21 12894 14 22120 61 40720 10 736.0 2 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 128:20000:16/512 1128 16 5103 12 20367 95 1144 16 725 2 17172 94 ss1,4G,12369,47,17023,21,12894,14,22120,61,40720,10,736.0,2,128:20000:16/512 ,1128,16,5103,12,20367,95,1144,16,725,2,17172,94 # external data log with writeback mke2fs -v -s 4096 -O journal_dev /dev/sdb6 mkfs.ext3 -v -j -J device=/dev/sdb6 -O sparse_super -O dir_index -R stride=8 /dev/sda1 mount -t ext3 -o data=writeback /dev/sda1 /mnt mkdir -m 777 /mnt/t bonnie++ -u nobody:nobody -d /mnt/t -s 4g -m ss1 -n128:20000:16:512 Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ss1 4G 28205 95 37493 25 17134 7 21320 59 40395 10 756.3 2 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 128:20000:16/512 1637 17 36370 76 20284 94 2109 22 27351 70 17057 94 ss1,4G,28205,95,37493,25,17134,7,21320,59,40395,10,756.3,2,128:20000:16/512, 1637,17,36370,76,20284,94,2109,22,27351,70,17057,94 -- Simon Oliver -------------- next part -------------- A non-text attachment was scrubbed... Name: ext3.pdf Type: application/pdf Size: 16811 bytes Desc: not available URL: From arjanv at redhat.com Wed Jul 14 13:00:42 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Jul 2004 15:00:42 +0200 Subject: ext3 performance with hardware RAID5 In-Reply-To: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> References: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> Message-ID: <1089810042.2806.5.camel@laptop.fenrus.com> On Wed, 2004-07-14 at 14:56, Simon Oliver wrote: > -O dir_index because this is supposed to help file listing performance with > Samba shares -R stride=8 because of the 32kb stripe size (4kb*8=32kb) > RHEL3 does not include HTREE though (the thing that uses dir_index) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From adilger at clusterfs.com Wed Jul 14 16:50:45 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Wed, 14 Jul 2004 10:50:45 -0600 Subject: ext3 performance with hardware RAID5 In-Reply-To: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> References: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> Message-ID: <20040714165045.GN23346@schnapps.adilger.int> On Jul 14, 2004 13:56 +0100, Simon Oliver wrote: > I would also like to hear any suggestions on how I might further improve > file system performance or my test methodology. You didn't specify the size of the external journal device. In our testing we found that having a larger journal (internal) made a large difference in performance. I believe that the external journal will be the full size of the device (could be wrong of course) so it is probably worthwhile to ensure that the external journal is the same size as the internal journal (can be specified with "-J size=" for an internal journal, and "mke2fs -s 4096 -O journal_dev /dev/sdb6 " for the external journal. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shanson at cruiskeen.com Wed Jul 14 20:33:46 2004 From: shanson at cruiskeen.com (Steve Hanson) Date: Wed, 14 Jul 2004 15:33:46 -0500 Subject: ext3 performance with hardware RAID5 In-Reply-To: <20040714165045.GN23346@schnapps.adilger.int> References: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> <20040714165045.GN23346@schnapps.adilger.int> Message-ID: <40F598AA.8020806@cruiskeen.com> Andreas Dilger wrote: > On Jul 14, 2004 13:56 +0100, Simon Oliver wrote: > >>I would also like to hear any suggestions on how I might further improve >>file system performance or my test methodology. > > > You didn't specify the size of the external journal device. In our > testing we found that having a larger journal (internal) made a large > difference in performance. I believe that the external journal will > be the full size of the device (could be wrong of course) so it is > probably worthwhile to ensure that the external journal is the same > size as the internal journal (can be specified with "-J size=" for > an internal journal, and "mke2fs -s 4096 -O journal_dev /dev/sdb6 " > for the external journal. > > Well, actually, he did say - if you read the whole text of the email the mke2fs commands are included in the mail - # external data log mke2fs -v -s 4096 -O journal_dev /dev/sdb6 mkfs.ext3 -v -j -J device=/dev/sdb6 -O sparse_super -O dir_index -R stride=8 /dev/sda1 mount -t ext3 -o data=journal /dev/sda1 /mnt mkdir -m 777 /mnt/t bonnie++ -u nobody:nobody -d /mnt/t -s 4g -m ss1 -n128:20000:16:512 From adilger at clusterfs.com Wed Jul 14 21:00:54 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Wed, 14 Jul 2004 15:00:54 -0600 Subject: ext3 performance with hardware RAID5 In-Reply-To: <40F598AA.8020806@cruiskeen.com> References: <002401c469a1$fe05a350$a06e5882@bi.umist.ac.uk> <20040714165045.GN23346@schnapps.adilger.int> <40F598AA.8020806@cruiskeen.com> Message-ID: <20040714210054.GS23346@schnapps.adilger.int> On Jul 14, 2004 15:33 -0500, Steve Hanson wrote: > Andreas Dilger wrote: > >You didn't specify the size of the external journal device. In our > >testing we found that having a larger journal (internal) made a large > >difference in performance. I believe that the external journal will > >be the full size of the device (could be wrong of course) so it is > >probably worthwhile to ensure that the external journal is the same > >size as the internal journal (can be specified with "-J size=" for > >an internal journal, and "mke2fs -s 4096 -O journal_dev /dev/sdb6 " > >for the external journal. > > Well, actually, he did say - if you read the whole text of > the email the mke2fs commands are included in the mail - > > # external data log > mke2fs -v -s 4096 -O journal_dev /dev/sdb6 > mkfs.ext3 -v -j -J device=/dev/sdb6 -O sparse_super -O dir_index -R stride=8 Actually, he didn't. Nowhere does it report the size of /dev/sdb6. The "-b 4096" option just tells you the blocksize. The internal journal will be 32MB, but if /dev/sdb6 is 400MB or whatever then it will give a large advantage to the external journal setup. It won't really test whether the external journal is the source of the speedup or if the large journal is the source. It might also be interesting to see what the perf looks like with a ramdisk as the external journal (e.g. simulate an NVRAM device). I imagine it won't be much better than just the external journal, since you are doing mostly sequential IO to the external journal anyways. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dchan at veritas.com Wed Jul 14 22:12:14 2004 From: dchan at veritas.com (david x chan) Date: Wed, 14 Jul 2004 15:12:14 -0700 Subject: O-direct on ext3 file ssytem References: <40EDDBCB.6090402@veritas.com> <200407091422.25831@WOLK> <1089386679.2856.84.camel@sisko.scot.redhat.com> Message-ID: <40F5AFBE.5020106@veritas.com> Hi I am back ... with more questions. I am currently running oracle 9205 with patches 3016968 (async io fix) & 2448994_9205 (direct io fix). All my data files are residing on an ext3 file system. /dev/tpccvg/tpcc_disks on /tpcc_disks type ext3 (rw) /dev/tpccvg/log1_1 on /log1_1 type ext3 (rw) /dev/tpccvg/log2_1 on /log2_1 type ext3 (rw) /dev/tpccvg/log3_1 on /log3_1 type ext3 (rw) /dev/tpccvg/log4_1 on /log4_1 type ext3 (rw) /dev/tpccvg/log5_1 on /log5_1 type ext3 (rw) /dev/tpccvg/log6_1 on /log6_1 type ext3 (rw) /dev/tpccvg/log7_1 on /log7_1 type ext3 (rw) /dev/tpccvg/log8_1 on /log8_1 type ext3 (rw) Whenever I tried to start up oracle with 'filesystemio_options=directio', it failed to mount the dbase due to problem writing to the control file: LCK0 started with pid=16 Wed Jul 14 13:12:57 2004 ORA-00204: error in reading (block 1, # blocks 1) of controlfile ORA-00202: controlfile: '/tpcc_disks/control_001' ORA-27091: skgfqio: unable to queue I/O ORA-27072: skgfdisp: I/O error Linux Error: 22: Invalid argument Additional information: 1 if I do a trace on the process, it shown that oracle is doing the correct things by open the file with O_DIRECT flag: 5997 <... rt_sigprocmask resumed> NULL, 8) = 0 5990 open("/tpcc_disks/control_001", O_RDONLY|O_DIRECT|O_LARGEFILE 5997 semop(3342337, 0xbfff5108, 1 is there any thing that I need to do for ext3 in order for O_DIRECT to work??? Am I missing some library files on the OS kernel level? MAny thanks in advance for your time. Regards, David Stephen C. Tweedie wrote: >Hi, > >On Fri, 2004-07-09 at 13:22, Marc-Christian Petersen wrote: > > > >>ext3 supports direct i/o, but not in 2.4 mainline. It was added in 2.6. >> >> > > > >>>my system is running : >>>Red Hat Enterprise Linux AS release 3 (Taroon Update >>>2) >>>Kernel 2.4.21-15.ELsmp on an i686 >>> >>> >>2.4-aa, 2.4-suse, 2.4-wolk tree and some others have it, 2.4-rh kernels do not >>have it. >> >> > >2.4 RHL kernels did not; RHEL 3 does, so 2.4.21-15.EL will have it. > >--Stephen > > > >_______________________________________________ >Ext3-users mailing list >Ext3-users at redhat.com >https://www.redhat.com/mailman/listinfo/ext3-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.oliver at umist.ac.uk Thu Jul 15 08:46:36 2004 From: simon.oliver at umist.ac.uk (Simon Oliver) Date: Thu, 15 Jul 2004 09:46:36 +0100 Subject: ext3 performance with hardware RAID5 In-Reply-To: <20040714165045.GN23346@schnapps.adilger.int> Message-ID: <009101c46a48$3cd66690$a06e5882@bi.umist.ac.uk> > You didn't specify the size of the external journal device. > In our testing we found that having a larger journal > (internal) made a large difference in performance. >> For these tests I created a 256MB partition in the mirrored disk set for the log device: /dev/sdb6. The internal log was the default size (32MB?). The external journal device is 256MB. >From what I've read the journal size doesn't come into play until the load becomes very high such as with lots or NFS IO. I've also read that "if the journal ever gets full, the throughput pauses for a while until every transaction in the journal has been checkpointed onto the main device. One way to avoid this is to reduce the flush time by altering /proc/sys/vm/bdflush. This way transactions get flushed to disc before the journal fills." Do you have any experience with this? Is there any way to monitor how full the journal gets? > I believe > that the external journal will be the full size of the device > (could be wrong of course) so it is probably worthwhile to > ensure that the external journal is the same size as the > internal journal (can be specified with "-J size=" for an > internal journal, and "mke2fs -s 4096 -O journal_dev > /dev/sdb6 " for the external journal. Good point - I'll make that change and rerun the tests. -- Simon Oliver From tsw at animatele.com Fri Jul 16 01:41:19 2004 From: tsw at animatele.com (Ilya Balashov) Date: Fri, 16 Jul 2004 05:41:19 +0400 Subject: Assertion failure in transaction.c Message-ID: I am running Debian Potato with kernel 2.4.27-rc3 on a Sparc Server 20, 128MB RAM machine. After few hours I get the following error in the syslog kernel file Jul 15 01:09:25 mudshark kernel: Assertion failure in journal_stop() at transaction.c:1418: "journal_current_handle() == handle" Jul 15 01:09:25 mudshark kernel: kernel BUG at transaction.c:1418! Jul 15 01:09:25 mudshark kernel: Unable to handle kernel NULL pointer dereference Jul 15 01:09:25 mudshark kernel: tsk->{mm,active_mm}->context = 000000dd Jul 15 01:09:25 mudshark kernel: tsk->{mm,active_mm}->pgd = fc027800 Is this a Kernel Bug or a Ext3 Bug or an application problem or anything else? -- Regards, Ilya Balashov AnimaTel, Inc. From tytso at mit.edu Fri Jul 16 17:46:45 2004 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 16 Jul 2004 13:46:45 -0400 Subject: Assertion failure in transaction.c In-Reply-To: References: Message-ID: <20040716174645.GG16381@thunk.org> On Fri, Jul 16, 2004 at 05:41:19AM +0400, Ilya Balashov wrote: > I am running Debian Potato with kernel 2.4.27-rc3 on a Sparc Server 20, > 128MB RAM machine. > > After few hours I get the following error in the syslog kernel file > Jul 15 01:09:25 mudshark kernel: Assertion failure in journal_stop() at > transaction.c:1418: "journal_current_handle() == handle" I can't say for sure, but the last couple of times I've had to track down errors of this sort, it was caused by a kernel stack overflow corrupting the journal_info pointer in the task structure. I'd look out for a misbehaving device driver that is using too much stack space..... - Ted From my_qa2004 at yahoo.com Wed Jul 21 11:24:03 2004 From: my_qa2004 at yahoo.com (Ash) Date: Wed, 21 Jul 2004 04:24:03 -0700 (PDT) Subject: Quota Support Message-ID: <20040721112403.51749.qmail@web53203.mail.yahoo.com> Hi I want to know the current status of Quota support on Ext3FS over the 2.6.7 kernels. I read something about potential deadlock issues/crashes with quotas on Ext3. How stable is the curent quota support (specifically on 2.6 kernels) ? Another thing, in the man page for mount, it says that "These options are accepted but ignored" for "grpquota / noquota / quota / usrquota" options under ext2. What does this signify ? Any resources/pointers will be greatly appreciated. Thanks Ash __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From crosser at rol.ru Wed Jul 21 14:42:41 2004 From: crosser at rol.ru (Eugene Crosser) Date: Wed, 21 Jul 2004 18:42:41 +0400 Subject: Quota Support In-Reply-To: <20040721112403.51749.qmail@web53203.mail.yahoo.com> References: <20040721112403.51749.qmail@web53203.mail.yahoo.com> Message-ID: <1090420961.5223.11.camel@ariel.sovam.com> On Wed, 2004-07-21 at 04:24 -0700, Ash wrote: > I want to know the current status of Quota support on > Ext3FS over the 2.6.7 kernels. > I read something about potential deadlock > issues/crashes with quotas on Ext3. How stable is the > curent quota support (specifically on 2.6 kernels) ? On a filesystem with about a million objects that belong to 300,000 different users, under I/O load of ca. 30 Mb/sec, system hangs after several hours. For me, that is. Probably (?) you need to modify quota to trigger this. > Another thing, in the man page for mount, it says that > > "These options are accepted but ignored" for "grpquota > / noquota / quota / usrquota" options under ext2. What > does this signify ? mount ignores these flags, just writes them into /etc/mtab and nothing more. The flags are actually used by quotaon and quotaoff. Eugene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwbaker at acm.org Thu Jul 22 17:32:26 2004 From: jwbaker at acm.org (Jeffrey W. Baker) Date: Thu, 22 Jul 2004 10:32:26 -0700 Subject: How to interpret corruption error message Message-ID: <1090517546.31196.7.camel@heat> (sort-of xposted from linux-kernel) Hi, I am wondering how to interpret this error message, which popped up on a 2.4.26 SMP x86 box two days ago: EXT2-fs: corrupt root inode, run e2fsck init_special_inode: bogus imode (37316) EXT2-fs: corrupt root inode, run e2fsck init_special_inode: bogus imode (37316) EXT2-fs: corrupt root inode, run e2fsck The problem is, the error message doesn't indicate *which* filesystem we are talking about, and I have three mounted: 1 ext2 and 2 ext3. The ext2 is on a plain old pata disk and the two ext3 filesystems are on software raid5 sata volumes. I'm pretty much afraid to reboot the machine at this point, I have no idea which FS I'm about to lose. Any hints appreciated. -jwb From adilger at clusterfs.com Thu Jul 22 21:18:27 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Thu, 22 Jul 2004 17:18:27 -0400 Subject: How to interpret corruption error message In-Reply-To: <1090517546.31196.7.camel@heat> References: <1090517546.31196.7.camel@heat> Message-ID: <20040722211827.GI1677@schnapps.adilger.int> On Jul 22, 2004 10:32 -0700, Jeffrey W. Baker wrote: > I am wondering how to interpret this error message, which popped up on a > 2.4.26 SMP x86 box two days ago: > > EXT2-fs: corrupt root inode, run e2fsck > init_special_inode: bogus imode (37316) > EXT2-fs: corrupt root inode, run e2fsck > init_special_inode: bogus imode (37316) > EXT2-fs: corrupt root inode, run e2fsck > > The problem is, the error message doesn't indicate *which* filesystem we > are talking about, and I have three mounted: 1 ext2 and 2 ext3. The > ext2 is on a plain old pata disk and the two ext3 filesystems are on > software raid5 sata volumes. The ext3 filesystems would report "EXT3-fs: ...", but yes it would be good if ext3_error() and ext3_warning() would include the device name or number. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rkimber at ntlworld.com Thu Jul 22 21:28:30 2004 From: rkimber at ntlworld.com (rkimber at ntlworld.com) Date: Thu, 22 Jul 2004 22:28:30 +0100 Subject: How to interpret corruption error message In-Reply-To: <20040722211827.GI1677@schnapps.adilger.int> References: <1090517546.31196.7.camel@heat> <20040722211827.GI1677@schnapps.adilger.int> Message-ID: <20040722222830.34ed2502.rkimber@ntlworld.com> On Thu, 22 Jul 2004 17:18:27 -0400 Andreas Dilger wrote: > The ext3 filesystems would report "EXT3-fs: ...", but yes it would be > good if ext3_error() and ext3_warning() would include the device name > or number. Does this mean this will go on some sort of TODO list, or is this just an opinion (which I would share)? - Richard. -- Richard Kimber http://www.psr.keele.ac.uk/ From harvi at matharu.info Thu Jul 22 22:35:23 2004 From: harvi at matharu.info (Harvinder Matharu) Date: Thu, 22 Jul 2004 23:35:23 +0100 Subject: Ext3 filesystem aborting journal at random times (Maxtor 300GB disk) Message-ID: <6B954A5C-DC2F-11D8-9F5F-000A958A3F2E@matharu.info> Hi, Sorry if this is an old and fixed issue but I can't really seem to find a definitive explanation/fix to this in the mail lists. Ever since I upgraded to FC2 my server randomly decides that it can no longer access the disk and "aborts" the ext3 journal leaving it read-only as expected. I've seen the same errors on other mail list, explained away as disk or disk cable issues, but in my case all the disks are all brand new 300GB Maxtors. Does anyone have any ideas? Is it because the current kernel can't handle a 288GB partition? BTW the server is completely up to date as per the up2date command including the kernel (2.6.6-1.435.2.3). Start of fsck: ================================================= [root at server /]# fsck -y -t ext3 /dev/hdc1 fsck 1.35 (28-Feb-2004) e2fsck 1.35 (28-Feb-2004) /dev/hdc1: recovering journal /dev/hdc1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Error reading block 55214498 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes Error reading block 55214499 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes Error reading block 55214500 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes Error reading block 61177858 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes <> Pass 2: Checking directory structure Entry 'ghostscript' in /OLD/usr/share (32112642) has deleted/unused inode 32915539. Clear? yes Entry 'projects' in /OLD/usr/share/gettext (32295519) has deleted/unused inode 32915521. Clear? yes Entry 'disk' in /OLD/usr/include (32608468) has deleted/unused inode 33473295. Clear? yes Entry 'cyrus' in /OLD/usr/include (32608468) has deleted/unused inode 33473299. Clear? yes Entry 'parted' in /OLD/usr/include (32608468) has deleted/unused inode 33492290. Clear? yes Entry 'php' in /OLD/usr/include (32608468) has deleted/unused inode 33492303. Clear? yes Entry '..' in ??? (32915564) has deleted/unused inode 32915540. Clear? yes Entry '..' in ??? (32915786) has deleted/unused inode 32915540. Clear? yes Entry '..' in ??? (32915801) has deleted/unused inode 32915539. Clear? yes <> Pass 3: Checking directory connectivity Unconnected directory inode 32915564 (...) Connect to /lost+found? yes /lost+found not found. Create? yes Error reading block 69730304 (Attempt to read block from filesystem resulted in short read) while reading inode and block bitmaps. Ignore error? yes Force rewrite? yes Unconnected directory inode 32915786 (...) Connect to /lost+found? yes Unconnected directory inode 32915801 (...) Connect to /lost+found? yes Unconnected directory inode 33492357 (...) Connect to /lost+found? yes Unconnected directory inode 33492461 (...) Connect to /lost+found? yes Unconnected directory inode 33492497 (...) Connect to /lost+found? yes Unconnected directory inode 33769637 (Error reading block 67534919 (Attempt to read block from filesystem resulted in short read). Ignore error? yes Force rewrite? yes ???) Connect to /lost+found? yes Couldn't fix parent of inode 33769637: Ext2 inode is not a directory Unconnected directory inode 33769657 (???) Connect to /lost+found? yes Couldn't fix parent of inode 33769657: Ext2 inode is not a directory <> Pass 4: Checking reference counts Inode 32112642 ref count is 316, should be 315. Fix? yes Inode 32295519 ref count is 5, should be 4. Fix? yes Inode 32608468 ref count is 250, should be 246. Fix? yes Unattached inode 32915553 Connect to /lost+found? yes WARNING: PROGRAMMING BUG IN E2FSCK! OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM. inode_link_info[33769637] is 3, inode.i_links_count is 1. They should be the same! Inode 33769637 ref count is 1, should be 2. Fix? yes WARNING: PROGRAMMING BUG IN E2FSCK! OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM. inode_link_info[33769657] is 3, inode.i_links_count is 1. They should be the same! Inode 33769657 ref count is 1, should be 2. Fix? yes <> Pass 5: Checking group summary information Block bitmap differences: -(65853587--65853668) -(66711497--66711572) -(66711644--66711989) -(66968848--66968889) -(67007184--67007226) -(67565768--67566720) +(69730304--69730817) Fix? yes Free blocks count wrong for group #2009 (22014, counted=22096). Fix? yes Free blocks count wrong for group #2035 (21906, counted=22328). Fix? yes Free blocks count wrong for group #2043 (22014, counted=22056). Fix? yes Free blocks count wrong for group #2044 (21880, counted=21923). Fix? yes Free blocks count wrong for group #2061 (22014, counted=22967). Fix? yes Free blocks count wrong (64428562, counted=64430104). Fix? yes Inode bitmap differences: -(32915521--32915552) -(33342497--33342560) -(33342625--33342944) -(33473281--33473312) -(33492289--33492320) -(33769505--33769632) Fix? yes Free inodes count wrong for group #2009 (13080, counted=13112). Fix? yes /dev/hdc1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/hdc1: ********** WARNING: Filesystem still has errors ********** /dev/hdc1: 939701/36634624 files (0.3% non-contiguous), 8812231/73242335 blocks [root at server /]# ================================================= Errors in messages: ================================================= Jul 20 04:09:13 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 20 04:09:13 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=526647391, high=31, low=6553695, sector=526647391 Jul 20 04:09:13 server kernel: end_request: I/O error, dev hdc, sector 526647391 Jul 20 04:09:13 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=32915539, block=65830916 Jul 20 04:09:13 server kernel: Aborting journal on device hdc1. Jul 20 04:09:13 server kernel: ext3_abort called. Jul 20 04:09:13 server kernel: EXT3-fs abort (device hdc1): ext3_journal_start: Detected aborted journal Jul 20 04:09:13 server kernel: Remounting filesystem read-only Jul 20 04:10:13 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }Jul 20 04:10:13 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=526647391, high=31, low=6553695, sector=526647391Jul 20 04:10:13 server kernel: end_request: I/O error, dev hdc, sector 526647391 Jul 20 04:10:13 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=32915521, block=65830916 Jul 20 04:10:29 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 20 04:10:29 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=531366999, high=31, low=11273303, sector=531366999 Jul 20 04:10:29 server kernel: end_request: I/O error, dev hdc, sector 531366999Jul 20 04:10:29 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=33214528, block=66420867 Jul 20 04:10:31 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 20 04:10:31 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=531366999, high=31, low=11273303, sector=531366999Jul 20 04:10:31 server kernel: end_request: I/O error, dev hdc, sector 531366999 Jul 20 04:10:31 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=33214497, block=66420867 Jul 20 04:10:39 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }Jul 20 04:10:39 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=533463199, high=31, low=13369503, sector=533463199 Jul 20 04:10:39 server kernel: end_request: I/O error, dev hdc, sector 533463199Jul 20 04:10:39 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=33341770, block=66682892 Jul 20 04:10:44 server kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }Jul 20 04:10:44 server kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=533463441, high=31, low=13369745, sector=533463439Jul 20 04:10:44 server kernel: end_request: I/O error, dev hdc, sector 533463439 Jul 20 04:10:44 server kernel: EXT3-fs error (device hdc1): ext3_get_inode_loc: unable to read inode block - inode=33342730, block=66682922 ================================================= Thanks in advance, Harvi From evilninja at gmx.net Thu Jul 22 23:45:07 2004 From: evilninja at gmx.net (evilninja) Date: Fri, 23 Jul 2004 01:45:07 +0200 Subject: Ext3 filesystem aborting journal at random times (Maxtor 300GB disk) In-Reply-To: <6B954A5C-DC2F-11D8-9F5F-000A958A3F2E@matharu.info> References: <6B954A5C-DC2F-11D8-9F5F-000A958A3F2E@matharu.info> Message-ID: <41005183.60505@gmx.net> Harvinder Matharu schrieb: > > Errors in messages: > > ================================================= > Jul 20 04:09:13 server kernel: hdc: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Jul 20 04:09:13 server kernel: hdc: dma_intr: error=0x40 { did you try to disable DMA? did it help? (man hdparm) Christian. -- BOFH excuse #108: The air conditioning water supply pipe ruptured over the machine room From adilger at clusterfs.com Fri Jul 23 01:17:51 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Thu, 22 Jul 2004 21:17:51 -0400 Subject: Ext3 filesystem aborting journal at random times (Maxtor 300GB disk) In-Reply-To: <6B954A5C-DC2F-11D8-9F5F-000A958A3F2E@matharu.info> References: <6B954A5C-DC2F-11D8-9F5F-000A958A3F2E@matharu.info> Message-ID: <20040723011751.GM1677@schnapps.adilger.int> On Jul 22, 2004 23:35 +0100, Harvinder Matharu wrote: > Jul 20 04:09:13 server kernel: hdc: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Jul 20 04:09:13 server kernel: hdc: dma_intr: error=0x40 { > UncorrectableError }, LBAsect=526647391, high=31, low=6553695, > sector=526647391 > Jul 20 04:09:13 server kernel: end_request: I/O error, dev hdc, sector > 526647391 > Jul 20 04:09:13 server kernel: EXT3-fs error (device hdc1): > ext3_get_inode_loc: unable to read inode block - inode=32915539, > block=65830916 > Jul 20 04:09:13 server kernel: Aborting journal on device hdc1. This is a hard disk error. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From calinb at comcast.net Fri Jul 30 01:46:41 2004 From: calinb at comcast.net (calinb at comcast.net) Date: Fri, 30 Jul 2004 01:46:41 +0000 Subject: Large File Copy to Large ext3 RAID5 Array Often Stalls Message-ID: <073020040146.25555.4109A8810002E666000063D322007623020D0207040E0C@comcast.net> I'm experiencing strange behavior from my ext3 RAID5 array and my Fedora Core 2 system. Before I go crazy varying all sorts of tuning parameters, I thought some list subscribers might provide me with useful advice. The problematic array is: 3x Promise Technology Ultra 100 TX2 PCI cards 6x Maxtor 250GB IDE drives (one drive per cable) RAID level 5, 128Kb chunk size, EXT3: "mkfs -t ext3 -b 4096 -m 0 -R stride=16 /dev/md2" I'm running Samba 3 and I first noticed this problem when 3 out of my 5 Windows clients (2 XP machines and 1 Server 2K3 machine) failed to copy any large files (~1GB) to a subdirectory on the server containing about 220 other such large files. Two XP machines on my network have no problems whatsoever copying large files to the very same subdirectory on the server. A failing file transfer begins at a reasonable data rate (~6 MB / sec) but grinds to a near standstill after about 30 seconds and the copy continues to crawl until I cancel it (maybe 10kB / second--just a rough guess.) The two well behaived clients transfer the 1GB files in about 2-3 minutes, as expected. Yup, Samba--that's what I thought at first so I tried FTP and obtained the same results. I can't correlate the problem to anything on the five Windows clients, or the NICs or the switch, etc. I can't find any configuration differences amongst the clients that correlates to the 3 failing or 2 fully functional clients. However, I can successfully copy the large files across the network from all 5 clients to an empty or nearly empty subdirectory on the raid5 array. Then I move the files down to the subdirectory as desired. That's my workaround for the 3 "bad" macines. (Yuck!) Now, here's what happens from the server console: if I copy a large file from a different drive (a mirror pair) on the server to the raid5 ext3 array, I have the same kind of problems that I have with the 3 networked clients. If I copy the large files from the mirror pair to an empty or nearly empty subdirectory on the raid5 ext3 filesystem, then the performance varies widely (from about 10MB /sec to 40 MB / sec.) I'd probably never notice this problem with smaller file (<100 - 200 MB or so) because the copy completes before the stall. The subdirectory containing the 220 1GB files was originally populated by copying the directory structure and files from one of the "good" XP Samba clients across the network. Any ideas or suggestions are greatly appreciated. I've tried data=journal, ordered, and writeback and, though there are performance differences, the problem remains in all three modes. Thanks, Cal Brabandt, Linux System Admin newbie From calinb at comcast.net Sat Jul 31 21:36:30 2004 From: calinb at comcast.net (Calin Brabandt) Date: Sat, 31 Jul 2004 14:36:30 -0700 Subject: Large File Copy to Large ext3 RAID5 Array Often Stalls In-Reply-To: <20040730202104.4845A73C6D@hormel.redhat.com> Message-ID: <001301c47746$718bcd20$0b00000a@WIDEBODY> Perhaps this IS a Samba problem. I created a new directory structure on my RAID5 array from the Linux console and move its contents of large files to the new subdirectory. Although I need to do more testing, the problem seem to have vanished--at least when copying new files from my network Samba clients to the new subdirectory. Much of the subdirectory structure on the RAID5 array was originally created using Windows Explorer on a Windows XP client by simply dragging and dropping the subdirectory icons to the Samba share on the RAID5. Could Samba have screwed up this operation in a manner resulting in my symptoms? I'd sure like to better understand the problem so I can avoid it in the future. Thanks, Cal From schwab at suse.de Sat Jul 24 15:02:12 2004 From: schwab at suse.de (Andreas Schwab) Date: Sat, 24 Jul 2004 17:02:12 +0200 Subject: ext[23]_rename do not update [cm]time of target directory Message-ID: POSIX says in : Upon successful completion, rename() shall mark for update the st_ctime and st_mtime fields of the parent directory of each file. ext[23]_rename fail to update st_[cm]time of the target directory if the target file already existed. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From zhenyu.z.wang at intel.com Mon Jul 26 02:43:51 2004 From: zhenyu.z.wang at intel.com (Wang, Zhenyu Z) Date: Mon, 26 Jul 2004 10:43:51 +0800 Subject: FW: IA64 test report: 2.6.8-rc1 /tiger 2004-7-20: Boot Hang! Message-ID: <6E0C289723A0564F9A8279E236E8565F07CFC5DA@pdsmsx402.pd.intel.com> Originally, the test is on a tiger with RHEL installed. The fs is ext3 as default. Then the oops came up. I've installed the test kernel on another tiger with Suse, reiserfs as default. The kernel can boot successfully without any trouble. Is it a known issue? Or what causes this happen? thanks, -zhen -----Original Message----- From: Wang, Zhenyu Z Sent: 2004?7?20? 16:59 To: linux-ia64 at vger.kernel.org Cc: linux-acpi Subject: IA64 test report: 2.6.8-rc1 /tiger 2004-7-20: Boot Hang! ACPI Test Report for 2.6 ia64 kernel ========================= Hardware Configuration: ----------------------- System Name: ACPI-Tiger System Type: 4 way 900 Itanium2, tiger M/B revision: N/A Processor version: N/A Firmware Versions: N/A I/O configuration summary: MPT scsi host driver Seagate ST318406LC boot drive IDE floppy and CDROM Serial console USB mouse USB keyboard Ethernet Pro 1000 Software Configuration: 1.Bk pull form lia64.bkbits.net/linux-ia64-2.5 on 7/20(Shanghai time) 2.bk pull from linux-acpi.bkbits.net/linux-acpi-test-2.6.8 on 7/20(Shanghai time) Kernel Config file: arch/ia64/defconfig ACPI Features Tested: (prioritized). -------------------- 1. Boot _fail_ 2. serial console 3. ATI (run X window system) 4. usb keyboard 5. USB mouse 6. NIC (eg. Ping or ftp) 7. IDE (eg. r/w floppy or CDROM) 8. SCI (eg. Press power button) 9. Soft Power off Linux version 2.6.8-rc1 (root at acpi-tiger) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)) #1 SMP Tue Jul 20 15:52:29 CST 2004 EFI v1.10 by INTEL: SALsystab=0x3fe4c8c0 ACPI=0x3ff84000 ACPI 2.0=0x3ff83000 MPS=0x3ff82000 SMBIOS=0xf0000 ACPI: RSDP (v002 INTEL ) @ 0x000000003ff83000 ACPI: XSDT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x000000003ff83090 ACPI: FADT (v003 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x000000003ff83138 ACPI: MADT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x000000003ff83230 ACPI: DSDT (v001 Intel SR870BN4 0x00000000 MSFT 0x0100000d) @ 0x0000000000000000 efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0 efi.trim_top: ignoring 24KB of memory at 0x1000 due to granule hole at 0x0 efi.trim_top: ignoring 8KB of memory at 0x7000 due to granule hole at 0x0 efi.trim_top: ignoring 484KB of memory at 0x9000 due to granule hole at 0x0 efi.trim_top: ignoring 4KB of memory at 0x84000 due to granule hole at 0x0 efi.trim_top: ignoring 108KB of memory at 0x85000 due to granule hole at 0x0 efi.trim_bottom: ignoring 15360KB of memory at 0x100000 due to granule hole at 0x0 SAL 3.1: Intel Corp SR870BN4 version 3.0 SAL Platform features: BusLock IRQ_Redirection SAL: AP wakeup using external interrupt vector 0xf0 iosapic_system_init: Disabling PC-AT compatible 8259 interrupts ACPI: Local APIC address 0xc0000000fee00000 PLATFORM int CPEI (0x3): GSI 22 (level, low) -> CPU 0 (0xc218) vector 30 register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level 4 CPUs available, 4 CPUs total Registering legacy COM ports for serial console MCA related initialization done On node 0 totalpages: 64121 DMA zone: 64121 pages, LIFO batch:4 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: BOOT_IMAGE=scsi0:?EFI?redhat?vmlinux.26 root=/dev/sda2 console=ttyS1,9600n8 console=tty0 ro PID hash table entries: 2048 (order 11: 32768 bytes) CPU 0: base freq=199.458MHz, ITC ratio=14/2, ITC freq=1396.209MHz+/--1ppm Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 6, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 5, 524288 bytes) Memory: 1008192k/1025936k available (7281k code, 17360k reserved, 3306k data, 208k init) McKinley Errata 9 workaround not needed; disabling it Calibrating delay loop... 2089.76 BogoMIPS Mount-cache hash table entries: 1024 (order: 0, 16384 bytes) Boot processor id 0x0/0xc218 task migration cache decay timeout: 10 msecs. CPU 1: synchronized ITC with CPU 0 (last diff -1 cycles, maxerr 513 cycles) CPU 1: base freq=199.458MHz, ITC ratio=14/2, ITC freq=1396.209MHz+/--1ppm Calibrating delay loop... 2089.76 BogoMIPS CPU 2: synchronized ITC with CPU 0 (last diff -1 cycles, maxerr 513 cycles) CPU 2: base freq=199.458MHz, ITC ratio=14/2, ITC freq=1396.209MHz+/--1ppm Calibrating delay loop... 2089.76 BogoMIPS CPU 3: synchronized ITC with CPU 0 (last diff -1 cycles, maxerr 513 cycles) CPU 3: base freq=199.458MHz, ITC ratio=14/2, ITC freq=1396.209MHz+/--1ppm Calibrating delay loop... 2089.76 BogoMIPS Brought up 4 CPUs Total of 4 processors activated (8359.04 BogoMIPS). NET: Registered protocol family 16 ACPI: Subsystem revision 20040715 ACPI: Interpreter enabled ACPI: Using IOSAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 ACPI: PCI Root Bridge [PCI1] (00:02) ACPI: PCI Root Bridge [PCI3] (00:09) ACPI: PCI Root Bridge [PCI4] (00:0f) ACPI: Device [CSFF] status [00000008]: functional but not present; setting present ACPI: PCI Root Bridge [CSFF] (00:ff) SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing GSI 16 (level, low) -> CPU 2 (0xc418) vector 48 ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 48 GSI 19 (level, low) -> CPU 2 (0xc418) vector 49 ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 49 GSI 23 (level, low) -> CPU 2 (0xc418) vector 50 ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 50 ACPI: PCI interrupt 0000:00:1f.1[A]: no GSI GSI 18 (level, low) -> CPU 2 (0xc418) vector 51 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 51 GSI 71 (level, low) -> CPU 2 (0xc418) vector 52 ACPI: PCI interrupt 0000:03:1f.0[A] -> GSI 71 (level, low) -> IRQ 52 GSI 28 (level, low) -> CPU 2 (0xc418) vector 53 ACPI: PCI interrupt 0000:06:02.0[A] -> GSI 28 (level, low) -> IRQ 53 GSI 29 (level, low) -> CPU 2 (0xc418) vector 54 ACPI: PCI interrupt 0000:06:02.1[B] -> GSI 29 (level, low) -> IRQ 54 GSI 47 (level, low) -> CPU 2 (0xc418) vector 55 ACPI: PCI interrupt 0000:06:1f.0[A] -> GSI 47 (level, low) -> IRQ 55 GSI 119 (level, low) -> CPU 2 (0xc418) vector 56 ACPI: PCI interrupt 0000:0a:1f.0[A] -> GSI 119 (level, low) -> IRQ 56 GSI 95 (level, low) -> CPU 2 (0xc418) vector 57 ACPI: PCI interrupt 0000:0c:1f.0[A] -> GSI 95 (level, low) -> IRQ 57 GSI 167 (level, low) -> CPU 2 (0xc418) vector 58 ACPI: PCI interrupt 0000:10:1f.0[A] -> GSI 167 (level, low) -> IRQ 58 GSI 120 (level, low) -> CPU 2 (0xc418) vector 59 ACPI: PCI interrupt 0000:12:01.0[A] -> GSI 120 (level, low) -> IRQ 59 GSI 143 (level, low) -> CPU 2 (0xc418) vector 60 ACPI: PCI interrupt 0000:12:1f.0[A] -> GSI 143 (level, low) -> IRQ 60 perfmon: version 2.0 IRQ 238 perfmon: Itanium 2 PMU detected, 16 PMCs, 18 PMDs, 4 counters (47 bits) PAL Information Facility v0.5 perfmon: added sampling format default_format perfmon_default_smpl: default_format v2.0 registered Total HugeTLB memory allocated, 0 Installing knfsd (copyright (C) 1996 okir at monad.swb.de). udf: registering filesystem Initializing Cryptographic API ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU0] (supports C1) ACPI: Processor [CPU1] (supports C1) ACPI: Processor [CPU2] (supports C1) ACPI: Processor [CPU3] (supports C1) EFI Time Services Driver v0.4 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled acpi_serial_port: zero-length IO port range? ttyS0 at I/O 0x3f8 (irq = 44) is a 16550A acpi_serial_port: zero-length IO port range? ttyS1 at I/O 0x2f8 (irq = 45) is a 16550A RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Intel(R) PRO/1000 Network Driver - version 5.2.52-k4 Copyright (c) 1999-2004 Intel Corporation. ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 51 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection ACPI: PCI interrupt 0000:12:01.0[A] -> GSI 120 (level, low) -> IRQ 59 e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection Ethernet Channel Bonding Driver: v2.6.0 (January 14, 2004) bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx st: Version 20040403, fixed bufsize 32768, s/g segs 256 osst :I: Tape driver with OnStream support version 0.99.1 osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $ Fusion MPT base driver 3.01.09 Copyright (c) 1999-2004 LSI Logic Corporation ACPI: PCI interrupt 0000:06:02.0[A] -> GSI 28 (level, low) -> IRQ 53 mptbase: Initiating ioc0 bringup ioc0: 53C1030: Capabilities={Initiator} ACPI: PCI interrupt 0000:06:02.1[B] -> GSI 29 (level, low) -> IRQ 54 mptbase: Initiating ioc1 bringup ioc1: 53C1030: Capabilities={Initiator} Fusion MPT SCSI Host driver 3.01.09 scsi0 : ioc0: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=255, IRQ=53 Using anticipatory io scheduler Vendor: SEAGATE Model: ST318406LC Rev: 8A03 Type: Direct-Access ANSI SCSI revision: 03 SCSI device sda: 35566478 512-byte hdwr sectors (18210 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 Vendor: ESG-SHV Model: SCA HSBP M17 Rev: 0101 Type: Processor ANSI SCSI revision: 02 Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0, type 3 scsi1 : ioc1: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=255, IRQ=54 ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 50 ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller ehci_hcd 0000:00:1d.7: irq 50, pci mem c0000000f9ff0000 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 PCI: slot 0000:00:1d.7 has incorrect PCI cache line size of 0 bytes, correcting to 128 ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 48 uhci_hcd 0000:00:1d.0: Intel Corp. 82801DB (ICH4) USB UHCI #1 uhci_hcd 0000:00:1d.0: irq 48, io base 0000000000004cc0 uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 49 uhci_hcd 0000:00:1d.1: Intel Corp. 82801DB (ICH4) USB UHCI #2 uhci_hcd 0000:00:1d.1: irq 49, io base 0000000000004ce0 uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice EFI Variables Facility v0.08 2004-May-17 NET: Registered protocol family 2 IP: routing cache hash table of 16384 buckets, 256Kbytes TCP: Hash tables configured (established 131072 bind 65536) arp_tables: (C) 2002 David S. Miller NET: Registered protocol family 1 usb 3-1: new full speed USB device using address 2 hub 3-1:1.0: USB hub found hub 3-1:1.0: 7 ports detected NET: Registered protocol family 17 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesy>tem) r1.1:only. owFspeid UuBudedike uelnm addre 208kB fhelper[221]: Unsupported data reference 8821862825984 [1] Modules linked in: Pid: 221, CPU 3, comm: khelper psr : 00001010085a2010 ifs : 8000000000000813 ip : [] Not tainted ip is at sba_alloc_range+0x50/0x1280 unat: 0000000000000000 pfs : 0000000000000814 rsc : 0000000000000003 rnat: 0000000000000000 bsps: 0000000000000000 pr : 0000000000065995 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a000000100600f80 b6 : a000000100308d00 b7 : a00000010055e3a0 f6 : 1003e6db6db6db6db6db7 f7 : 1003e000000000000f763 f8 : 100059dfff62000000000 f9 : 1003e000000000006c3b5 f10 : 1003e0000000000001212 f11 : 1003e0000000000007e7e r1 : a000000100c3e560 r2 : e000000004848000 r3 : 0000000000001212 r8 : 0000000000000000 r9 : 0000000000000000 r10 : a000000100a57e48 r11 : 0000000000000040 r12 : e00000003cfd7510 r13 : e00000003cfd0000 r14 : e000000001118000 r15 : 0000000000000040 r16 : e00000003cff8000 r17 : 0000000000001000 r18 : e000000004849000 r19 : 0000000000001000 r20 : e00000003dd99000 r21 : e00000000177af40 r22 : 0000000000000000 r23 : a000000100a7fce8 r24 : 0000000000000000 r25 : e00000003dd98fff r26 : e00000000177af58 r27 : 0000000000000000 r28 : a0000001005fed20 r29 : e00000003dd98fff r30 : 0000000000000001 r31 : 0000000000000038 Call Trace: [] show_stack+0x80/0xa0 sp=e00000003cfd7070 bsp=e00000003cfd1b10 [] die+0x1d0/0x280 sp=e00000003cfd7240 bsp=e00000003cfd1ae8 [] ia64_fault+0x180/0xcc0 sp=e00000003cfd7240 bsp=e00000003cfd1aa8 [] ia64_leave_kernel+0x0/0x260 sp=e00000003cfd7340 bsp=e00000003cfd1aa8 [] sba_alloc_range+0x50/0x1280 sp=e00000003cfd7510 bsp=e00000003cfd1a10 [] sba_map_sg+0x380/0x740 sp=e00000003cfd7510 bsp=e00000003cfd1988 [] mptscsih_AddSGE+0xf0/0x740 sp=e00000003cfd7520 bsp=e00000003cfd1910 [] mptscsih_qcmd+0x630/0xba0 sp=e00000003cfd7530 bsp=e00000003cfd18a8 [] scsi_dispatch_cmd+0x480/0x6a0 sp=e00000003cfd7530 bsp=e00000003cfd1870 [] scsi_request_fn+0x5a0/0xac0 sp=e00000003cfd7540 bsp=e00000003cfd1750 [] __generic_unplug_device+0xc0/0xe0 sp=e00000003cfd7540 bsp=e00000003cfd1730 [] generic_unplug_device+0x80/0xe0 sp=e00000003cfd7540 bsp=e00000003cfd1710 [] blk_backing_dev_unplug+0x90/0xa0 sp=e00000003cfd7540 bsp=e00000003cfd16f0 [] sync_buffer+0x100/0x120 sp=e00000003cfd7540 bsp=e00000003cfd16d8 [] __wait_on_buffer+0x1e0/0x200 sp=e00000003cfd7540 bsp=e00000003cfd16b0 [] __bread_slow+0x150/0x1a0 sp=e00000003cfd75a0 bsp=e00000003cfd1690 [] __bread+0x60/0x80 sp=e00000003cfd75a0 bsp=e00000003cfd1668 [] ext3_get_branch+0xc0/0x2a0 sp=e00000003cfd75a0 bsp=e00000003cfd1620 [] ext3_get_block_handle+0xc0/0x6a0 sp=e00000003cfd75a0 bsp=e00000003cfd1588 [] do_mpage_readpage+0x650/0x680 sp=e00000003cfd7620 bsp=e00000003cfd14e0 [] mpage_readpages+0x130/0x2a0 sp=e00000003cfd7780 bsp=e00000003cfd1478 [] ext3_readpages+0x30/0x60 sp=e00000003cfd7820 bsp=e00000003cfd1448 [] read_pages+0x280/0x2a0 sp=e00000003cfd7820 bsp=e00000003cfd13d0 [] do_page_cache_readahead+0x210/0x440 sp=e00000003cfd78b0 bsp=e00000003cfd1350 [] page_cache_readahead+0x160/0x520 sp=e00000003cfd78c0 bsp=e00000003cfd1300 [] do_generic_mapping_read+0x1a0/0x800 sp=e00000003cfd78c0 bsp=e00000003cfd1258 [] __generic_file_aio_read+0x370/0x400 sp=e00000003cfd7920 bsp=e00000003cfd11e8 [] generic_file_aio_read+0x60/0xc0 sp=e00000003cfd7940 bsp=e00000003cfd11b8 [] do_sync_read+0x110/0x160 sp=e00000003cfd7950 bsp=e00000003cfd1178 [] vfs_read+0x210/0x2c0 sp=e00000003cfd79d0 bsp=e00000003cfd1130 [] kernel_read+0x60/0xa0 sp=e00000003cfd79d0 bsp=e00000003cfd10f8 [] load_script+0x550/0x580 sp=e00000003cfd79e0 bsp=e00000003cfd10b8 [] search_binary_handler+0x400/0x7a0 sp=e00000003cfd7a70 bsp=e00000003cfd1038 [] do_execve+0x340/0x3e0 sp=e00000003cfd7a70 bsp=e00000003cfd0fc8 [] sys_execve+0x90/0xe0 sp=e00000003cfd7c60 bsp=e00000003cfd0f58 [] ia64_execve+0x30/0x160 sp=e00000003cfd7c60 bsp=e00000003cfd0f30 [] ia64_ret_from_syscall+0x0/0x20 sp=e00000003cfd7c60 bsp=e00000003cfd0f30 [] execve+0x0/0x20 sp=e00000003cfd7e30 bsp=e00000003cfd0f30 [] ____call_usermodehelper+0x160/0x1a0 sp=e00000003cfd7e30 bsp=e00000003cfd0f18 [] kernel_thread_helper+0xe0/0x100 sp=e00000003cfd7e30 bsp=e00000003cfd0ef0 [] start_kernel_thread+0x20/0x40 sp=e00000003cfd7e30 bsp=e00000003cfd0ef0