From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Chris Murphy <lists@colorremedies.com>
Cc: Dave Chinner <david@fromorbit.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
xfs list <linux-xfs@vger.kernel.org>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
linux-ext4@vger.kernel.org
Subject: Re: inline extents
Date: Thu, 20 Sep 2018 15:34:20 -0400 [thread overview]
Message-ID: <20180920193420.GA9343@thunk.org> (raw)
In-Reply-To: <CAJCQCtQyws4LVJKrNiFST4ajFXB5ViXx=oRWq98r=tppa+K8FQ@mail.gmail.com>
On Wed, Sep 19, 2018 at 09:18:16PM -0600, Chris Murphy wrote:
> > ext4 has inline data, too, so there's every chance grub will corrupt
> > ext4 filesystems with tit's wonderful new feature. I'm not sure if
> > the ext4 metadata cksums cover the entire inode and inline data, but
> > if they do it's the same problem as btrfs.
>
> I don't see inline used with a default mkfs, but I do see metadata_csum
The grub environment block is 1024 bytes, so unless you are using a 4k
inode size (the default is 256 bytes), the grub environment block
won't be an inline data file. So in practice, this won't be a
problem. So in practice this won't be a problem for ext4 today.
There are ways that grub can query the file system (using FIEMAP or
FS_IOC_GETFLAGS) to see whether or not the file is an inline file.
For xfs grub would also need to make sure the file isn't reflinked
file (which can also be queried using FIEMAP). That's fine for
inline, since a file won't magically change from stored in a block
versus inline, so grub can check this at grub setup time. But the
problem with reflink is that a file that was originally using a block
exclusively could later have that block be shared by another file, at
which point it's only safe to write the block using copy-on-write.
> I know some of the file systems have reserve areas for bootloader
> stuff. I'm not sure if that's preferred over bootloaders just getting
> their own partition and controlling it stem to stern however they
> want.
Ext4 had reserved the bootloader inode, and we have defined a way for
a bootloader to access it. The original intent was that not it just
be fore the environment block, but also the grub stage 1.5 or stage 2
loader. This would allow grub to just use a fixed list of blocks or
extents, and not need to understand the ext4 extents structures. We
added way this when, because we anticipated this would be easier for
grub than having it learn how to read ext4 extents structures.
Instead, the bootloader would at setup time use the EXT4_IOC_SWAP_BOOT
ioctl and then use a fixed list of blocks or block extents like LILO
used to do.
Of course, grub exceeded expectations and actually learned how to read
ext4 file systems, and probably we (the ext4 developers) should have
reached out to GRUB folks.
Cheers,
- Ted
prev parent reply other threads:[~2018-09-21 1:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJCQCtQVzmwey0GcuHmZ8=_XuqmrA24d4DDVVuX9vL3KYStwZg@mail.gmail.com>
[not found] ` <20180920014506.GL27618@dastard>
2018-09-20 3:18 ` inline extents Chris Murphy
2018-09-20 19:34 ` Theodore Y. Ts'o [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=20180920193420.GA9343@thunk.org \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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).