From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1K7FfD-0005E5-Mt for mharc-grub-devel@gnu.org; Fri, 13 Jun 2008 16:14:23 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7FfB-0005BG-OU for grub-devel@gnu.org; Fri, 13 Jun 2008 16:14:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7FfA-00059T-IE for grub-devel@gnu.org; Fri, 13 Jun 2008 16:14:20 -0400 Received: from [199.232.76.173] (port=37970 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7FfA-000594-7c for grub-devel@gnu.org; Fri, 13 Jun 2008 16:14:20 -0400 Received: from c60.cesmail.net ([216.154.195.49]:44262) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1K7Ff9-0003kV-Tl for grub-devel@gnu.org; Fri, 13 Jun 2008 16:14:20 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 13 Jun 2008 16:14:18 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 73F49619058 for ; Fri, 13 Jun 2008 16:14:18 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <1213372559.29669.14.camel@dv> Content-Type: text/plain Date: Fri, 13 Jun 2008 16:14:17 -0400 Message-Id: <1213388057.21899.20.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Some concern about the journal support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2008 20:14:22 -0000 On Sat, 2008-06-14 at 01:05 +0800, Bean wrote: > Please see if my last patch works. Basically, it use read_hook as an > indicator. If read_hook is not null, which means we need to get a > block location, it use the fs address. If read_hook is null, which > means we don't care about the location, it use the journal address. > This should fit the problem. My testing shows that we still have some problems with journal support. I could not read /home in grub-fstest, and it didn't work when I reverted your patch. It worked with the version immediately before you added journal support on May 20, but didn't work with the version where the journal support was added. After I returned to the current code, I could read /home again - apparently something changed on the filesystem in the meantime. Your patch should fix the issue with hardcoding block locations, if I understand correctly. 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. -- Regards, Pavel Roskin