Re: Some concern about the journal support

[Robert Millan]

On Fri, Jun 13, 2008 at 04:14:17PM -0400, Pavel Roskin wrote:
> 
> Your patch should fix the issue with hardcoding block locations, if I
> understand correctly.

Notice that hardcoding block locations only happens when core.img doesn't
fit in the post-mbr area.

Which is a situation we should try to avoid by making core.img small, which
means a smaller ext2.mod also helps ;-)

> I was asking where journal support would be beneficial in userspace at
> all.  And it has to be asked if journal support is useful at the boot
> time.
> 
> We have some code that is hard to get right and hard to test.  Yet it
> will be run every time an unclean ext3 filesystem is found at the boot
> time.  What are we gaining?  What is the situation where using the
> journal is beneficial?  How likely is it to happen?  Is it possible that
> we may be better off not using the journal?  How likely is that?
> 
> The standard use of the journal is to make the filesystem consistent
> after an unclean shutdown without having to run a time-consuming fsck.
> Since grub is not writing anything to the disk, consistency is not
> really important.  What's important got grub is reliability and ability
> to access all files on the filesystem.
> 
> > btw, the reiserfs driver is a little strange, it don't follow the
> > normal path of grub_fshelp_read_file, perhaps we just disable the
> > journal at the moment.
> 
> My impression is that we need to make journal support experimental and
> disabled by default for both ext3 and reiserfs.  It should only be
> enabled by default if there are a good arguments why it's useful and a
> testsuite to prove that it's reliable.

How about a separate module?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)