Ever since I started using ext3fs, whenever there is a disk write, the
kernel sucks up all of the CPU thereby preempting everything and causing
the PC to freeze momentarily. Could this possibly be caused by the
journaling code in ext3?
-Erik
On Sat, Dec 01, 2001 at 12:47:19AM -0600, Erik Elmore wrote:
> Ever since I started using ext3fs, whenever there is a disk write, the
> kernel sucks up all of the CPU thereby preempting everything and causing
> the PC to freeze momentarily. Could this possibly be caused by the
> journaling code in ext3?
>
You really need to give kernel version, gcc version and what things were
happening at the time.
I can think of five different things that this general description has
brought up.
mf
ahhhh... woops... every official kernel since ext3 made it into the
official tree, 2.4.14 if memory serves. I'm using gcc 2.95.3. And to
clarify the bug, say on a large disk write, the pause isn't constant,
it just pauses for a second every few seconds during the write. For
smaller writes, it will pause only once, I assume while performing the
actual write to disk.
Erik
On Fri, 30 Nov 2001, Mike Fedyk wrote:
> On Sat, Dec 01, 2001 at 12:47:19AM -0600, Erik Elmore wrote:
> > Ever since I started using ext3fs, whenever there is a disk write, the
> > kernel sucks up all of the CPU thereby preempting everything and causing
> > the PC to freeze momentarily. Could this possibly be caused by the
> > journaling code in ext3?
> >
>
> You really need to give kernel version, gcc version and what things were
> happening at the time.
>
> I can think of five different things that this general description has
> brought up.
>
> mf
>
Erik Elmore wrote:
>
> ahhhh... woops... every official kernel since ext3 made it into the
> official tree, 2.4.14 if memory serves. I'm using gcc 2.95.3. And to
> clarify the bug, say on a large disk write, the pause isn't constant,
> it just pauses for a second every few seconds during the write. For
> smaller writes, it will pause only once, I assume while performing the
> actual write to disk.
>
I've seen a couple of reports where ext3 appears to exacerbate
the effects of poor hdparm settings. What is your raw disk
throughput, from `hdparm -t /dev/hda'?
In article <[email protected]> you wrote:
> And to
> clarify the bug, say on a large disk write, the pause isn't constant,
You should elaborate more on the type of disks writes. Is this a write to a
single large file, a rename/delte of a large tree, ot generating of a lot of
files. Cause there is a difference in the meta data and data handling. both
where known to take too much time in different versions.
Greetings
Bernd
> I've seen a couple of reports where ext3 appears to exacerbate
> the effects of poor hdparm settings. What is your raw disk
> throughput, from `hdparm -t /dev/hda'?
`hdparm -t /dev/hda` reports:
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 16.76 seconds = 3.82 MB/sec
Erik
> You should elaborate more on the type of disks writes. Is this a write to a
> single large file, a rename/delte of a large tree, ot generating of a lot of
> files. Cause there is a difference in the meta data and data handling. both
> where known to take too much time in different versions.
It appears when writing a single large file such as downloading or copying
a file, and also when I copy a large number of smaller files at once. I
have noticed no performance hits when renaming or deleting a large number
of files at once.
Erik
in other mail I asked Erik about the disk's mode: it is PIO,
so the pathetic speed and crippling VM/Ext2 performance is
entirely expected. I'm guessing he's missing CONFIGs of either
the chipset-specific driver or one of:
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
> > I've seen a couple of reports where ext3 appears to exacerbate
> > the effects of poor hdparm settings. What is your raw disk
> > throughput, from `hdparm -t /dev/hda'?
>
> `hdparm -t /dev/hda` reports:
>
> # hdparm -t /dev/hda
>
> /dev/hda:
> Timing buffered disk reads: 64 MB in 16.76 seconds = 3.82 MB/sec
Hi ..
I have to say, I had it too .. on my IBook2
On Sun, Dec 02, 2001 at 02:55:04PM +0100, Bernd Eckenfels wrote:
>In article <[email protected]> you wrote:
>> And to
>> clarify the bug, say on a large disk write, the pause isn't constant,
>You should elaborate more on the type of disks writes. Is this a write to a
>single large file, a rename/delte of a large tree, ot generating of a lot of
>files. Cause there is a difference in the meta data and data handling. both
>where known to take too much time in different versions.
at me ..
I kompiled a Ben0 Kernel with ext3 support and then I made tune2fs to
convert ext2 to ext3 partitions by making a .journal - file!
After 45 min after the reboot the ext3 system, the IBook freezes at havy
disk/IO (an untar at OpenOffice source , tar.gz 100MB, Sourcetree
550MB).
The IBook freezed and I reseted it .. but I had to install the whole
system .. the yaboot wasn't able to find a kernel on the / Partition.
(ext3 too) :)
Regards
Jan
>Greetings
>Bernd
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
--
One time, you all will be emulated by linux!
----
Jan- Hendrik Palic
Url:"http://www.billgotchy.de"
E-Mail: "[email protected]"
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w---
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++
G+++ e+++ h+ r++ z+
------END GEEK CODE BLOCK------
A Diumenge 02 Desembre 2001 19:15, Mark Hahn va escriure:
> in other mail I asked Erik about the disk's mode: it is PIO,
> so the pathetic speed and crippling VM/Ext2 performance is
> entirely expected. I'm guessing he's missing CONFIGs of either
> the chipset-specific driver or one of:
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_BLK_DEV_ADMA=y
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_IDEDMA_AUTO=y
>
> > > I've seen a couple of reports where ext3 appears to exacerbate
> > > the effects of poor hdparm settings. What is your raw disk
> > > throughput, from `hdparm -t /dev/hda'?
> >
> > `hdparm -t /dev/hda` reports:
> >
> > # hdparm -t /dev/hda
> >
> > /dev/hda:
> > Timing buffered disk reads: 64 MB in 16.76 seconds = 3.82 MB/sec
maybe the only thing he is missing is the *AUTO configs
you could try:
# /sbin/hdparm -c 1 -d 1 /dev/hda
which tries to do this:
/dev/hda:
setting 32-bit I/O support flag to 1
setting using_dma to 1 (on)
and then test again with -t to see if it gets better...
Jan-Hendrik Palic wrote:
>
> The IBook freezed and I reseted it .. but I had to install the whole
> system .. the yaboot wasn't able to find a kernel on the / Partition.
> (ext3 too) :)
>
An unrecovered ext3 filesystem is probably unrecognisable to
yaboot. I'm told that yaboot 1.3.5 and later have changes which
permit booting from unrecovered ext3 filesystems.
heh, that makes sense, if I want my hardware to work right, then I need to
build the damn driver. I added in the support and tweaked my startup
scripts and not only did that pause go away, my throughput has improved as
well. Thanks guys.
Erik
Hi ...
On Mon, Dec 03, 2001 at 04:17:44PM -0800, Andrew Morton wrote:
>> The IBook freezed and I reseted it .. but I had to install the whole
>> system .. the yaboot wasn't able to find a kernel on the / Partition.
>> (ext3 too) :)
>An unrecovered ext3 filesystem is probably unrecognisable to
>yaboot. I'm told that yaboot 1.3.5 and later have changes which
>permit booting from unrecovered ext3 filesystems.
hmmm ok ... thnx ... :)
But the IBook freezed with the 2.4.15-ben0 on haevy harddisk/IO ....
what could it be?
Best regards!
Jan
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
--
One time, you all will be emulated by linux!
----
Jan- Hendrik Palic
Url:"http://www.billgotchy.de"
E-Mail: "[email protected]"
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w---
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++
G+++ e+++ h+ r++ z+
------END GEEK CODE BLOCK------
On Tue, Dec 04, 2001 at 10:53:19PM +0100, Jan-Hendrik Palic wrote:
> Hi ...
>
> On Mon, Dec 03, 2001 at 04:17:44PM -0800, Andrew Morton wrote:
> >> The IBook freezed and I reseted it .. but I had to install the whole
> >> system .. the yaboot wasn't able to find a kernel on the / Partition.
> >> (ext3 too) :)
> >An unrecovered ext3 filesystem is probably unrecognisable to
> >yaboot. I'm told that yaboot 1.3.5 and later have changes which
> >permit booting from unrecovered ext3 filesystems.
>
> hmmm ok ... thnx ... :)
>
> But the IBook freezed with the 2.4.15-ben0 on haevy harddisk/IO ....
>
> what could it be?
>
I would suggest you try another ben0, or use a kernel available from the bk
repositories.
Check out http://www.penguinppc.org/
mf