All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Copeland <me@bobcopeland.com>
To: Fabian Frederick <fabf@skynet.be>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
Date: Wed, 25 Jun 2014 16:28:06 -0400	[thread overview]
Message-ID: <20140625202806.GA20575@localhost> (raw)
In-Reply-To: <810210906.61891.1403726606049.open-xchange@webmail.nmp.skynet.be>

On Wed, Jun 25, 2014 at 10:03:26PM +0200, Fabian Frederick wrote:
> > >     bitmap_size = DIV_ROUND_UP(sbi->s_num_blocks, 8);
> > >
> > Agreed - even though the FS data structures support 64-bit block
> > count, I've never seen an OMFS fs with more than about 2M blocks
> > (typical device had 20 gigs w/ 8k blocks).  So it would make
> > sense to bail in omfs_fill_super if that number is greater than
> > 2^31 or so.
> We could use unsigned int for bitmap instead of int or simply u64 ?

It doesn't really make sense to be a signed int, sure -- but even so
making it a u64 without at least including a sanity check is probably
not the way to go.

OMFS allocates space for the entire free-space bitmap in memory, rather
than loading its blocks on demand.  That's admittedly pretty dumb, but I
did it so that I could eventually support those FSes without a free-space
bitmap (I've never been asked for that feature, though, and didn't have
ReplayTV myself, so I don't believe that actually happened).

If s_num_blocks won't fit in a u32, well then that's a pretty huge chunk of
memory to allocate, and would represent a disk much bigger than the ones
that were available when this FS was used on a few devices.

(As for why the designers used u64 for all data structures, I guess just
optimism?)

-- 
Bob Copeland %% www.bobcopeland.com

  reply	other threads:[~2014-06-25 20:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 18:17 [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc Fabian Frederick
2014-06-25 18:27 ` Linus Torvalds
2014-06-25 19:02   ` Bob Copeland
2014-06-25 20:03     ` Fabian Frederick
2014-06-25 20:28       ` Bob Copeland [this message]
2014-06-25 19:05 ` Bob Copeland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140625202806.GA20575@localhost \
    --to=me@bobcopeland.com \
    --cc=akpm@linux-foundation.org \
    --cc=fabf@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.