From: Davidlohr Bueso <dave@gnu.org>
To: Maurizio Lombardi <m.lombardi85@gmail.com>
Cc: util-linux@vger.kernel.org
Subject: Re: mkfs.minix V3 is broken
Date: Sun, 27 Nov 2011 23:03:38 +0100 [thread overview]
Message-ID: <1322431418.3213.7.camel@offbook> (raw)
In-Reply-To: <CAMtsiiDrWGKthY52+HT5r19g9EFRG2NHKMD3vni-SeaMNfuGDg@mail.gmail.com>
On Tue, 2011-11-22 at 10:03 +0100, Maurizio Lombardi wrote:
> On Mon, Nov 21, 2011 at 11:06 PM, Davidlohr Bueso <dave@gnu.org> wrote:
> >
> > Most of the work I did on supporting v3 was based on the kernel's
> > implementation and the mkfs shipped with minix (by ast), so a lot of
> > what you say makes sense. I've taken a quick look at the changes and
> > most are bugs are pretty straightforward, except:
> >
> > - mkfs.minix: The total number of zones is limited to 65536 only on V1
> > filesystems
> >
> > Unless I'm missing something, this doesn't really change any logic.
>
> Sorry, probably the commit message is not very well written... However
> this commit fixes a very nasty bug, let me explain why....
> Look at what the code did *before* my patch:
>
> if (fs_version == 3)
> magic = MINIX3_SUPER_MAGIC;
> if (fs_version == 2) {
> if (namelen == 14)
> magic = MINIX2_SUPER_MAGIC;
> else
> magic = MINIX2_SUPER_MAGIC2;
> } else {
> if (BLOCKS > MINIX_MAX_INODES)
> BLOCKS = MINIX_MAX_INODES;
> }
>
> Can you see what happens if fs_version is == 3 ?
> The total number of blocks is restricted to a maximum of 65536 both
> with V1 and V3 filesystems, this is wrong because the total number of
> blocks in V3 is a 32 bit number (the same of V2). With this
> realization, it is really simple to fix the bug, and this is exactly
> what I did:
Oh, yes, my bad, we should definitely have more blocks with v3.
I made a couple of filesystems with your changes and things look good,
specially incrementing the amount of inodes. The 60 character filename
was already featured but it's good to specify it explicitly as well.
Karel, unless you have any objections please pull these changes in.
Thanks,
Davidlohr
>
> if (fs_version == 3)
> magic = MINIX3_SUPER_MAGIC;
> - if (fs_version == 2) {
> +else if (fs_version == 2) {
> if (namelen == 14)
> magic = MINIX2_SUPER_MAGIC;
> else
> magic = MINIX2_SUPER_MAGIC2;
> } else {
> if (BLOCKS > MINIX_MAX_INODES)
> BLOCKS = MINIX_MAX_INODES;
> }
>
> >
> > I'll give the changes a proper test over the weekend.
>
> Ok, thanks.
> In case you accept the changes I did, this is the github repository
> link with read-only access from where you can pull the changes from:
>
> git://github.com/maurizio-lombardi/util-linux.git
>
> Regards,
next prev parent reply other threads:[~2011-11-27 22:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 19:40 mkfs.minix V3 is broken Maurizio Lombardi
2011-11-21 22:06 ` Davidlohr Bueso
2011-11-22 9:03 ` Maurizio Lombardi
2011-11-22 10:05 ` Maurizio Lombardi
2011-11-22 10:54 ` Karel Zak
2011-11-27 22:03 ` Davidlohr Bueso [this message]
2011-11-28 9:27 ` Karel Zak
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=1322431418.3213.7.camel@offbook \
--to=dave@gnu.org \
--cc=m.lombardi85@gmail.com \
--cc=util-linux@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).