From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Some concern about the journal support
Date: Fri, 13 Jun 2008 16:14:17 -0400 [thread overview]
Message-ID: <1213388057.21899.20.camel@dv> (raw)
In-Reply-To: <ca0f59980806131005u7f2c375uf5d536e297598af6@mail.gmail.com>
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
next prev parent reply other threads:[~2008-06-13 20:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 9:05 Some concern about the journal support Bean
2008-06-13 10:01 ` Bean
2008-06-13 12:14 ` Bean
2008-06-13 15:55 ` Pavel Roskin
2008-06-13 17:05 ` Bean
2008-06-13 19:45 ` Isaac Dupree
2008-06-13 20:40 ` Pavel Roskin
2008-06-13 21:49 ` Isaac Dupree
2008-06-13 22:06 ` Pavel Roskin
2008-06-14 3:32 ` Bean
2008-06-14 4:11 ` Bean
2008-06-13 20:14 ` Pavel Roskin [this message]
2008-06-14 11:43 ` Robert Millan
2008-06-14 16:17 ` Bean
2008-06-14 17:32 ` Bean
2008-06-14 18:06 ` Robert Millan
2008-06-14 18:29 ` Bean
2008-06-14 18:48 ` Robert Millan
2008-06-14 18:14 ` Javier Martín
2008-06-16 1:27 ` Pavel Roskin
2008-06-16 19:02 ` Bean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1213388057.21899.20.camel@dv \
--to=proski@gnu.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.