View previous topic :: View next topic |
Author |
Message |
enderandrew l33t
Joined: 25 Oct 2005 Posts: 731
|
Posted: Tue Jun 27, 2006 7:39 am Post subject: |
|
|
I want to throw things right now.
I normally use Reiser4 all day long on all my boxes. I keep hearing the ext3 is more stable, and offers just as good performance when properly configured.
My first two boxes I put ext3 on, I had crashes and lost data within 2 weeks.
So I decided to go ahead on give ext3 one more try.
Brand new install. I just spent 4 days compiling everything. Now it won't boot, and it says /dev/root is corrupted. the fschk program spots the errors, attempts to fix them, but doesn't do any good. I know I am probably the exception to the rule, but 3 times out of 3, ext3 has taken a crap on me within 2 weeks of using it. I've never lost data with reiser4.
I'm *really* hoping I don't have to format and start over again, because my free time is next to nonexistant these days, but I thought ext3 was supposed to be absolutely stable as a rock. _________________ Nihilism makes me smile. |
|
Back to top |
|
|
Doogman Apprentice
Joined: 24 Sep 2004 Posts: 242
|
Posted: Tue Jun 27, 2006 8:05 pm Post subject: |
|
|
More info:
doug@ghidorah ~ $ uname -a
Linux ghidorah 2.6.16-ck12n #2 SMP Sat Jun 24 12:34:26 EDT 2006 i686 Dual Core AMD Opteron(tm) Processor 175 GNU/Linux
I seem to be having the same slow-write problem with a box running 2.6.16-gentoo-r7. I would like to see some other people's benchmarks! Bonnie++ isn't that hard to run.
Question enderandrew... why move from Reiser when you weren't having problems?
Obviously people who use ext3 don't have to reformat partitions every other week as I think you would see some red flags raised somewhere.
<Testimonial> I've been using ext3 since it's inception and my filesystems survived numerious hard crashes and such while trying out new kernels and hardware. Heck, my last system had a hardware problem that when the MB had high IO it would occasionally corrupt the disk writes. Nice. Even so, I never lost a filesystem and in fact only noticied it when I seen the errors corrected during the monthly fsck. Moving to a Tyan K8E fixed all those problems. </Testimonial> |
|
Back to top |
|
|
enderandrew l33t
Joined: 25 Oct 2005 Posts: 731
|
Posted: Wed Jun 28, 2006 5:12 am Post subject: |
|
|
I was doing new installs on two more laptops. _________________ Nihilism makes me smile. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Jul 03, 2006 8:35 pm Post subject: |
|
|
PaulBredbury wrote: | Here's another ext3 performance tip: Upgrade to kernel 2.6.17 |
not really, just see these comparisons I made using bonnie++:
Code: |
Version 1.93c ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
2.6.15-r8 1800M 331 99 97570 39 73378 25 844 98 253583 47 2728 36
2.6.17-r1 1800M 304 99 96719 35 61476 16 777 97 184444 22 2490 28
|
These are done using a dual boot install of 2.6.15-r8 and 2.6.17-r1 on the same ext3 filesystem which resides on nvraid, RAID0 using the same bonnie package and same kernel config (make oldconfig using 2.6.15-r8 .config in 2.6.17-r1). Seq rewrite and read rates have fallen by as much as 15-25%. Rewrite may have suffered because of reduced seq. read performance. Upgrades are not always what they are made out to be. |
|
Back to top |
|
|
darklegion Guru
Joined: 14 Nov 2004 Posts: 468
|
Posted: Thu Jul 06, 2006 5:05 am Post subject: |
|
|
devsk wrote: | PaulBredbury wrote: | Here's another ext3 performance tip: Upgrade to kernel 2.6.17 |
not really, just see these comparisons I made using bonnie++:
Code: |
Version 1.93c ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
2.6.15-r8 1800M 331 99 97570 39 73378 25 844 98 253583 47 2728 36
2.6.17-r1 1800M 304 99 96719 35 61476 16 777 97 184444 22 2490 28
|
These are done using a dual boot install of 2.6.15-r8 and 2.6.17-r1 on the same ext3 filesystem which resides on nvraid, RAID0 using the same bonnie package and same kernel config (make oldconfig using 2.6.15-r8 .config in 2.6.17-r1). Seq rewrite and read rates have fallen by as much as 15-25%. Rewrite may have suffered because of reduced seq. read performance. Upgrades are not always what they are made out to be. |
Did you enable "CONFIG_ADAPTIVE_READAHEAD" while doing "make oldconfig"?. I think this option is needed to get the performance increase (I haven't tested the kernel as of yet). |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Thu Jul 06, 2006 5:59 am Post subject: |
|
|
where does this config parameter lie? I can't find it.
PS: I found out why its not there. Its in a patch for mm kernel, which is not present in the latest gentoo-sources (at least that string CONFIG_ADAPTIVE doesn't figure in any of files under /usr/src/linux) that I am running. But the poster (and the link he posted) actually said it was in mainline kernel. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Fri Jul 07, 2006 3:18 pm Post subject: |
|
|
if it makes anybody happy knowing that they are not missing out on holy-grail, here it is:
Code: |
Version 1.93c ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
van-2.6.17 1800M 356 98 33834 13 28018 18 934 90 64460 23 186.2 6
mm6-2.6.17 1800M 495 98 33363 11 25761 13 1238 93 64946 18 276.4 13
|
no gains for adaptive readahead in mm6...
Both tests done under a VM using same install with dual boot setup. |
|
Back to top |
|
|
Sedrik l33t
Joined: 08 Apr 2005 Posts: 655 Location: Uppsala, Sweden
|
Posted: Wed Aug 02, 2006 8:37 am Post subject: |
|
|
How much improvement can one expect these tweaks(full journaling, indexing) to give?
Is it like 0.5% increase? more? less?
I'm a ext3 user already, have been since my friend pointed me to a post somewhere pointing out the faults of reiserfs (which I used before since it was the popular chooice).
Nice guide =)
*Edit
Please continue to add more tweaks and safe modes to run to the first post as time goes by =) _________________ From Gentoo with love |
|
Back to top |
|
|
Sachankara l33t
Joined: 11 Jun 2004 Posts: 696 Location: Stockholm, Sweden
|
Posted: Wed Aug 02, 2006 6:12 pm Post subject: |
|
|
Full journaling on Ext3 decreases the performance. People should try running with the default to see the speed difference.
Personally I've started to using XFS because it feels faster on everything but really large files. People should try XFS for their /usr/portage partition, then they might notice how fast it stays over time. _________________ Gentoo Hardened Linux 2.6.21 + svorak (Swedish dvorak) |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Aug 02, 2006 6:39 pm Post subject: |
|
|
Sachankara wrote: | People should try running with the default to see the speed difference. | what is default? I thought with -j, the default was full (metadata as well as data) journalling.
Sachankara wrote: |
Personally I've started to using XFS because it feels faster on everything but really large files. People should try XFS for their /usr/portage partition, then they might notice how fast it stays over time. | Tried it. Its freaky fast (mostly because of no data journalling) in benchmarks but my boot times increased on the same hardware in a dual boot setup, meaning real life read performance was worse than ext3. And this was with all the optimizations that I could find. Moreover, no data journalling kinda keeps me away from it. |
|
Back to top |
|
|
adsmith Veteran
Joined: 26 Sep 2004 Posts: 1386 Location: NC, USA
|
Posted: Wed Aug 02, 2006 6:56 pm Post subject: |
|
|
If you want real data, here are some good and generally accepted benchmarks:
http://linuxgazette.net/122/TWDT.html#piszcz
They are probably posted several pages back as well.
JFS and XFS are both excellent FS's, but as the previous posted said, neither support full-data journalling. With that fact and these benchmarks, EXT3 really shines.
By the way, for a while it was true that data journalling in EXT3 was somehow *faster* than just metadata journalling. See:
http://www-128.ibm.com/developerworks/linux/library/l-fs8.html
I'm not sure if this is still true. |
|
Back to top |
|
|
codergeek42 Bodhisattva
Joined: 05 Apr 2004 Posts: 5142 Location: Anaheim, CA (USA)
|
Posted: Thu Aug 03, 2006 1:36 am Post subject: |
|
|
Sedrik wrote: | How much improvement can one expect these tweaks(full journaling, indexing) to give?
Is it like 0.5% increase? more? less? | Honestly, I can't say for certain (though if you'd like, give me some time and I'm sure I could come up with some benchmarks). It certainly feels faster, or at least more responsive, though.
Sedrik wrote: | Nice guide =) | Thanks.
Sedrik wrote: | *Edit
Please continue to add more tweaks and safe modes to run to the first post as time goes by =) | If I think of any or find out anything, I'll surely add it. _________________ ~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Wed Aug 23, 2006 9:23 pm Post subject: |
|
|
Sedrik wrote: | HNice guide =) |
I second this! Without this thread I would'nt even have looked at ext3 after always hearing how slow and basically useless it was, but you showed me the light |
|
Back to top |
|
|
codergeek42 Bodhisattva
Joined: 05 Apr 2004 Posts: 5142 Location: Anaheim, CA (USA)
|
Posted: Thu Aug 24, 2006 3:47 am Post subject: |
|
|
mrcs wrote: | Sedrik wrote: | HNice guide =) |
I second this! Without this thread I would'nt even have looked at ext3 after always hearing how slow and basically useless it was, but you showed me the light | Wee. Another Ext3 convert! _________________ ~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Mon Aug 28, 2006 10:52 am Post subject: |
|
|
codergeek42 wrote: | Wee. Another Ext3 convert! |
Just one question though. When I set the size of ccache to 1G or greater, it's just a matter of time before ext3 breaks down, spits out tons of errors and remount / as read only.
If I set ccache to 512 or less, that never happens. What's up with that? |
|
Back to top |
|
|
neuron Advocate
Joined: 28 May 2002 Posts: 2371
|
Posted: Mon Aug 28, 2006 1:35 pm Post subject: |
|
|
mrcs wrote: | codergeek42 wrote: | Wee. Another Ext3 convert! |
Just one question though. When I set the size of ccache to 1G or greater, it's just a matter of time before ext3 breaks down, spits out tons of errors and remount / as read only.
If I set ccache to 512 or less, that never happens. What's up with that? |
hardware error, and your simply not hitting the error when using a smaller ccache. |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Mon Aug 28, 2006 5:20 pm Post subject: |
|
|
neuron wrote: | hardware error, and your simply not hitting the error when using a smaller ccache. |
Well, I have the same exact error on two machines, but I guess it could be the hardware. But shouldn't a hardware error pop up when doing other operations too? Like now, my laptop hardrive is 99% full and still no error like that.
EDIT: Um, actually it's nowhere near full, my bad, wrong drive, but the question remains. |
|
Back to top |
|
|
neuron Advocate
Joined: 28 May 2002 Posts: 2371
|
Posted: Mon Aug 28, 2006 9:05 pm Post subject: |
|
|
mrcs wrote: | neuron wrote: | hardware error, and your simply not hitting the error when using a smaller ccache. |
Well, I have the same exact error on two machines, but I guess it could be the hardware. But shouldn't a hardware error pop up when doing other operations too? Like now, my laptop hardrive is 99% full and still no error like that.
EDIT: Um, actually it's nowhere near full, my bad, wrong drive, but the question remains. |
it can be a lot of things, but all ccache does is stress the hardware, I very seriously doubt you'll find stability problems in ext3. (atleast without experimental patches) as it's being used on enterprise level all over the world. |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Mon Aug 28, 2006 11:26 pm Post subject: |
|
|
neuron wrote: | it can be a lot of things, but all ccache does is stress the hardware, I very seriously doubt you'll find stability problems in ext3. (atleast without experimental patches) as it's being used on enterprise level all over the world. |
Yeah, I'm suspecting that my slow laptop hard drive can't cope with that many seeks when the cache is to big. It does work flawlessly when the cache is set to <512M so you're probably right. The other one's a SCSI disc but that one might actually being dying. |
|
Back to top |
|
|
neuron Advocate
Joined: 28 May 2002 Posts: 2371
|
Posted: Tue Aug 29, 2006 1:26 am Post subject: |
|
|
mrcs wrote: | neuron wrote: | it can be a lot of things, but all ccache does is stress the hardware, I very seriously doubt you'll find stability problems in ext3. (atleast without experimental patches) as it's being used on enterprise level all over the world. |
Yeah, I'm suspecting that my slow laptop hard drive can't cope with that many seeks when the cache is to big. It does work flawlessly when the cache is set to <512M so you're probably right. The other one's a SCSI disc but that one might actually being dying. |
you might wanna look into smartmontools and check dmesg. |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3435 Location: Gainesville, Florida
|
Posted: Thu Sep 28, 2006 8:29 pm Post subject: |
|
|
adsmith wrote: Considering that the above article is from Dec 2001 and with 2.4 kernels, I've often wondered about this since I read page one of this thread, when I became an ext3 convert, although I went ahead and am still using data=journal to this day.
Seeing as how it was never entirely clear why this was the case (at least to me), and it simply goes against all logic (and the kernel fs docs), I'm changing all my ext3 partitions to data=writeback. I also ran Justin's LinuxGazette newer tests (with his script, and a 2.6.14 kernel) on my own system, comparing ext3 data=journal and data=writeback modes, and confirmed what logic predicts- writeback indeed produced better scores.
From the kernel Documentation/filesystems/ext3.txt file:
Quote: |
Data Mode
---------
There are 3 different data modes:
* writeback mode
In data=writeback mode, ext3 does not journal data at all. This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext3 performance.
* ordered mode
In data=ordered mode, ext3 only officially journals metadata, but it logically
groups metadata and data blocks into a single unit called a transaction. When
it's time to write the new metadata out to disk, the associated data blocks
are written first. In general, this mode performs slightly slower than
writeback but significantly faster than journal mode.
* journal mode
data=journal mode provides full data and metadata journaling. All new data is
written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes.
|
_________________ Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11 |
|
Back to top |
|
|
feld Guru
Joined: 29 Aug 2004 Posts: 593 Location: WI, USA
|
Posted: Mon Oct 30, 2006 4:20 pm Post subject: |
|
|
but some of us are more worried about filesystem integrity than being a ricer.
it's not like full journaled mode annihilates our performance in any considerable way... _________________ < bmg505> I think the first line in reiserfsck is
if (random(65535)< 65500) { hose(partition); for (i=0;i<100000000;i++) print_crap(); } |
|
Back to top |
|
|
XenoTerraCide Veteran
Joined: 18 Jan 2004 Posts: 1418 Location: MI, USA
|
Posted: Mon Oct 30, 2006 4:27 pm Post subject: |
|
|
yep integrity. writes are noted to be slower, but reads should be as fast normally and faster (than writeback) while writing. I don't know about others but I read data more than i write it. the only thing I have on reiserfs is portage because I don't need integrity and it handles small files better. the rest I need integrity on. /var might be a good candidate for writeback because logs are constantly being written. and aren't read as much. _________________ I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help. |
|
Back to top |
|
|
1bitmemory n00b
Joined: 08 Jun 2004 Posts: 17
|
|
Back to top |
|
|
|