On Sat, Jun 14, 2008 at 7:43 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > 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?
Hi, It's a good idea, perhaps I can add a journal layer on top of disk to do the mapping transparently. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
