linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Alexey Lyashkov <alexey.lyashkov@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 2/3] Fix panic with journal superblock flags printing.
Date: Thu, 22 Nov 2018 16:23:27 -0500	[thread overview]
Message-ID: <20181122212327.GA26402@thunk.org> (raw)
In-Reply-To: <EC847396-EE31-4F96-B8A9-3457FD1AC9F5@gmail.com>

On Thu, Nov 22, 2018 at 07:24:17AM +0300, Alexey Lyashkov wrote:
> 1024 is jbd superblock size, and this constant widely used over e2fsprogs code.
> from this particular case it’s clear bug as jsb_buffer defined as.
> >>
>         char                    jsb_buffer[1024];

The jbd superblock size is 1024 bytes --- just as the ext4 superblock
is only 1024 bytes.  It may be *stored* in a 4k block, and the size of
the super block has nothingm to do with the size of the file system
block size.

It gets used here:

	if (exp_block_size != (int) ntohl(jsb->s_blocksize))
		fprintf(f, "Journal block size:       %u\n",
			(unsigned int)ntohl(jsb->s_blocksize));

The normal case is when the journal superblock size is the same as the
file system block size, and in that case, there's no reason to print
the journal block size.  It *can* happen where the journal block size
can be different from the file system block size.  The most likely
case is the one where an external journal is in use, and the external
journal is shared between two file systems, one which uses (say) a 4k
block size, and the other uses (say) a 1k block size.  The data
structures support this mode, but what we don't have is e2fsck support
for handling a journal replay where the journal needs to be replayed
to two different file systems --- especially if one of the block
device is temporarily unavailable.

So that's why this is there, and in fact it's intentional that it's
done this way.

Cheers,

						- Ted

  reply	other threads:[~2018-11-23  8:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19  9:16 [PATCH 0/3] debugfs fixes alexey.lyashkov
2018-11-19  9:16 ` [PATCH 1/3] block number output fix alexey.lyashkov
2018-11-21 23:33   ` Theodore Y. Ts'o
2018-11-19  9:16 ` [PATCH 2/3] Fix panic with journal superblock flags printing alexey.lyashkov
2018-11-21 23:54   ` Theodore Y. Ts'o
2018-11-22  4:24     ` Alexey Lyashkov
2018-11-22 21:23       ` Theodore Y. Ts'o [this message]
2018-11-19  9:16 ` [PATCH 3/3] add support to check a journal checksum v1 while journal dump alexey.lyashkov
2018-11-22  0:07   ` Theodore Y. Ts'o
2018-11-22  5:08     ` Alexey Lyashkov

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=20181122212327.GA26402@thunk.org \
    --to=tytso@mit.edu \
    --cc=alexey.lyashkov@gmail.com \
    --cc=linux-ext4@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).