public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Alex Tomas <bzzz@tmi.comex.ru>
Cc: linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net,
	William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [PATCH] concurrent inode allocation for ext2 against 2.5.64
Date: Sat, 15 Mar 2003 13:51:58 -0800	[thread overview]
Message-ID: <20030315135158.6d5fef1a.akpm@digeo.com> (raw)
In-Reply-To: <m365qk1gzx.fsf@lexa.home.net>

Alex Tomas <bzzz@tmi.comex.ru> wrote:
>
> 
> hi!
> 
> here is the patch for ext2 concurrent inode allocation. should be applied
> on top of previous concurrent-balloc patch. tested on dual p3 for several
> hours of stress-test + fsck. hope someone test it on big iron ;)
> 


> ...
> +void ext2_reserve_inode (struct super_block * sb, int group, int dir)
> +{

This can have static scope.  And, please, no spaces after the function name,
nor after the `*' thingy.  ext2 is all over the place in this regard and I'm
slowly trying to get it consistent.

I'm not sure that skipping setting s_dirt is desirable.  Sure, we haven't
actually altered the superblock.  But we sort-of "virtually dirtied" it.  The
superblock is now out-of-date and we should sync it.

It could be that not writing the superblock for a week is an OK thing to do. 
inode and block allocation counts are something which fsck can trivially fix
up.  But at the cost of a single sector write per five seconds I think it's
best to keep the superblock more up-to-date.

I'll make the same change to the block allocator patches.

>  struct ext2_bg_info {
>  	u8 debts;
>  	spinlock_t balloc_lock;
> +	spinlock_t ialloc_lock;
>  	unsigned int reserved;
>  } ____cacheline_aligned_in_smp;
> 

hm, I wonder if this should be in a separate cacheline.  We may as well use a
single lock if they're this close together.  Bill, can you test that
sometime?


diff -puN fs/ext2/ialloc.c~ext2-ialloc-no-lock_super-fixes fs/ext2/ialloc.c
--- 25/fs/ext2/ialloc.c~ext2-ialloc-no-lock_super-fixes	2003-03-15 13:36:14.000000000 -0800
+++ 25-akpm/fs/ext2/ialloc.c	2003-03-15 13:40:43.000000000 -0800
@@ -63,7 +63,17 @@ error_out:
 	return bh;
 }
 
-void ext2_reserve_inode (struct super_block * sb, int group, int dir)
+/*
+ * Speculatively reserve an inode in a blockgroup which used to have some
+ * spare ones.  Later, when we come to actually claim the inode in the bitmap
+ * it may be that it was taken.  In that case the allocator will undo this
+ * reservation and try again.
+ *
+ * The inode allocator does not physically alter the superblock.  But we still
+ * set sb->s_dirt, because the superblock was "logically" altered - we need to
+ * go and add up the free inodes counts again and flush out the superblock.
+ */
+static void ext2_reserve_inode(struct super_block *sb, int group, int dir)
 {
 	struct ext2_group_desc * desc;
 	struct buffer_head *bh;
@@ -72,7 +82,7 @@ void ext2_reserve_inode (struct super_bl
 	if (!desc) {
 		ext2_error(sb, "ext2_reserve_inode",
 			"can't get descriptor for group %d", group);
-	return;
+		return;
 	}
 
 	spin_lock(&EXT2_SB(sb)->s_bgi[group].ialloc_lock);
@@ -82,11 +92,11 @@ void ext2_reserve_inode (struct super_bl
 		desc->bg_used_dirs_count =
 			cpu_to_le16(le16_to_cpu(desc->bg_used_dirs_count) + 1);
 	spin_unlock(&EXT2_SB(sb)->s_bgi[group].ialloc_lock);
-
+	sb->s_dirt = 1;
 	mark_buffer_dirty(bh);
 }
 
-void ext2_release_inode (struct super_block * sb, int group, int dir)
+static void ext2_release_inode(struct super_block *sb, int group, int dir)
 {
 	struct ext2_group_desc * desc;
 	struct buffer_head *bh;
@@ -105,7 +115,7 @@ void ext2_release_inode (struct super_bl
 		desc->bg_used_dirs_count =
 			cpu_to_le16(le16_to_cpu(desc->bg_used_dirs_count) - 1);
 	spin_unlock(&EXT2_SB(sb)->s_bgi[group].ialloc_lock);
-
+	sb->s_dirt = 1;
 	mark_buffer_dirty(bh);
 }
 

_



  parent reply	other threads:[~2003-03-15 21:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-15 21:01 [PATCH] concurrent inode allocation for ext2 against 2.5.64 Alex Tomas
2003-03-15 21:17 ` William Lee Irwin III
2003-03-15 21:51 ` Andrew Morton [this message]
2003-03-15 22:06   ` William Lee Irwin III
2003-03-16  8:50     ` William Lee Irwin III
2003-03-15 22:02 ` William Lee Irwin III
2003-03-15 22:23   ` William Lee Irwin III
2003-03-15 22:37   ` Andrew Morton
2003-03-15 22:58     ` William Lee Irwin III
2003-03-15 23:08       ` William Lee Irwin III
2003-03-15 23:18         ` William Lee Irwin III
2003-03-15 23:40   ` William Lee Irwin III
2003-03-16  8:25 ` Martin J. Bligh

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=20030315135158.6d5fef1a.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=bzzz@tmi.comex.ru \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox