Re: grub-probe detects ext4 wronly as ext2

[Bean]

On Fri, Jul 4, 2008 at 8:00 PM, Javier Martín <address@hidden> wrote:
> 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.

Hi,

Actually, I don't see the point of this discussion. The worst case
scenario is hanging grub, instead of report a unknown file system
error. The end result the same, user can't boot from this partition.
The point here is that we should try our best to read from it. If it's
indeed incompatible, there is nothing we can do.

About the flags, no one can guarantee that the incompat bit would
result in an unreadable fs. The journal is a good example. Even with
journal enabled, we can read from it most of the time. Note that the
/boot directory is rarely touched, and we sync twice when modifying
it. You may argue that there is still a chance of failure. Well, there
certainly is, but should we disable install to ext3 ?

-- 
Bean