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 /.) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
