linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Wysochanski <davidw@netapp.com>
To: Chris Mason <mason@suse.com>
Cc: akpm@osdl.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: reiserfs and SCSI oops seen in 2.6.9-rc2 with local SCSI diskIO
Date: Tue, 05 Oct 2004 07:51:38 -0400	[thread overview]
Message-ID: <41628ACA.2020205@netapp.com> (raw)
In-Reply-To: <1096937103.6679.4.camel@watt.suse.com>

Chris Mason wrote:
> On Fri, 2004-09-24 at 11:03 -0400, David Wysochanski wrote:
>  > I can reproduce this pretty easily with local disk.
>  >
>  > Here's some details about my setup (attached is the
>  > full kernel config):
>  > - dell 2650 (dual xeon, hyperthreading disabled)
>  > - 1 local SCSI disk (root volume)
>  > - 2 local SCSI disks (data), each with 10 partitions
>  > of 100MB each, 6 of them reiserfs filesystems, 3 of them
>  > ext3, and 3 of them ext2 (total of 20 unique filesystems)
>  > - one instance of test program running on each of the
>  > 20 filesystems
>  >
>  > Sorry, but at this time I can't share the test program itself
>  > (I'm working on that).  Let me try to describe it though.
> 
> I think this is a bug in how reiserfs deals with small filesystems.
> There are a few different cases where it will try to use bitmap #2 even
> when there is only 1 bitmap.  Each of your test filesystems will need
> only 1 bitmap for reiserfs, so while it is a valid bug, it's not the one
> you were originally trying to reproduce.
> 
> This patch should do it (against 2.6.9-rc3).  Thanks to Jan Kara for
> finding this bug.
> 
> -chris
> 
> On small filesystems (<128M), make sure not to reference bitmap blocks that
> don't exist.
> 
> Index: linux.269rc3/fs/reiserfs/bitmap.c
> ===================================================================
> --- linux.269rc3.orig/fs/reiserfs/bitmap.c      2004-08-18 
> 09:38:50.000000000 -0400
> +++ linux.269rc3/fs/reiserfs/bitmap.c   2004-10-04 20:19:42.000000000 -0400
> @@ -236,6 +236,9 @@ static int bmap_hash_id(struct super_blo
>         if (!bm)
>             bm = 1;
>      }
> +    /* this can only be true when SB_BMAP_NR = 1 */
> +    if (bm >= SB_BMAP_NR(s))
> +       bm = 0;
>      return bm;
>  }
>  
> @@ -293,6 +296,10 @@ static int scan_bitmap (struct reiserfs_
>  
>      get_bit_address (s, *start, &bm, &off);
>      get_bit_address (s, finish, &end_bm, &end_off);
> +    if (bm > SB_BMAP_NR(s))
> +        return 0;
> +    if (end_bm > SB_BMAP_NR(s))
> +        end_bm = SB_BMAP_NR(s);
>  
>      /* When the bitmap is more than 10% free, anyone can allocate.
>       * When it's less than 10% free, only files that already use the
> @@ -313,6 +320,7 @@ static int scan_bitmap (struct reiserfs_
>             if (nr_allocated)
>                 goto ret;
>          }
> +       /* we know from above that start is a reasonable number */
>         get_bit_address (s, *start, &bm, &off);
>      }
>  
> @@ -1050,9 +1058,10 @@ int reiserfs_allocate_blocknrs(reiserfs_
>  {
>      int initial_amount_needed = amount_needed;
>      int ret;
> +    struct super_block *s = hint->th->t_super;
>  
>      /* Check if there is enough space, taking into account reserved 
> space */
> -    if ( SB_FREE_BLOCKS(hint->th->t_super) - 
> REISERFS_SB(hint->th->t_super)->reserved_blocks <
> +    if ( SB_FREE_BLOCKS(s) - REISERFS_SB(s)->reserved_blocks <
>          amount_needed - reserved_by_us)
>          return NO_DISK_SPACE;
>      /* should this be if !hint->inode &&  hint->preallocate? */
> @@ -1072,6 +1081,8 @@ int reiserfs_allocate_blocknrs(reiserfs_
>  
>      /* find search start and save it in hint structure */
>      determine_search_start(hint, amount_needed);
> +    if (hint->search_start >= SB_BLOCK_COUNT(s))
> +        hint->search_start = SB_BLOCK_COUNT(s) - 1;
>  
>      /* allocation itself; fill new_blocknrs and preallocation arrays */
>      ret = blocknrs_and_prealloc_arrays_from_search_start
> 
> 
> 
> 

Thanks - will try this patch and let you know.



      reply	other threads:[~2004-10-05 11:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-24 15:03 reiserfs and SCSI oops seen in 2.6.9-rc2 with local SCSI disk IO David Wysochanski
2004-09-24 15:18 ` Matthew Wilcox
2004-09-24 15:42   ` David Wysochanski
2004-09-24 17:58     ` Christoph Hellwig
2004-09-27 20:44     ` Chris Mason
2004-09-24 19:39 ` Barry K. Nathan
2004-09-24 19:42   ` David Wysochanski
2004-10-05  0:45 ` Chris Mason
2004-10-05 11:51   ` David Wysochanski [this message]

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=41628ACA.2020205@netapp.com \
    --to=davidw@netapp.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mason@suse.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;
as well as URLs for NNTP newsgroup(s).