All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qi Yong <qiyong@fc-cn.com>
To: akpm@linux-foundation.org, jwboyer@redhat.com
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: [patch] minix zmap block counts calculation fix
Date: Mon, 04 Aug 2014 09:47:08 +0800	[thread overview]
Message-ID: <53DEE61C.8060202@fc-cn.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

Hello,

The original Linus' minix zmap blocks calculation was correct, in the
formula of: sbi->s_nzones - sbi->s_firstdatazone + 1. It is (sp->s_zones
- (sp->s_firstdatazone - 1) in the minix3 source code.

But a later patch (fs/minix: Verify bitmap block counts before mounting)
has changed it unfortunately as:
  sbi->s_nzones - (sbi->s_firstdatazone + 1).
This would show free blocks one block less than the real when the total
data blocks are in "full zmap blocks plus one".

commit 016e8d44bc06dd3322f26712bdd3f3a6973592d0
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Fri Aug 19 14:50:26 2011 -0400

This patch corrects that zmap blocks calculation and tidy a printk
message while at it.

Signed-off-by: Qi Yong <qiyong@fc-cn.com>

-- 
Qi Yong


[-- Attachment #2: mfs-zmap_blocks-fix.patch --]
[-- Type: text/plain, Size: 1254 bytes --]

diff --git a/fs/minix/bitmap.c b/fs/minix/bitmap.c
index 4bc50da..742942a 100644
--- a/fs/minix/bitmap.c
+++ b/fs/minix/bitmap.c
@@ -96,7 +96,7 @@ int minix_new_block(struct inode * inode)
 unsigned long minix_count_free_blocks(struct super_block *sb)
 {
 	struct minix_sb_info *sbi = minix_sb(sb);
-	u32 bits = sbi->s_nzones - (sbi->s_firstdatazone + 1);
+	u32 bits = sbi->s_nzones - sbi->s_firstdatazone + 1;
 
 	return (count_free(sbi->s_zmap, sb->s_blocksize, bits)
 		<< sbi->s_log_zone_size);
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index f007a33..3f57af1 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -267,12 +267,12 @@ static int minix_fill_super(struct super_block *s, void *data, int silent)
 	block = minix_blocks_needed(sbi->s_ninodes, s->s_blocksize);
 	if (sbi->s_imap_blocks < block) {
 		printk("MINIX-fs: file system does not have enough "
-				"imap blocks allocated.  Refusing to mount\n");
+				"imap blocks allocated.  Refusing to mount.\n");
 		goto out_no_bitmap;
 	}
 
 	block = minix_blocks_needed(
-			(sbi->s_nzones - (sbi->s_firstdatazone + 1)),
+			(sbi->s_nzones - sbi->s_firstdatazone + 1),
 			s->s_blocksize);
 	if (sbi->s_zmap_blocks < block) {
 		printk("MINIX-fs: file system does not have enough "

                 reply	other threads:[~2014-08-04  1:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=53DEE61C.8060202@fc-cn.com \
    --to=qiyong@fc-cn.com \
    --cc=akpm@linux-foundation.org \
    --cc=jwboyer@redhat.com \
    --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.