mirror of https://lore.kernel.org/lkml/
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome