Re: [PATCH] Bug fix for ext2.c

[Robert Millan]

On Sun, Mar 15, 2009 at 12:56:26AM +0800, Bean wrote:
> On Sun, Mar 15, 2009 at 12:37 AM, Robert Millan <address@hidden> wrote:
> > On Sun, Mar 15, 2009 at 12:16:23AM +0800, Bean wrote:
> >> Hi,
> >>
> >> I've discovered a bug in ext2.c, inside grub_ext2_mount. The mount
> >> function must return GRUB_ERR_BAD_FS if something goes wrong, because
> >> grub_fs_probe would stop as soon as it sees a non-GRUB_ERR_BAD_FS
> >> error, thus preventing other fs driver from detecting the correct fs
> >> type. This patch fixes the problem.
> >
> > I think current behaviour is correct.  If a failure is triggered by
> > grub_disk_read(), from grub_fs_probe perspective it means something is
> > fucked up other than just "this is not the FS we're looking for", so it
> > should be aware of the difference.
> >
> > Or is grub_ext2_read_inode() failure the one that's causing trouble for
> > you?
> 
> Hi,
> 
> ext2 only reads the first two sectors in mount, which is normally ok ,
> but there are exceptions. For example, cpio filesystem could be less
> one sector. 

I don't understand what you mean here.  If grub_disk_read failed, this
indicates something's broken down in the disk layer doesn't it?  How is
the number of sectors related to this?

> Also, hostfs always return error in its read function,
> which would cause ext2 to fail. The effect can be seen in grub-fstest.
> hostfs is the first fs driver to register, and the last to query. When
> accessing the (host) device, ext2 cause it to fail before hostfs has a
> chance to see it.

Why does hostfs fail?  Is this intentional?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."