All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	The development of GNU GRUB <grub-devel@gnu.org>,
	Peter Jones <pjones@redhat.com>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Chris Murphy <lists@colorremedies.com>
Subject: Re: [GRUB PATCH] xfs: accept filesystem with sparse inodes
Date: Sat, 19 May 2018 11:52:44 -0600	[thread overview]
Message-ID: <CAJCQCtQxE7W=M3fp6f=1MXKqgG8sZusMoL3KqNN0VM6cHbd5Vg@mail.gmail.com> (raw)
In-Reply-To: <20180516090011.GA24959@router-fw-old.local.net-space.pl>

On Wed, May 16, 2018 at 3:00 AM, Daniel Kiper <dkiper@net-space.pl> wrote:
> On Tue, May 15, 2018 at 02:55:55PM -0500, Eric Sandeen wrote:
>> The sparse inode metadata format became a mkfs.xfs default in
>> xfsprogs-4.16.0, and such filesystems are now rejected by grub as
>> containing an incompatible feature.
>>
>> In essence, this feature allows xfs to allocate inodes into fragmented
>> freespace.  (Without this feature, if xfs could not allocate contiguous
>> space for 64 new inodes, inode creation would fail.)
>>
>> In practice, the disk format change is restricted to the inode btree,
>> which as far as I can tell is not used by grub.  If all you're doing
>> today is parsing a directory, reading an inode number, and converting
>> that inode number to a disk location, then ignoring this feature
>> should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
>>
>> I did some brief testing of this patch by hacking up the regression
>> tests to completely fragment freespace on the test xfs filesystem, and
>> then write a large-ish number of inodes to consume any existing
>> contiguous 64-inode chunk.  This way any files the grub tests add and
>> traverse would be in such a fragmented inode allocation.  Tests passed,
>> but I'm not sure how to cleanly integrate that into the test harness.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
> Eric, thank you for posting the patch. LGTM.
>
> Chris, may I ask you to test it and add your "Tested-by:" if it works?

Fedora openQA (which caught the bug) now passes. I did a separate test
making sure sparse inode feature is enabled and grub-probe,
grub-install, grub-mkconfig report no problem. So yeah feel free to
Tested-by to me.

-- 
Chris Murphy

      reply	other threads:[~2018-05-19 17:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15 19:55 [GRUB PATCH] xfs: accept filesystem with sparse inodes Eric Sandeen
2018-05-16  9:00 ` Daniel Kiper
2018-05-19 17:52   ` Chris Murphy [this message]

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='CAJCQCtQxE7W=M3fp6f=1MXKqgG8sZusMoL3KqNN0VM6cHbd5Vg@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=sandeen@sandeen.net \
    /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.