linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251
Date: Tue, 2 Jul 2019 13:33:01 -0400	[thread overview]
Message-ID: <20190702173301.GA3032@mit.edu> (raw)
In-Reply-To: <1562028814.2762.50.camel@HansenPartnership.com>

On Mon, Jul 01, 2019 at 05:53:34PM -0700, James Bottomley wrote:
> 
> Actually, we control the location of the IPL, so as long as mke2fs
> errors out if we get it wrong I can add an offset so it begins at
> sector 258.  Palo actually executed mke2fs when you initialize the
> partition so it can add any options it likes. I was also thinking I
> should update palo to support ext4 as well.

If you never going to resize the boot partition, because it's fixed
size, you might as we not waste space on the reserving blocks for
online resize.  So having the palo bootloader be very restrictive
about what features it enables probably makes sense.

> Well, we don't have to use badblocks to achieve this, but we would like
> a way to make an inode cover the reserved physical area of the IPL. 
> Effectively it's a single contiguous area on disk with specific
> absolute alignment constraints.  It doesn't actually matter if it
> appears in the directory tree.

If you don't mind that it is visible in the namespace, you could take
advantage of the existing mk_hugefile feature[1][2]

[1] http://man7.org/linux/man-pages/man5/mke2fs.conf.5.html
[2] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/mk_hugefiles.c

# cat >> /etc/mke2fs.conf < EOF

[fs_types]
    palo_boot = {
    	features = ^resize_inode
	blocksize = 1024		 
    	make_hugefiles = true
	num_hugefiles = 1
	hugefiles_dir = /palo
	hugefiles_name = IPL
	hugefiles_size = 214k
	hugefiles_align = 256k
	hugefiles_align_disk = true
    }
EOF
# mke2fs -T palo_boot /dev/sda1

Something like this will create a 1k block file system, containing a
zero-filled /palo/IPL which is 214k long, aligned with respect to the
beginning of the disk at an 256k boundary.  (This feature was
sponsored by the letters, 'S', 'M', and 'R'.  :-)

If you wanted it to be hidden from the file system you could just drop
the hugefiles_dir line above, and then after mounting the file system
run open the /IPL file and then execute the EXT4_IOC_SWAP_BOOT ioctl
on it.  This will move those blocks so they are owned by inode #5, an
inode reserved for the boot loader.

Cheers,

       	       	    	       - Ted

  reply	other threads:[~2019-07-02 17:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01 22:44 [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251 James Bottomley
2019-07-02  0:23 ` Theodore Ts'o
2019-07-02  0:53   ` James Bottomley
2019-07-02 17:33     ` Theodore Ts'o [this message]
2019-07-02 19:31       ` James Bottomley
2019-07-02 20:39         ` Theodore Ts'o
2019-07-03  0:37           ` James Bottomley
2019-07-05 16:25           ` Question about ext4 testing: need to produce a high depth extent tree to verify mapping code James Bottomley
2019-07-05 17:39             ` Matthew Wilcox
2019-07-05 18:49               ` James Bottomley
2019-07-05 21:40                 ` Darrick J. Wong
2019-07-06  4:02                 ` Theodore Ts'o

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=20190702173301.GA3032@mit.edu \
    --to=tytso@mit.edu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-parisc@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).