Messages in this thread Patch in this message | | | Date | Mon, 29 Nov 1999 17:54:07 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [PATH] A few things for immediate cleanup. |
| |
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:
--- 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
- 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/
| |