grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-probe detects ext4 wronly as ext2


From: Javier Martín
Subject: Re: grub-probe detects ext4 wronly as ext2
Date: Fri, 04 Jul 2008 14:00:34 +0200

El vie, 04-07-2008 a las 19:29 +0800, Bean escribió:
> On Fri, Jul 4, 2008 at 6:34 PM, Javier Martín <address@hidden> wrote:
> > I know I promised not to keep posting but... I just cannot xD
> >
> > El vie, 04-07-2008 a las 14:49 +0800, Bean escribió:
> >> Hi,
> >>
> >> This is an example of good practice,  which check the driver
> >> by function, not by flags.
> > This will find and check core.img. As my previous post showed, one file
> > being readable in a partition with an incompatible flag does not
> > guarantee that every file will be. Thus, the conservative policy for
> > grub-probe would be to also check that the FS is "theoretically"
> > accesible (i.e. the ext2/whatever driver is fine with its flags) in
> > addition to the current "practical" check.
> 
> Yes, one file can't guarantee the whole fs is accessible, but it's a
> good indicator. Nothing can guarantee 100% success. Even without
> structure change, grub can still fail if the underlying fs is dirty.
> 
> >>
> >> The  flags are a little vague, for example,
> >> if they change btree structure in the future, this would introduce
> >> another flag, but we don't need to worry about it, because we don't
> >> use it at all.
> > The btree flag (and any of its modifications) is ROCOMPAT, which indeed
> > allows us not to worry about it at all, because our driver is read only.
> > The proposed patch addresses only INCOMPAT flags, and it even adds a
> > mechanism to ignore some of them because we deem them not to create real
> > incompatibilities (like needs-recovery).
> 
> It's just an example. We only use part of ext's structure, there is
> every chance that some part of it has been changed and we're not
> affected.
That's the point of categorizing new features in "rw-compat",
"ro-compat" and "incompat". The first two indicate changes that won't
affect any reader, while the latter warn readers that they will very
probably find incompatible metadata which they will not be able to
interpret. From the _current_ list of incompatible features:
compression, filetype, needs_recovery, journal_dev, meta_bg, extents,
64bit and flex_bg; we have implemented support for one (filetype) and
knowingly ignore another (needs_recovery). However, every other incompat
flag affects the metadata format in ways that cause strange failures
difficult for the user to trace, like the Godfather tune in my other
post being read as 256 bytes of zeros.

As an example, one of the _bg flags (meta_bg iIrc) means that inodes may
be lazily written to disk instead of every single one being initialized
by mke2fs, which speeds up the format process a lot. Given that our
driver does not know what to do with that "incompat" feature (and it
currently ignores it), if our driver met one of the inodes not yet
inited, we would read either "garbage" or even worse, metadata from
another extN filesystem that was there before the last mke2fs.

> 
> >>
> >> If we can ensure the boot partition can be accessed, then the problem
> >> is solved. Yes, there may be other partition using ext4 that we can't
> >> access, but remember that linux loader will check for signatures as
> >> well, a corrupted kernel would not be loaded. So the difference is
> >> merely the error message users sees, unknown filesystem or invalid
> >> kernel.
> > I didn't know the "linux" loader checked signatures. Do the "multiboot",
> > "multiboot2" and "bsd" loaders do the same? In the platforms where it is
> > able to load a file, does the "chainloader" loader perform any checks?
> > So in that cases difference would be between "unknown filesystem" and
> > "the FSM knows what".
> >
> 
> Yes, they all check for signatures. In fact, commands that deal with
> input file should always check for it first. If not, we need to fix
> that command.
They all check for _certain_ signatures in particular places, like
"multiboot" looking for the MB-info block and chainloader looking for
0x55aa (in i386-pc), but I already explained how a hypothetical new
incompatible feature like partial compression can make that system go
down the sink, because the block with the signature can well be fine but
other parts be read wrong.

> 
> >>
> >> And, grub WILL follow the evolution the extN, because it's the primary
> >> boot loader for linux. The only reason we don't have ext4 support at
> >> present is because it's not stable. If major distro starts to use it
> >> as default, we would have to support it as well.
> > Please... ReiserFS was used for long in many distros and GRUB2 didn't
> > support it until 1.96 - even with GRUB Legacy having implemented it long
> > ago. I literally waited years for it to be included! Besides, as I
> > already said, we cannot win in a race against the future: new features,
> > some of them incompatible, are introduced ""constantly"" (every few
> > years) in extN, and until we get to know about them and at least decide
> > whether they can be safely ignored, the sane behavior is to obey them
> > and reject access (except if the user override is enabled). Yes, we can
> > implement ext4 and possibly even before it's released as stable, but
> > could you please start implementing ext7 so that we don't have to worry
> > about its incompatibilities when it comes?
> 
> It's an ongoing process for grub. Besides, compatibility goes both
> ways. The developer of extN file system would also consider existing
> driver, significant change to the fs structure would not be as
> frequent.
> 
In the nearly eight years from ext2 release to the merge of ext3 into
the kernel, some incompatible features were introduced in ext2 proper,
like filetype and compression. Even now, with ext4 in development and
merged into the kernel less than five years after ext3, incompatible
features are being backported to ext2 like the lazy inode initializing I
mentioned earlier. Those can hit us HARD.

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

[Prev in Thread] Current Thread [Next in Thread]