All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: reiserfs-list@namesys.com
Subject: Re: [PATCH] new data logging and quota patches available
Date: 22 Feb 2003 11:12:32 -0500	[thread overview]
Message-ID: <1045930351.16042.377.camel@tiny.suse.com> (raw)
In-Reply-To: <1045926958.16042.366.camel@tiny.suse.com>

And here's one more patch for those of you that want to experiment a
little.  reiserfs_dirty_inode gets called to log the inode every time
the vfs layer does an atime/mtime/ctime update, which is one of hte
reasons mounting with -o noatime and -o nodiratime makes things faster. 
We had to do this because otherwise kswapd can end up trying to write
inodes, which can lead to deadlock as he tries to wait on the log.

One of the patches in my data logging directory is kinoded-8, which
changes things so a new kinoded does all inode writeback instead of
kswapd.

That means that if you apply up to 05-data-logging-36 and then apply
09-kinoded-8 (you won't need any of the other quota patches), you can
also apply this patch.  It changes reiserfs to leave inodes dirty, which
saves us lots of time on atime/mtime updates.

I'l upload this after it gets a little additional testing, but wanted to
include it here in case anyone else was interested in benchmarking.

--- linux.suse.1/fs/reiserfs/inode.c	2003-02-20 11:22:08.000000000 -0500
+++ linux.suse/fs/reiserfs/inode.c	2003-02-20 16:13:28.000000000 -0500
@@ -1492,12 +1498,19 @@
 ** does something when called for a synchronous update.
 */
 void reiserfs_write_inode (struct inode * inode, int do_sync) {
-
+    struct reiserfs_transaction_handle th;
     if (inode->i_sb->s_flags & MS_RDONLY) {
         reiserfs_warning("clm-6005: writing inode %lu on readonly FS\n", 
 	                  inode->i_ino) ;
         return ;
     }
+
+    lock_kernel() ;
+    journal_begin(&th, inode->i_sb, 1) ;
+    reiserfs_update_sd (&th, inode);
+    journal_end(&th, inode->i_sb, 1) ;
+    unlock_kernel() ;
+
     /* memory pressure can sometimes initiate write_inode calls with sync == 1,
     ** these cases are just when the system needs ram, not when the 
     ** inode needs to reach disk for safety, and they can safely be
--- linux.suse.1/fs/reiserfs/super.c	2003-02-20 11:22:08.000000000 -0500
+++ linux.suse/fs/reiserfs/super.c	2003-02-20 20:07:06.000000000 -0500
@@ -421,15 +422,18 @@
 	                  inode->i_ino) ;
         return ;
     }
-    lock_kernel() ;
-
-    /* this is really only used for atime updates, so they don't have
-    ** to be included in O_SYNC or fsync
+    /* this is used for atime updates, so they don't have
+    ** to be included in O_SYNC or fsync, but if we are nesting in to
+    ** a transaction, journal_begin/end is free, so we might as well
+    ** log the inode now (plus quota depends on it)
     */
-    journal_begin(&th, inode->i_sb, 1) ;
-    reiserfs_update_sd (&th, inode);
-    journal_end(&th, inode->i_sb, 1) ;
-    unlock_kernel() ;
+    if (reiserfs_transaction_running(inode->i_sb)) {
+	lock_kernel() ;
+	journal_begin(&th, inode->i_sb, 1) ;
+	reiserfs_update_sd (&th, inode);
+	journal_end(&th, inode->i_sb, 1) ;
+	unlock_kernel() ;
+    }
 }
 
 static void reiserfs_clear_inode (struct inode *inode)


 





  reply	other threads:[~2003-02-22 16:12 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-21 23:32 [PATCH] new data logging and quota patches available Chris Mason
2003-02-21 23:52 ` Philippe Gramoullé
2003-02-22 12:41 ` Dieter Nützel
2003-02-22 15:15   ` Chris Mason
2003-02-22 16:12     ` Chris Mason [this message]
2003-02-23  0:50       ` Manuel Krause
2003-02-23  1:04         ` Manuel Krause
2003-02-23 14:50           ` Chris Mason
2003-02-23 17:18           ` Chris Mason
2003-02-23 17:37             ` Marc-Christian Petersen
2003-02-23 18:39               ` Marc-Christian Petersen
2003-02-23 19:33                 ` Chris Mason
2003-02-24 18:01                   ` Marc-Christian Petersen
2003-02-24  1:42             ` Manuel Krause
2003-02-24 14:08               ` Chris Mason
2003-02-24 17:45                 ` Manuel Krause
2003-02-24 22:19                   ` Manuel Krause
2003-02-28  8:10                     ` Manuel Krause
2003-02-28 13:32                       ` Chris Mason
2003-03-06  2:49                         ` Manuel Krause
2003-03-06  3:46                           ` Chris Mason
2003-03-06  4:03                             ` Manuel Krause
2003-03-08 14:13                               ` Manuel Krause
2003-03-09 16:39                                 ` Chris Mason
2003-03-09 17:07                                   ` Manuel Krause
2003-03-09 17:24                                     ` Chris Mason
2003-03-09 17:39                                       ` Manuel Krause
2003-03-09 18:12                                         ` Chris Mason
2003-03-11  1:42                                         ` Chris Mason
2003-03-11 20:46                                         ` Chris Mason
2003-03-12  7:38                                           ` Oleg Drokin
2003-03-12 13:22                                             ` Chris Mason
2003-03-12 13:28                                               ` Oleg Drokin
2003-03-12 13:41                                                 ` Chris Mason
2003-03-12 14:43                                           ` Manuel Krause
2003-03-12 14:55                                             ` Chris Mason
2003-03-12 19:25                                             ` Hans Reiser
2003-03-13  2:01                                               ` Manuel Krause
2003-02-24 17:59               ` Marc-Christian Petersen
2003-02-24 18:05                 ` Marc-Christian Petersen
2003-02-24 18:46                   ` Chris Mason
2003-02-24 18:08                 ` Chris Mason
2003-02-24 18:11                   ` Marc-Christian Petersen
2003-02-23 14:56         ` Chris Mason
2003-02-22 13:54 ` Oleg Drokin
2003-02-22 14:17   ` Chris Mason
2003-02-25 15:31   ` Ookhoi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1045930351.16042.377.camel@tiny.suse.com \
    --to=mason@suse.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.