Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Some ext3 Filesystem Tips
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5 ... 13, 14, 15  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Francis85
n00b
n00b


Joined: 27 Jan 2003
Posts: 35

PostPosted: Wed Aug 03, 2005 8:00 am    Post subject: Reply with quote

One of my computers here is a PowerMac 7300 with a 1GHz G3 cpu upgrade card, and 1 GB of ram.

That machine has a 50mhz bus speed, and by using the journal_data mount option on my ext3 filesystem, the machine would really choke.

Code:

kernel BUG in expand at mm/page_alloc.c:413!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT
NIP: C0043E28 LR: C0043E24 SP: E5C9DC10 REGS: e5c9db60 TRAP: 0700 Not tainted
MSR: 00021032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = e727b0b0[7523] 'ftp' THREAD: e5c9c000
Last syscall: 4
GPR00: 00000001 E5C9DC10 E727B0B0 00000001 C0C8F040 C0368EBC C0368E70 C0C8F018
GPR08: 00000080 C0368F1B C0C8F080 C0368F1C 24022424 1004F070 E603F3A8 00000001
GPR16: E5C9DCC0 C036C4FC E74919A0 000003C8 000001E0 0000001F 0000001E 00001032
GPR24: 000000D2 00000000 00000000 C0368E1C C0C8F000 00000001 00000002 C0368E74
NIP [c0043e28] __rmqueue+0xc8/0x140
LR [c0043e24] __rmqueue+0xc4/0x140
Call trace:
[c00444ec] buffered_rmqueue+0x26c/0x2e8
[c0044888] __alloc_pages+0x278/0x410
[c00411b0] generic_file_buffered_write+0x124/0x648
[c0041ce0] __generic_file_aio_write_nolock+0x2f0/0x588
[c0041ff0] generic_file_aio_write+0x78/0x18c
[c00e86bc] ext3_file_write+0x20/0xe4
[c00620f0] do_sync_write+0x9c/0x104
[c00622dc] vfs_write+0x184/0x1ac
[c00623e0] sys_write+0x4c/0x90
[c0004380] ret_from_syscall+0x0/0x44
note: ftp[7523] exited with preempt_count 2
scheduling while atomic: ftp/0x10000002/7523
Call trace:
[c02f0154] schedule+0x74c/0x77c
[c02f0c68] cond_resched+0x48/0x64
[c004f7a4] unmap_vmas+0x5c8/0x5d4
[c0054bc8] exit_mmap+0x70/0x158
[c0016cf0] mmput+0x54/0x100
[c001b654] exit_mm+0xc8/0x1e4
[c001bb58] do_exit+0xec/0xbf0
[c0004e98] _exception+0x0/0xa8
[c0004f08] _exception+0x70/0xa8
[c0004a88] ret_from_except_full+0x0/0x4c
[c0043e28] __rmqueue+0xc8/0x140
[c00444ec] buffered_rmqueue+0x26c/0x2e8
[c0044888] __alloc_pages+0x278/0x410
[c00411b0] generic_file_buffered_write+0x124/0x648
[c0041ce0] __generic_file_aio_write_nolock+0x2f0/0x588
Bad page state at prep_new_page (in process 'kjournald', page c0c8f080)
flags:0x000122d1 mapping:00000000 mapcount:65536 count:-1013692927
Backtrace:
Call trace:
[c0043980] bad_page+0x64/0xbc
[c00444ac] buffered_rmqueue+0x22c/0x2e8
[c0044888] __alloc_pages+0x278/0x410
[c00481e4] cache_alloc_refill+0x318/0x598
[c0047cdc] kmem_cache_alloc+0x64/0x68
[c0043104] mempool_alloc_slab+0x1c/0x2c
[c0042f18] mempool_alloc+0x5c/0x140
[c0068498] bio_alloc_bioset+0x28/0x1ac
[c00658f4] submit_bh+0xb4/0x194
[c00fefd8] journal_commit_transaction+0x6f8/0x1498
[c01023b8] kjournald+0xdc/0x284
[c0006ea4] kernel_thread+0x44/0x60
Trying to fix it up, but a reboot is needed

    <any write access fails until I reboot the machine, and freezes the active console>



I would get these errors by initiating a FTP transfer on my LAN. File transfer would start at 11 MB/s, and then drop and drop to about 6 MB/s and then die with this error. Disabling journal_data fixes this issue, although I'm back to using reiserfs. Even fsck would provoke such errors! In other words, anything which would need relatively quick access to the drive.

Now, as long as it is able to saturate a 100baseTX link, I have no issue with it, since this machine is my LAN's file server.
Maybe this could be helpful to someone..
Back to top
View user's profile Send private message
ruben
Guru
Guru


Joined: 04 Jul 2003
Posts: 462

PostPosted: Wed Aug 03, 2005 8:15 am    Post subject: Reply with quote

It might not be related in any way, but i see in your post the following:
Code:
PREEMPT

Just wondering if you have enabled 'kernel preemption' in your kernel config. You should disable it on ppc machines, it does not work and can lead to all kinds of weird errors. (Alternatively, you can enable it, but then you should also enable SMP, even if your machine is not a dual processor)
Back to top
View user's profile Send private message
Francis85
n00b
n00b


Joined: 27 Jan 2003
Posts: 35

PostPosted: Wed Aug 03, 2005 10:54 am    Post subject: Reply with quote

It is not enabled in my config, I just checked.
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Wed Aug 03, 2005 3:50 pm    Post subject: Reply with quote

This isn't really a support forum (perhaps you should post your problem in the Kernel & Hardware forum).

That said, if you're not running your FTP daemon, does mounting it with full data journalling work ok? Perhaps the ftp daemon creates a bad system call or something. :?
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
Francis85
n00b
n00b


Joined: 27 Jan 2003
Posts: 35

PostPosted: Wed Aug 03, 2005 5:51 pm    Post subject: Reply with quote

Nope.. as I said even fsck.ext3 would make the kernel go nuts! (These kernel panics would sometimes make the filesystem completely unrecoverable, unless I booted on another drive and fsck.ext3 it from there)

That said, I know this is not a support forum, but wanted to mention this here in case anyone would get such odd behavior. :)
Back to top
View user's profile Send private message
neuron
Advocate
Advocate


Joined: 28 May 2002
Posts: 2371

PostPosted: Tue Oct 04, 2005 3:18 pm    Post subject: Reply with quote

Anyone know if somoene has figured out what causes journal mode to be faster than writeback yet?
Back to top
View user's profile Send private message
vipernicus
Veteran
Veteran


Joined: 17 Jan 2005
Posts: 1462
Location: Your College IT Dept.

PostPosted: Wed Oct 05, 2005 12:07 am    Post subject: Reply with quote

can full_journal be safely disabled?
_________________
Viper-Sources Maintainer || nesl247 Projects || vipernicus.org blog
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Wed Oct 05, 2005 12:18 am    Post subject: Reply with quote

vipernicus wrote:
can full_journal be safely disabled?
Yes. Running tune2fs again will make the filesystem use ordered journalling mode (the default):
Code:
# tune2fs -o journal_data_ordered /dev/hdXY
Hope that helps.
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
pv
Tux's lil' helper
Tux's lil' helper


Joined: 25 Mar 2005
Posts: 103
Location: Russia, Yaroslavl

PostPosted: Sat Dec 03, 2005 10:12 pm    Post subject: Reply with quote

I'm going to reinstall Gentoo and make the root partition to be ext3fs (now it is reiserfs).
I've run a small test.

First I run something like
Code:
mke2fs -j /dev/hda3
tune2fs -o journal_data -O dir_index /dev/hda3
mount -o noatime /dev/hda3 /mnt/tmp
time tar xjf portage-20050712.tar.bz2 -C /mnt/tmp
Real         1m4s
User          19s
System         5s

Then
Code:
mkreiserfs /dev/hda3
mount -o noatime,notail,data=journal /dev/hda3 /mnt/tmp
time tar xjf portage-20050712.tar.bz2 -C /mnt/tmp
Real          44s
User          18s
System        11s

I'm sorry but ext3fs doesn't seem to be better (meaning faster) in terms of real time. Unpacking a kernel I had the similar results. (Note that while mounting reiserfs partition I used notail option). Where can I (if can) found results saying that ext3 is better than reiserfs? Was I quite wrong thinking this thread states that ext3fs is both more stable and faster than reiserfs?
BTW, my frient has Fedora Core N and a system very like my one except his root partition is ext3, and his system looks MUCH faster than my Gentoo. Is the reason of that some Fedora patches increasing ext3fs performance?
_________________
Nothing but perfection.
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Sat Dec 03, 2005 10:40 pm    Post subject: Reply with quote

pv wrote:
I'm sorry but ext3fs doesn't seem to be better (meaning faster) in terms of real time. Unpacking a kernel I had the similar results. (Note that while mounting reiserfs partition I used notail option).
ReiserFS is heavily optimized to be very fast with large quantities of small files (such as kernel sources or the portage tree). This is why you see it so much faster, even with full data journalling.
Quote:
Where can I (if can) found results saying that ext3 is better than reiserfs?
I'm not a believer of benchmarks, though Google would probably have some. The way I found this out is by installing a full ReiserFS-based system (same full journalling, etc.) and installing a full Ext3-based system. (Same hardware, kernel, etc.). While Ext3 does tend to be slightly slower in this regard, it was clearly the winner for me in terms of interactivity and "feeling" fast.
Quote:
Was I quite wrong thinking this thread states that ext3fs is both more stable and faster than reiserfs?
I'd say it's much more stable than ReiserFS, but it seems to be about on par with it for general desktop use in terms of speed, etc.
Quote:
BTW, my frient has Fedora Core N and a system very like my one except his root partition is ext3, and his system looks MUCH faster than my Gentoo. Is the reason of that some Fedora patches increasing ext3fs performance?
Fedora does not use full journalling by default, only ordered journalling (writes the metadata to the journal, then flushes the data and commits the journal while trying to do I/O in large blocks).

I don't want this thread to turn into a ReiserFS vs. Ext3 debate though (that's been discussed in other threads).
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Thu Dec 08, 2005 5:39 am    Post subject: Reply with quote

Quote:
neuron wrote:
Anyone know if somoene has figured out what causes journal mode to be faster than writeback yet?


I'm still wondering too. Has there been any more updated info coming out about preferring the ext3 full journaling mode, as opposed to the "writeback mode? As one now in the process of converting multiple Gentoo systems / partitions back to ext3 (tweaked with dir_index, journal_data) from reiserfs, I'd really like to know if the info on this thread, and the Robbins article about the journal mode being much faster is in the final analysis, correct.

Reading stuff like on the link below (as well as many other supposedly reliable "expert" sources) leads one to wonder what the truth really is, as most all insist that writeback offers better performance at the expense of data protection.

http://www.linuxplanet.com/linuxplanet/reports/4136/5/

One other basic question for the ext3 experts:
Am I correct in thinking that all the tune2fs options can be run on unmounted ext3 / partitions (with a full Linux installation already existing on said partition), as long as you run e2fsck -D after tune2fs, and the result will be no data loss, or any other negative impact?

I have several other Linux distros installed with default ext3 / partitions that I'd like to tweak up a bit.

Oh yeah- Many thanks to codergeek42 for tying this all together for me- the reiserfs fragmentation was becoming a problem.

I guess what prompted me to go with reiserfs 3+ years ago in the first place was the abysmal default ext3 performance of my first linux distros, and reiserfs was definitely an improvement at the time, especially with the 2.4 kernels of the day.

Any more thoughts on the commit= setting? It seems to me syncing all it's buffers the default every 5 seconds is overkill, and must affect performance to some extent. Maybe not commit=9999, but what about a more reasonable sync interval- say every 60, 120, 512, or whatever number of seconds???

A quote from http://navindra.blogspot.com/2004/10/kde-dot-news-ext3s-miserable-failure.html

Quote:
And the last interesting parameter is commit. commit defaults to 5 in ext3, and it means that ext3 will sync all its buffers - yes, that's a sync every 5 seconds. It harms performance a _lot_ and ext3 defaults to that value because ext3 developers are really _paranoic_ about data safety. You can mout ext3 it with huge values to increase performance

In short, if you want to do _fair_ benchmarks reiser vs ext3, you must:
o use htree
o use 2.6 (orlov, also ext3 is a _lot_ faster in 2.6, reiserfs too I guess)
o mount your filesystem with data=writeback
o mount your filesystem with commit=9999 (or whatever huge value you want)
o read Documentation/filesystems/ext3.txt


Again, this guy recommends data=writeback and commit=xxxx. (this blog was from Oct 2004, so it's not too outdated)
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Thu Dec 08, 2005 6:58 am    Post subject: Reply with quote

wrc1944 wrote:
Reading stuff like on the link below (as well as many other supposedly reliable "expert" sources) leads one to wonder what the truth really is, as most all insist that writeback offers better performance at the expense of data protection.
Well, I'm personally a fan of "if it gets done much more reliably with a small sacrifice in performance, do it." I've noticed only minor slowdowns on my machine with full journalling enabled, though your experiences may vary of course. In fact, it "feels" just as fast as ordered data mode to me.
Quote:
One other basic question for the ext3 experts:
Am I correct in thinking that all the tune2fs options can be run on unmounted ext3 / partitions (with a full Linux installation already existing on said partition), as long as you run e2fsck -D after tune2fs, and the result will be no data loss, or any other negative impact?
Correct. Just make sure it's unmounted before doing this. If it is mounted, I can almost guarantee you severe data loss.
Quote:
I have several other Linux distros installed with default ext3 / partitions that I'd like to tweak up a bit.
It should work the same, as long as they all have recent kernel and e2fsprogs versions, etc.
Quote:
Oh yeah- Many thanks to codergeek42 for tying this all together for me- the reiserfs fragmentation was becoming a problem.
I'm happy to help. :)
Quote:
Any more thoughts on the commit= setting? It seems to me syncing all it's buffers the default every 5 seconds is overkill, and must affect performance to some extent. Maybe not commit=9999, but what about a more reasonable sync interval- say every 60, 120, 512, or whatever number of seconds???
That's up to you to tweak as you see fit. I've left it at the default and it works fine. Remember though, it can also sacrificing performance for stability (what if the journal write is still stored in RAM on a power failure?).
Quote:
Again, this guy recommends data=writeback and commit=xxxx. (this blog was from Oct 2004, so it's not too outdated)
It really depends on your goals and tests. Like I said, my first priority with my data is keeping it safe. Generally speaking, I can read/write that data Fast Enough(tm). :)
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Thu Dec 08, 2005 8:57 am    Post subject: Reply with quote

I must be misunderstanding what codergeek42 and 6thpink are saying about commit=xxxx.

I do understand 6thpink's statement:
Quote:
I agree and also add that a so high commit raises the probability of data loss, and we dont want that (if we wanted we would be using reiser4

which seems to agree with the kernel ext3 documentation.

FROM KERNEL DOC
Quote:
Ext3 can be told to sync all its data and metadata
every 'nrsec' seconds. The default value is 5 seconds.
This means that if you lose your power, you will lose,
as much, the latest 5 seconds of work (your filesystem
will not be damaged though, thanks to journaling). This
default value (or any low value) will hurt performance,
but it's good for data-safety. Setting it to 0 will
have the same effect than leaving the default 5 sec.
Setting it to very large values will improve
performance.


What I don't get is codergeeks statement:
Quote:
This mount option specifies how often (in second intervals) to sync the data to disk. Setting this too high may cause excessive usage of memory and possibly CPU/swap resources.

If the number is set higher, meaning less number of actual syncs for a given time period, how can that cause more memory and/or cpu/swap usage?

In other words, wouldn't the longer the time interval between each sync mean less memory/cpu/swap usage for any given time period considered, because there is less activity? Put yet another way, if you use the default commit=5 (which equals 60 syncs per 5 minutes), wouldn't commit=60 mean only 5 syncs per every 5 minutes, and cut down on a lot of background activity, translating into a little better performance? And, the higher the commit= number, the less syncs per time period, and the higher the potential for data loss on a crash. So the question seems to be where is the point where data loss potential exceeds the performance benefit of a lessor number of syncs?

If this is incorrect, where am I going wrong? I think I'm getting a headache at this point :roll:
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Thu Dec 08, 2005 5:23 pm    Post subject: Reply with quote

wrc1944 wrote:
What I don't get is codergeeks statement:
Quote:
This mount option specifies how often (in second intervals) to sync the data to disk. Setting this too high may cause excessive usage of memory and possibly CPU/swap resources.

If the number is set higher, meaning less number of actual syncs for a given time period, how can that cause more memory and/or cpu/swap usage?
Sorry for not being clear there. What I meant was that, since the filesystem driver has been instructed to sync to the disk less often, it will likely use more resources because having that longer sync interval means that the data that still has not been written to the disk yet must be stored in memory. This could lead to more swap usage (if you don't have a lot of memory and set the commit=whatever option too high). I don't actually remember why I thought it would increase CPU usage noticably. :oops: If and/or when I do, I'll post that do.
Quote:
So the question seems to be where is the point where data loss potential exceeds the performance benefit of a lessor number of syncs?
I'm not an expert on this at all. Basically, I very much trust the kernel hackers who are doing this, so these two (three?) settings are the only options I've changed from the default mke2fs options. Like I mentioned though, you could also play with the journal size (`tune2fs -J size=$SIZE /dev/hdXY`); but be sure to read the relevant section of the man page for the limitations of that size.
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
pv
Tux's lil' helper
Tux's lil' helper


Joined: 25 Mar 2005
Posts: 103
Location: Russia, Yaroslavl

PostPosted: Thu Dec 08, 2005 9:07 pm    Post subject: Reply with quote

codergeek42 wrote:
I don't actually remember why I thought it would increase CPU usage noticably. :oops: If and/or when I do, I'll post that do.

I think that after, for example, an hour of buffering data in the memory and not saving to disk, the processor (and disk itself) will have to write much more data to disk than after 30 seconds consuming more time while doing this.

codergeek42 wrote:
Basically, I very much trust the kernel hackers who are doing this.

Agree. The kernel is the kernel and it must be stable as well as productive (fast and requiring little memory), and nobody but the kernel hackers knows how it works and how it can be improved.
_________________
Nothing but perfection.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Thu Dec 08, 2005 11:06 pm    Post subject: Reply with quote

Thanks codergeek42 and pv.
Your clarifications really help me understand this much better, and make perfect sense now that I think more carefully about it.

So I guess the conclusion might be that there's really no significant benefit from having a lessor number of syncs per given time period, and in fact it might even be worse. I guess the theory would be that having a very small sync every 5 seconds is far less noticable (and affects overall performance less) than to be going along in some process, and then suddenly having it preempted by a huge sync process, even if you have plenty of memory, and aren't using swap at all.

Now the only question is how long can I resist the temptation to play around with the commit= setting? And of course then there's the theory that maybe I'm just too much of a nit-picker about these types of things for my own good. :)
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Thu Dec 08, 2005 11:57 pm    Post subject: Reply with quote

Another convert here.

codergeek42 you only convince me by half. ;) The other half was my 75% full reiserfs partition that make my gentoo soo sloooow last 2-3 month :lol:

After read that reiserfs is not on development anymore i give up invest time on a dead horse and make my move.
I change to a mix of ext3 (with your tune sugestion) and xfs for partiitons with large files and everithing returns to the good old speed.

many thanks!

oh btw. i still keep my /usr/portage on ext2 (emerge --sync is a nice journal sistem :)). Do you note a real improvment, in speed terms, to move to the magic ext3 with journal mode?
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Fri Dec 09, 2005 1:05 am    Post subject: Reply with quote

RuiP wrote:
oh btw. i still keep my /usr/portage on ext2 (emerge --sync is a nice journal sistem :)). Do you note a real improvment, in speed terms, to move to the magic ext3 with journal mode?
To be honest, every partition on my system (including /boot) is Ext3 with these tweaks, so I have no comparison with a "standard" Ext2 setup. :)
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Fri Dec 09, 2005 2:30 am    Post subject: Reply with quote

I had forgotten about what RuiP mentions- about reiserfs not being actively developed anymore. I guess all efforts are going into reiser4, where a 6 month trial (/ included) didn't convince me that it was ready- same gradual slow-down problem, but worse.

As for being a convert, I think I'm almost there. :D I'll shake down this one ext3 tweaked box for a few more days, and then convert my other reiserfs Gentoo boxes if all goes well.

I have noticed 2 little things so far. One, the shell script and python script icons reverting to generic (no others did), and two, on bootup my system sometimes hangs at loading "local start" items for about 30-40 seconds before continuing to a normal kdm boot, whereas it use to only pause 2 seconds under reiserfs. Don't know if that's ext3 related, or not, but I haven't synced and emerged anything since I converted /, so it seems likely ext3 could be the reason.

EDIT: The booting "hang" was fixed by resetting my modem and router, so not ext3 related.
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
enderandrew
l33t
l33t


Joined: 25 Oct 2005
Posts: 731

PostPosted: Fri Dec 09, 2005 2:09 pm    Post subject: Reply with quote

Has anyone tried this patches?

http://www.bullopensource.org/ext4/

I can't get all six to play nicely with each other.
_________________
Nihilism makes me smile.
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Fri Dec 09, 2005 3:39 pm    Post subject: Reply with quote

enderandrew wrote:
Has anyone tried this patches?

http://www.bullopensource.org/ext4/

I can't get all six to play nicely with each other.
I'm waiting for those to hit upstream. :D
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Fri Dec 09, 2005 10:00 pm    Post subject: Reply with quote

I looked at the benchmarks on this page, but unfortunately, for some reason they didn't test with journal_data. After reading this thread and a few other sources, one would think journal_data definitely warrants comparison testing. Surely they (the ext2/ext3 improvement project people) must also be aware of the information and conclusions on journal_data mentioned here, but since they don't even mention it, I'm wondering once again what all this really means. How could they ignore the Dan Robbins article's statement and conclude journal_data wasn't worth testing?
Quote:
Therefore, ext3's data=journal mode, which was assumed to be the slowest of all ext3 modes in nearly all conditions, actually turns out to have a major performance advantage in busy environments where interactive IO performance needs to be maximized. Maybe data=journal mode isn't so sluggish after all!

Or is this info now too outdated to be considered, given newer kernels, gcc versions, and far more powerful hardware, etc?
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
the_g_cat
Tux's lil' helper
Tux's lil' helper


Joined: 31 Mar 2004
Posts: 117
Location: Dortmund - Germany

PostPosted: Mon Dec 12, 2005 4:10 pm    Post subject: Reply with quote

Hi all,

Just wanted to ask if there was a way to retrieve the journal and read some parts of it. Bottom line is: I have accidentaly deleted some files, and it is clear to me that I won't be able to undelete them, but I'd need to know the names of the files so I can evaluate what I would need to start looking for again and what not.

Thanks,

Cat
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 2767
Location: Gainesville, Florida

PostPosted: Sun Dec 18, 2005 6:51 pm    Post subject: Reply with quote

Well, I guess I'm now an ""official" tuned ext3 convert, as all my Gentoo installations are now converted. Again, thanks much to codergeek42 for sharing this great info with all of us!

I noticed fallow on page 3 of this thread uses writeback mode. I was wondering if anyone had any more info, comparisons, or thoughts on this, as opposed to using the journal_data mode?

I had at first considered using writeback, but after reading the Robbins article and comments here, I chose journal_data. I'm still wondering if I made the correct choice. Don't get me wrong- I'm very pleased with the change, and even converted my gcc-4.1 test box / to tuned ext3. I just wish to squeeze every last % of performance out of my Linux boxes.

If I did decide to try writeback, am I correct is thinking I can just freely switch back and forth between modes by mounting a knoppix cd, and running:

tune2fs -o journal_data_writeback /dev/hdxy

and then, e2fsck -D /dev/hdXY

on my unmounted Linux partitions? (And of course, experience no difficulties?)
_________________
Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.19, gcc-4.9.0, kernel 3.16.1-gentoo (USE=experimental "native")
Back to top
View user's profile Send private message
ExZombie
Apprentice
Apprentice


Joined: 29 May 2004
Posts: 164

PostPosted: Sun Dec 18, 2005 9:48 pm    Post subject: Reply with quote

tune2fs manpage has a short and to-the-point description of the three journal modes available. Writeback mode is the most performant, but if the filesystem is not unmounted cleanly you might (and you will) find that some files contain old data. To be exact, the files that were written to last and did not yet have their data synced will contain old data.
This is not actually that bad, provided you manually use 'sync' command before doing something that could hardlock your system. Having 'Magic SysRq' support compiled in your kernel can also be useful :) .

And yes, you can freely change journal modes. It's not even necessary to use tune2fs - by using it you are only changing the defaults which are written in the superblock. You can simply supply the option in fstab.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3, 4, 5 ... 13, 14, 15  Next
Page 4 of 15

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum