reiserfs patch for 2.4.0-prerelease
Hello everyone,
This patch is meant to be applied on top of the reiserfs 3.6.23 patch to get everything working in the new prerelease kernels. The order is:
untar linux-2.4.0-prerelease.tar.bz2
apply linux-2.4.0-test12-reiserfs-3.6.23.gz
apply this patch
apply the fs/super.c patch to make sure fsync_dev is called when unmounting /. This was already sent to l-k, I'll send to the reiserfs list as well.
If you want to apply the prerelease-diff from the testing dir it can go before or after the reiserfs patches.
These changes have been tested, but still need more. Don't apply if you aren't willing to bleed a little.
Changes:
Undoes the fs/buffer.c fuzz error from patching 3.6.23 into the prerelease kernels.
Remove the super unlocking hack that was needed to avoid deadlocks with my old end_io tasks. The tasks are gone, so are the deadlocks.
Change around the dirty inode call back so the reiserfs inodes get properly marked as dirty for the O_SYNC and dirty page stuff. This is kind of ugly, and I need to change it around more. But, it will work for now.
Add proper O_SYNC and fsync support.
Fix reiserfs makefile and page->mapping->host casts to work with the new kernel.
Log the super before balancing to avoid warning messages about logging an unprepared buffer.
Clears the dirty bit before sending buffers to submit_bh in reiserfs_writepage.
Please send any bug reports to the reiserfs list.
-chris
fs/buffer.c +0 -2
@@ -1647,8 +1647,6 @@buffer_insert_inode_queue (bh, inode); need_balance_dirty =1 ; } -if (buffer_uptodate (bh)) -continue ; } }
fs/inode.c +0 -4
@@ -134,10 +134,6 @@void __mark_inode_dirty (struct inode *inode,int flags) {struct super_block * sb = inode->i_sb; -if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->dirty_inode){ - inode->i_sb->s_op->dirty_inode (inode) ; -return ; - }if (sb) {spin_lock (&inode_lock);if ((inode->i_state & flags) != flags) {
fs/reiserfs/Makefile +2 -2
@@ -8,10 +8,10 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := reiserfs.o -O_OBJS := bitmap.o do_balan.o namei.o inode.o file.o dir.o fix_node.o super.o prints.o objectid.o \ +obj-y := bitmap.o do_balan.o namei.o inode.o file.o dir.o fix_node.o super.o prints.o objectid.o \ lbalance.o ibalance.o stree.o hashes.o buffer2.o tail_conversion.o journal.o resize.o tail_conversion.o version.o item_ops.o ioctl.o -M_OBJS := $(O_TARGET) +obj-m := $(O_TARGET) include $(TOPDIR)/Rules.make
fs/reiserfs/file.c +3 -5
@@ -90,11 +90,9 @@if (!S_ISREG (p_s_inode->i_mode))BUG (); -/* step one, flush all dirty buffers in the file's page map to disk */ - n_err =generic_buffer_fdatasync (p_s_inode,0 , ~0UL ) ; - -/* step two, commit the current transaction to flush any metadata -** changes + n_err =fsync_inode_buffers (p_s_inode) ; +/* commit the current transaction to flush any metadata +** changes. sys_fsync takes care of flushing the dirty pages for us */ journal_begin (&th, p_s_inode->i_sb, jbegin_count) ; windex =push_journal_writer ("sync_file" ) ;
fs/reiserfs/fix_node.c +14 -1
@@ -2499,7 +2499,20 @@if (FILESYSTEM_CHANGED_TB (p_s_tb) )return REPEAT_SEARCH ; } - +/* we log the super here so we know it is prepared and inside the +** transaction before the do_balance starts. This way, do_balance +** won't have to prepare it later on, when we aren't allowed to +** schedule +*/ +reiserfs_prepare_for_journal (p_s_tb->tb_sb, +SB_BUFFER_WITH_SB (p_s_tb->tb_sb),1 ) ; +if (FILESYSTEM_CHANGED_TB (p_s_tb) ) { +reiserfs_restore_prepared_buffer (p_s_tb->tb_sb, +SB_BUFFER_WITH_SB (p_s_tb->tb_sb)) ; +return REPEAT_SEARCH ; + } +journal_mark_dirty (p_s_tb->transaction_handle, p_s_tb->tb_sb, +SB_BUFFER_WITH_SB (p_s_tb->tb_sb)) ;#ifndef __KERNEL__ if ( atomic_read (&(p_s_tbS0->b_count)) > 1 || (p_s_tb->L[0] && atomic_read (&(p_s_tb->L[0]->b_count)) > 1) ||
fs/reiserfs/inode.c +50 -14
110 lines not on this page · raw message
fs/reiserfs/resize.c +0 -4
@@ -134,10 +134,8 @@SB_AP_BITMAP (s) = bitmap; } -unlock_super (s) ;/* deadlock avoidance */ /* begin transaction */ journal_begin (&th, s,10 ); -lock_super (s) ;/* must keep super locked during these ops */ /* correct last bitmap blocks in old and new disk layout */ reiserfs_prepare_for_journal (s,SB_AP_BITMAP (s)[bmap_nr -1 ],1 );
@@ -163,9 +161,7 @@journal_mark_dirty (&th, s,SB_BUFFER_WITH_SB (s));SB_JOURNAL (s)->j_must_wait =1 ; -unlock_super (s) ;/* see comments in reiserfs_put_super() */ journal_end (&th, s,10 ); -lock_super (s);return 0 ; }
fs/reiserfs/super.c +0 -19
@@ -46,9 +46,7 @@int dirty =0 ;lock_kernel () ;if (!(s->s_flags &MS_RDONLY )) { -unlock_super (s) ; dirty =flush_old_commits (s,1 ) ; -lock_super (s) ; } s->s_dirt = dirty;unlock_kernel () ;
@@ -68,12 +66,10 @@struct reiserfs_transaction_handle th ;lock_kernel () ;if (!(s->s_flags &MS_RDONLY )) { -unlock_super (s) ;journal_begin (&th, s,1 ) ;journal_mark_dirty (&th, s,SB_BUFFER_WITH_SB (s));reiserfs_block_writes (&th) ;journal_end (&th, s,1 ) ; -lock_super (s) ; } s->s_dirt = dirty;unlock_kernel () ;
@@ -98,14 +94,6 @@int i;struct reiserfs_transaction_handle th ; -/* the end_io task has to call get_super, which locks the super, which -** will deadlock with the journal. So, we unlock, and then relock -** when the journal is done. -** -** this sucks. -*/ -unlock_super (s) ; -/* change file system state to current state if it was mounted with read-write permissions */ if (!(s->s_flags &MS_RDONLY )) {journal_begin (&th, s,10 ) ;
@@ -118,7 +106,6 @@** to do a journal_end */ journal_release (&th, s) ; -lock_super (s) ;for (i =0 ; i <SB_BMAP_NR (s); i ++)brelse (SB_AP_BITMAP (s)[i]);
@@ -271,9 +258,7 @@return 0 ; } -unlock_super (s) ;journal_begin (&th, s,10 ) ; -lock_super (s) ;/* Mounting a rw partition read-only. */ reiserfs_prepare_for_journal (s,SB_BUFFER_WITH_SB (s),1 ) ; rs->s_state =cpu_to_le16 (s->u.reiserfs_sb.s_mount_state);
@@ -282,9 +267,7 @@ }else { s->u.reiserfs_sb.s_mount_state =le16_to_cpu (rs->s_state) ; s->s_flags &= ~MS_RDONLY ;/* now it is safe to call journal_begin */ -unlock_super (s) ;journal_begin (&th, s,10 ) ; -lock_super (s) ;/* Mount a partition which is read-only, read-write */ reiserfs_prepare_for_journal (s,SB_BUFFER_WITH_SB (s),1 ) ;
@@ -298,9 +281,7 @@ }/* this will force a full flush of all journal lists */ SB_JOURNAL (s)->j_must_wait =1 ; -unlock_super (s) ;journal_end (&th, s,10 ) ; -lock_super (s) ;return 0 ; }
fs/reiserfs/utils/lib/version.c +1 -1
@@ -3,5 +3,5 @@*/ char *reiserfs_get_version_string (void ) { -return "ReiserFS version 3.6.23" ; +return "ReiserFS version 3.6.24" ; }
fs/reiserfs/version.c +1 -1
@@ -3,5 +3,5 @@*/ char *reiserfs_get_version_string (void ) { -return "ReiserFS version 3.6.23" ; +return "ReiserFS version 3.6.24" ; }
include/linux/fs.h +33 -29
74 lines not on this page · raw message
include/linux/reiserfs_fs.h +1 -3
@@ -1809,9 +1809,7 @@void reiserfs_write_inode (struct inode * inode,int ) ;/* we don't mark inodes dirty, we just log them */ -static inline void reiserfs_dirty_inode (struct inode * inode) { -reiserfs_write_inode (inode,0 ) ; -} +void reiserfs_dirty_inode (struct inode * inode) ; struct inode * reiserfs_new_inode (struct reiserfs_transaction_handle *th, const struct inode * dir, int mode, const char * symname, int item_len,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hi,
I have been doing some dbench runs with the original and latest (Jan 4 22:xx) prerelease.diff kernels. Looks like both the latest kernels and the reiserfs patch both are costing some performance.
prerelease
MB/s user system cpu time
ext2 14.6 50.5s 76.4s 29% 7:14.9m
ext2 12.6 50.9s 76.7s 25% 8:23.6m
reiser 14.5 53.8s 149.2s 46% 7:16.1m
reiser 10.7 54.1s 154.5s 35% 9:49.9m
prerelease (2.4.0 jan 4 22:xx)
MB/s user system cpu time
ext2 10.5 52.8s 81.5s 22% 10:02.3m
reiser 5.8 54.6s 198.5s 23% 18:12.5m
reiser 6.4 55.1s 188.7s 24% 16.19.3m
Using the notail reiserfs mount option improves the reiserfs numbers 10-20% with both kernels.
All benchmarks run on a K6-III 400 with 128M just after boot with no X running.
Comments?
Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
reiserfs patch for 2.4.0-final
In reply to Chris MasonQuoted 10 lines · Chris Mason
This patch is meant to be applied on top of the reiserfs 3.6.23 patch to get everything working in the new prerelease kernels. The order is:
untar linux-2.4.0-prerelease.tar.bz2
apply linux-2.4.0-test12-reiserfs-3.6.23.gz
apply this patch
apply thefs/super.cpatch to make surefsync_devis called when unmounting /. This was already sent to l-k, I'll send to the reiserfs list as well.
Is this still correct for the final 2.4.0-kernel ?
Could someone create one single patch for the 2.4.0 ?
Bye,
Claas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
Quoted 5 lines · On Friday, January 05, 2001 02:04:08 PM +0100 Claas Langbehn…
Quoted 4 lines · Chris Mason
This patch is meant to be applied on top of the reiserfs 3.6.23 patch to get everything working in the new prerelease kernels. The order is:
Quoted 9 lines
Quoted 6 lines
untar linux-2.4.0-prerelease.tar.bz2
apply linux-2.4.0-test12-reiserfs-3.6.23.gz
apply this patch
apply thefs/super.cpatch to make surefsync_devis called when unmounting /. This was already sent to l-k, I'll send to the reiserfs list as well.Is this still correct for the final 2.4.0-kernel ?
Yes
Quoted 2 lines
Could someone create one single patch for the 2.4.0 ?
I put all the code into CVS, and Yura is making the official patch now.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
Quoted 3 lines · Chris Mason
Quoted 2 lines
Could someone create one single patch for the 2.4.0 ?
I put all the code into CVS, and Yura is making the official patch now.
Since 2.4.0 final should fix a few i/o performance issues (particuarly under heavy write loads), a quick few ext2 vs. reiserfs benchmarks would make very interesting reading ;-)
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
Quoted 9 lines · Chris Evans
Quoted 3 lines · Chris Mason
Quoted 2 lines
Could someone create one single patch for the 2.4.0 ?
I put all the code into CVS, and Yura is making the official patch now.
Since 2.4.0 final should fix a few i/o performance issues (particuarly under heavy write loads), a quick few ext2 vs. reiserfs benchmarks would make very interesting reading ;-)
An easy way to gain a performance edge on ext2 would be to do proper write clustering in the reiserfs ->writepage() function... </hint>
regards,
Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
Quoted 7 lines · On Friday, January 05, 2001 02:54:53 PM -0200 Rik van Riel…
Quoted 6 lines · Chris Evans
Quoted 3 lines · Chris Mason
Quoted 2 lines
Could someone create one single patch for the 2.4.0 ?
I put all the code into CVS, and Yura is making the official patch now.
Quoted 8 lines
Quoted 3 lines
Since 2.4.0 final should fix a few i/o performance issues (particuarly under heavy write loads), a quick few ext2 vs. reiserfs benchmarks would make very interesting reading ;-)
An easy way to gain a performance edge on ext2 would be to do proper write clustering in the reiserfs ->writepage() function... </hint>
;-)
The current 2.4 code has lots of room for tuning, since I've been trying to keep it clean/stable for now (and our dbench numbers show it). The first optimization is tuning for reiserfs_get_block, I think writepage clustering will be easier (and more beneficial) if we work out the buffer.c changes I've been posting.
I also want to change the log block allocation a bit, so the log blocks are allocated as the transaction progresses, instead of all at the end. I think that will make us much more VM friendly, and let me get rid of the inode writing kludges. It'll be a busy weekend ;-)
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
In reply to Rik van RielIs ext2 upgradable to reiserfs or ext3?
If so, is it transparent..or like a umount, convert, mount..or do you like have to import to a whole new partition?
Pointers to any docs of this sort would work for an answer
Thanx,
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
[email protected] Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Quoted 22 lines · Rik van Riel
Quoted 9 lines · Chris Evans
Quoted 3 lines · Chris Mason
Quoted 2 lines
Could someone create one single patch for the 2.4.0 ?
I put all the code into CVS, and Yura is making the official patch now.
Since 2.4.0 final should fix a few i/o performance issues (particuarly under heavy write loads), a quick few ext2 vs. reiserfs benchmarks would make very interesting reading ;-)
An easy way to gain a performance edge on ext2 would be to do proper write clustering in the reiserfs ->writepage() function... </hint>
regards,
Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose...
Quoted 8 lines
http://www.surriel.com/http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
Quoted 4 lines · Admin Mailing Lists
Is ext2 upgradable to reiserfs or ext3?
If so, is it transparent..or like a umount, convert, mount..or do you like have to import to a whole new partition?
ext2 is upgradable to ext3; after you have created a journal on the filesystem (either by hand or using tune2fs) you can
remount the filesystem as ext3. If it turns out you don't
like ext3, you can even go back to ext2 by unmounting the ext3 fs and remounting it ext2.
Going to reiserfs will require a reformat of your partition, because the format is completely different.
regards,
Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
In reply to Admin Mailing ListsQuoted 1 line
Is ext2 upgradable to reiserfs or ext3?
You can live up and downgrade between ext2 and ext3. For ext2->reiser and back you need to backup/restore or use a new partition currently - unless someone has tools I've not seen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
thanx everybody
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
[email protected] Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Quoted 7 lines · Alan Cox
Quoted 1 line
Is ext2 upgradable to reiserfs or ext3?
You can live up and downgrade between ext2 and ext3. For
ext2->reiserand back you need to backup/restore or use a new partition currently - unless someone has tools I've not seen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] reiserfs patch for 2.4.0-prerelease (dbench runs)
In reply to Chris MasonHi,
I ran a few more benchmarks on 2.4.0 final with 3.6.24. The results were a little susprising (all on the same box, just after boot, no X):
MB/s user system cpu time
3.6.24 7.1 54.0 177,6 25% 14:57.5
3.6.24 14.5 53.2 152.4 47% 7:15.7
3.6.24 5.6 55.6 191.0 22% 18:36.4
reiserfs can do well, but notice how the system cpu seconds varies... I am not seeing such wild differences in ext2 runs, impling that they are due to something in reiserfs?
Ed Tomlinson
Quoted 21 lines · Ed Tomlinson
Hi,
I have been doing some dbench runs with the original and latest (Jan 4 22:xx) prerelease.diff kernels. Looks like both the latest kernels and the reiserfs patch both are costing some performance.
prerelease
MB/s user system cpu time
ext2 14.6 50.5s 76.4s 29% 7:14.9m
ext2 12.6 50.9s 76.7s 25% 8:23.6mreiser 14.5 53.8s 149.2s 46% 7:16.1m
reiser 10.7 54.1s 154.5s 35% 9:49.9mprerelease (2.4.0 jan 4 22:xx)
MB/s user system cpu time
ext2 10.5 52.8s 81.5s 22% 10:02.3mreiser 5.8 54.6s 198.5s 23% 18:12.5m
reiser 6.4 55.1s 188.7s 24% 16.19.3m
Quoted 8 lines
Using the notail reiserfs mount option improves the reiserfs numbers 10-20% with both kernels.
All benchmarks run on a K6-III 400 with 128M just after boot with no X running.
Comments?
Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/