All of lore.kernel.org
 help / color / mirror / Atom feed
* More fun with MinixFS V3
@ 2009-07-04 18:29 Doug Graham
  0 siblings, 0 replies; only message in thread
From: Doug Graham @ 2009-07-04 18:29 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-07-04 18:29 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-04 18:29 More fun with MinixFS V3 Doug Graham

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.