lkml.org 
[lkml]   [2009]   [Jul]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 4 Jul 2009 14:29:40 -0400
From"Doug Graham" <>
SubjectMore fun with MinixFS V3
I was just looking over an old thread about MinixFs V3 support and
starting to get worried that my tweaks to support blocksizes of 512
bytes (for a small filesystem with many small files) might be broken.
This is the thread here: http://lkml.org/lkml/2006/5/6/50.
The nblocks() routine in fs/minix/itree_common.c now looks like this:

static inline unsigned nblocks(loff_t size, struct super_block *sb)
{
int k = sb->s_blocksize_bits - 10;
unsigned blocks, res, direct = DIRECT, i = DEPTH;
blocks = (size + sb->s_blocksize - 1) >> (BLOCK_SIZE_BITS + k);
...
and what had be worred at first is that sb->s_blocksize_bits will be 9
with a blocksize of 512, which makes k negative. But all may not be lost,
since k is only used once after this, after adding BLOCK_SIZE_BITS (10)
to it. At least that makes it nonnegative again, but then the question
is: what exactly is being accomplished here? First we subtract 10,
then add it back? The result is effectively this:

blocks = (size + sb->s_blocksize - 1) >> sb->s_blocksize_bits

which looks entirely correct to me. Is there any reason the code couldn't
just be written this way to begin with?

--Doug


\
 
 \ /
  Last update: 2009-07-04 20:33    [from the cache]
©2003-2009