LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-13-2009, 06:29 AM   #31
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,035

Rep: Reputation: 149Reputation: 149

Quote:
Originally Posted by H_TeXMeX_H View Post
I say if that is the case try a different filesystem, it may be related to ext3. It seems other filesystems have less of an issue with this. ext4 also counts as possible solution.
Based on the Kernel Bugzilla thread and my own experiences, I'm not so sure about that. Just yesterday I was copying files from an ext partition to an XFS one (and later to another encrypted ext3). Strangely, the slowest write was the one on XFS (~900 MB single file in ~4 minutes, and it slowed the system considerably). Later I copied another 750 MB at around 2 minutes however, and the writes on the encrypted ext3 were certainly faster. I suppose the fsync is relevant to disk writes, not reads, so this may give some information on the ext3 and XFS performances. On the other hand this wasn't a perfectly controlled experiment. Still, the people who tested 2.6.17 and the later ones (and found a difference) used the same partitions, so at least for them, there must be a kernel element in the bug.

Actually I do have an unencrypted ext3 Slamd64 partition. Maybe next time I reboot, I'll check to see if I have the same problem there.
 
Old 03-13-2009, 08:40 AM   #32
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Well, as there is no known solution, try as many things as you can, maybe you'll find at least a temporary solution.
 
Old 03-14-2009, 01:02 PM   #33
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
My Firefox 3.0.4 starts in less than 2 seconds cold on a slow box (E2200). Funny thing is, I have the problems ErV mentions on FreeBSD on a fast fox. Have tried every idea people gave me and nothing helped. Only thing is after they start once they generally start alot faster the next time.

EXT3 is slow, no question. I am running everything JFS (here and on my Slamd64 box) except for a small boot which is EXT3. I think TexMex may be onto something. I think the FreeBSD filesystem is also a bottleneck.
 
Old 03-16-2009, 03:40 PM   #34
adriv
Member
 
Registered: Nov 2005
Location: Diessen, The Netherlands
Distribution: Slackware 14.2 & -current
Posts: 692

Rep: Reputation: 40
I agree, ext3 is slow, tried it once, never liked it.
Go for JFS, with a bit of luck, the kernel bug won't rear it's ugly head.
You've got little to loose...
 
Old 03-17-2009, 08:17 AM   #35
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
Well actually you could get burned. None of the other journaling filesystems offer data consistency, only metadata consistency. You have to tune EXT3 to do that, but it sure works well. It is sloooow. I already had a file totally fried using JFS. I continue to use JFS, but it's not perfect.
 
Old 03-17-2009, 02:06 PM   #36
ErV
Senior Member
 
Registered: Mar 2007
Location: Russia
Distribution: Slackware 12.2
Posts: 1,202

Original Poster
Blog Entries: 3

Rep: Reputation: 62
I am temporarily abandoning this problem.
I can't spend time playing around with grub right now, and it is unclear when I'll be able to try another bootloader (honestly, I simply don't like idea of replacing bootloader for now). Also system-wide profiling isn't guaranteed to provide useful results, since OProfile indicates that only 30% of time is spent within kernel - so I won't get more than 30% improvement even if there is a bottleneck that can be fixed..
Thanks for everyone who posted a reply. If I ever find a solution, I'll post it here.
 
Old 03-17-2009, 05:39 PM   #37
adriv
Member
 
Registered: Nov 2005
Location: Diessen, The Netherlands
Distribution: Slackware 14.2 & -current
Posts: 692

Rep: Reputation: 40
Quote:
Originally Posted by Randux View Post
I continue to use JFS, but it's not perfect.
Neither is ext3.
 
Old 03-28-2009, 01:38 PM   #38
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,035

Rep: Reputation: 149Reputation: 149
Hi all,

Here is an update on the status of the kernel bug I've mentioned. I noticed a suggestion in Bugzilla, taken from a LKML post about this problem. Well, there are two suggestions actually: First, mounting ext3 with "data=writeback" option, instead of the default "ordered" mode. Using the "sync" option was also suggested and some people report improvement with this. The other idea is making the kjournald process "nicer" by a command like:

Code:
for i in `pidof kjournald` ; do ionice -c1 -p $i ; done
From these suggestions I tried the kjounald method (I put it in my rc.local), and also upgraded my kernel to 2.6.29. Since I did these simultaneously I can't tell which one has been more effective, but the responsiveness of my system during large file copies has increased noticeably.

Last edited by Ilgar; 03-28-2009 at 07:51 PM.
 
Old 03-28-2009, 01:48 PM   #39
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Be careful, using 'data=writeback' increases the chances of data loss should the system go down. See here:
http://www.linuxquestions.org/questi...rounds-712905/

Basically, ext4 exhibits this behavior by default. Linus is not happy about it.
 
Old 03-28-2009, 02:44 PM   #40
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,035

Rep: Reputation: 149Reputation: 149
Oh yes I forgot to mention that. Not a very serious risk, but if you want to be absolutely safe, stay with the default...
 
Old 03-29-2009, 02:04 AM   #41
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
There is btrfs with 2.6.29
 
Old 03-29-2009, 04:13 AM   #42
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,035

Rep: Reputation: 149Reputation: 149
Btrfs is experimental yet, even the disk format hasn't stabilized.
 
Old 03-29-2009, 04:15 AM   #43
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Quote:
Originally Posted by Ilgar View Post
Btrfs is experimental yet, even the disk format hasn't stabilized.
Come on, what could go wrong ?
 
Old 03-29-2009, 08:06 AM   #44
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
It (disk format) won't be changed.
 
Old 03-29-2009, 10:43 AM   #45
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,035

Rep: Reputation: 149Reputation: 149
Quote:
Originally Posted by Alien_Hominid View Post
It (disk format) won't be changed.
Code:
 

.config - Linux Kernel v2.6.29 Configuration
 
 Btrfs filesystem (EXPERIMENTAL) Unstable disk format  

CONFIG_BTRFS_FS:                                                                                     
Btrfs is a new filesystem with extents, writable snapshotting, support for multiple devices and many more features.  

Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED.  You should say N here unless you are interested in testing Btrfs with non-critical data.
PS: The capitalization is not mine .
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenOffice 2.0 is very slow to launch tongliu8 Linux - Software 24 12-24-2010 12:13 PM
fix: launch media player keyboard shortcut tutwabee Ubuntu 0 04-22-2006 04:33 PM
Slow OOo launch in Mandriva SE JerryP Mandriva 3 06-06-2005 06:26 PM
Slow name resolving _and_ slow konsole launch dangerbaby Mandriva 7 03-03-2005 06:11 AM
just to share acroread UTF-8 error launch fix. demmylls Linux - General 1 04-07-2004 05:34 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:26 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration