lkml.org 
[lkml]   [1999]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATH] A few things for immediate cleanup.
Andrea Arcangeli wrote:
>
> On Mon, 29 Nov 1999, Martin Dalecki wrote:
>
> >Are you sure? If I remember the mcdx.c block strategy routine here
> >I think one could get surprised here ...
>
> The interface doesn't require the blockdevice driver to support requests
> with blocks shorter than hardblocksize.
>
> >So why comes it that it's possible to drive fs with less blocks through
> >RAID?
>
> raid remaps the device and the sector of the bh and that has nothing to do
> with the size of the bh or with the blocksize. raid act like as a virtual
> layer and the size doesn't change during the virt to phys translation.
>
> >This doesn't answer one question: Why do all the other filesystems
> >working fine
> >without it? In esp. for example the minixfs.
>
> Because it's buggy, so here the fix against 2.3.30pre3:

OK still one question bogs me: Why do we this check at the VFS layer.
Wouldn't be sifficient to do it where it really belongs:
The strategy routine or one level up in the block device handling?
(Maybe this is exactly what's already happaning. I will have to dig it
up.)
This way one wouldn't need to replicate the check code all over all
the filesystems and possible one could still get away without the
hard sector sizes array. (Which is still offending me by it's design
;-).

> --- 2.3.30pre3-alpha/fs/minix/inode.c.~1~ Tue Sep 14 14:35:13 1999
> +++ 2.3.30pre3-alpha/fs/minix/inode.c Mon Nov 29 17:45:02 1999
> @@ -177,6 +177,7 @@
> kdev_t dev = s->s_dev;
> const char * errmsg;
> struct inode *root_inode;
> + unsigned int hblock;
>
> /* N.B. These should be compile-time tests.
> Unfortunately that is impossible. */
> @@ -186,6 +187,11 @@
> panic("bad V2 i-node size");
>
> MOD_INC_USE_COUNT;
> +
> + hblock = get_hardblocksize(dev);
> + if (hblock && hblock > BLOCK_SIZE)
> + goto out_bad_hblock;
> +
> lock_super(s);
> set_blocksize(dev, BLOCK_SIZE);
> if (!(bh = bread(dev,1,BLOCK_SIZE)))
> @@ -322,11 +328,16 @@
> brelse(bh);
> goto out_unlock;
>
> +out_bad_hblock:
> + printk("MINIX-fs: blocksize too small for device.\n");
> + goto out;
> +
> out_bad_sb:
> printk("MINIX-fs: unable to read superblock\n");
> out_unlock:
> - s->s_dev = 0;
> unlock_super(s);
> + out:
> + s->s_dev = 0;
> MOD_DEC_USE_COUNT;
> return NULL;
> }
>
> >The NR_REQUESTS isn't used anywhere else and it's kernel internal
> >thing that shouldn't be exposed to user space. (it wasn't).
>
> When I gone to make the ll_rw_block layer bigmem capable I needed it from
> the outside to make sure to avoid deadlocks due OOM. That's why I think
> it's something that somebody (like the VM) may be interested about.
>
> >I doubt seriously if the result of this procedure give good results on
> >the average system out there. At least I would prefere much to have a
>
> I dubited too but Dave says that testcase is been large enough to
> represent to any kind of setup out there.
>
> >deductive
> >statement supporting it.
>
> Me too.
>
> Andrea

Lenin says: "Trust is good, control is better". So Dave please plese
give
some comments/explanations...

--
Marcin Dalecki

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.431 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site