linux-nilfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Nilfs2 and Grub2
@ 2012-05-01 10:38 Sven-Göran Bergh
       [not found] ` <1335868737.71789.YahooMailNeo-/W4/QBBOCLIMe+d1jY/0H5EhsgyP+Z75VpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Sven-Göran Bergh @ 2012-05-01 10:38 UTC (permalink / raw)
  To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

Hi list,

I have done some observations with the combination
grub2 and nilfs2 on the boot partition. It would
be valuable to know if anyone else has done similar
observations or if this is a {,/un}known problem.


After some harsh handling the system is rebooted
and grub2 hangs during stage 1.5-2. Once grub2 has
encountered this problem it is consistent. It will
hang on every consecutive boot.

However, if the filesystem (on a CF) is mounted by
another system there are no problems reported.
Furthermore, once the filesystem has been mounted
by another system grub2 has no problems booting it
again afterwards. There is no need to do anything
else with the fs than mounting it by another system
and then umount it again.
My preliminary analysis is:
 * Nilfs2 is left in a disturbed state, due to some
   rough handling (still unknown in detail).
 * A normal mount has no problem to recover the fs
   in such case.
 * Grub2 lacks some of the recovery features
   performed during a normal mount and will have
   problem reading files on the fs.

Currently I do not have a more exact description of
the problem. I still have to figure out exactly what
handling that triggers this state for the fs.


This is an embedded project and a previous version

is running grub legacy and ext2 without any signs of
similar problems. Grub legacy has never failed, even
with a (partly) corrupt ext2.

My own knowledge in the nilfs2/grub2 internals is
limited and it is hard to troubleshoot since I
have no recipe reproduction. However, I have observed
it on several occasions on our test systems. I am on
a tight schedule, but when time permits, I will try
to find a way to reproduce this.

Have anyone experienced similar behavior?

Brgds
/Sven

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Nilfs2 and Grub2
       [not found] ` <1335868737.71789.YahooMailNeo-/W4/QBBOCLIMe+d1jY/0H5EhsgyP+Z75VpNB7YpNyf8@public.gmane.org>
@ 2012-05-03  6:49   ` Ryusuke Konishi
       [not found]     ` <20120503.154904.13275655.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Ryusuke Konishi @ 2012-05-03  6:49 UTC (permalink / raw)
  To: svengbergh-nilfs-/E1597aS9LQAvxtiuMwx3w
  Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA

Hi,
On Tue, 1 May 2012 03:38:57 -0700 (PDT), Sven-Göran_Bergh wrote:
> Hi list,
> 
> I have done some observations with the combination
> grub2 and nilfs2 on the boot partition. It would
> be valuable to know if anyone else has done similar
> observations or if this is a {,/un}known problem.
> 
> 
> After some harsh handling the system is rebooted
> and grub2 hangs during stage 1.5-2. Once grub2 has
> encountered this problem it is consistent. It will
> hang on every consecutive boot.
> 
> However, if the filesystem (on a CF) is mounted by
> another system there are no problems reported.
> Furthermore, once the filesystem has been mounted
> by another system grub2 has no problems booting it
> again afterwards. There is no need to do anything
> else with the fs than mounting it by another system
> and then umount it again.
> My preliminary analysis is:
>  * Nilfs2 is left in a disturbed state, due to some
>    rough handling (still unknown in detail).
>  * A normal mount has no problem to recover the fs
>    in such case.
>  * Grub2 lacks some of the recovery features
>    performed during a normal mount and will have
>    problem reading files on the fs.
> 
> Currently I do not have a more exact description of
> the problem. I still have to figure out exactly what
> handling that triggers this state for the fs.
> 
> This is an embedded project and a previous version
> 
> is running grub legacy and ext2 without any signs of
> similar problems. Grub legacy has never failed, even
> with a (partly) corrupt ext2.
> 
> My own knowledge in the nilfs2/grub2 internals is
> limited and it is hard to troubleshoot since I
> have no recipe reproduction. However, I have observed
> it on several occasions on our test systems. I am on
> a tight schedule, but when time permits, I will try
> to find a way to reproduce this.
> 
> Have anyone experienced similar behavior?
> 
> Brgds
> /Sven

Thank you for reporting the issue in the nilfs2 boot loader of grub2.

Your analysis seems right to me.

The nilfs2 grub code looks to be lacking roll forwarding and crc
verification (the latter both for super blocks and log blocks).

It is incomplete, or rather I should say it took a good trade-off
between simplicity and reliability as an early practicable
implementation.

Actually it works without trouble in most cases since most checkpoints
coherently include files needed to boot up system even though that
omission may lead the boot loader to read not-updated files after
unclean shutdown.

In my opinion, nilfs2 grub code does not have to do recovery, but it
should scan the latest checkpoint in order to minimize troubles.
However, I don't know whether it's possible or not in the boot loader.

Of course, there is a possibility that simply an unknown bug caused
your trouble.  In that case, inserting debug print functions in the
nilfs2 grub code and booting up with it, would be helpful to narrow
down the cause of the problem.


Thanks,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Nilfs2 and Grub2
       [not found]     ` <20120503.154904.13275655.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
@ 2012-05-04  5:13       ` Jiro SEKIBA
  0 siblings, 0 replies; 3+ messages in thread
From: Jiro SEKIBA @ 2012-05-04  5:13 UTC (permalink / raw)
  To: Ryusuke Konishi
  Cc: svengbergh-nilfs-/E1597aS9LQAvxtiuMwx3w,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA

Hi,

I'm original author of the grub2 NILFS2 module.

Yes, it lacks roll back/forward or recovery to keep the boot loader simple.
It also prevent from unintentional boot, like old buggy kernel is used.

Aside from the way it works, the code itself is capable to boot from
any checkpoints.  It happens to choose the latest one.  The only thing
we need is the way to _choose_ the checkpoint from grub interface :(.

thanks

regards
-- 
Jiro SEKIBA <jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>

At Thu, 03 May 2012 15:49:04 +0900 (JST),
Ryusuke Konishi wrote:
> 
> Hi,
> On Tue, 1 May 2012 03:38:57 -0700 (PDT), Sven-Göran_Bergh wrote:
> > Hi list,
> > 
> > I have done some observations with the combination
> > grub2 and nilfs2 on the boot partition. It would
> > be valuable to know if anyone else has done similar
> > observations or if this is a {,/un}known problem.
> > 
> > 
> > After some harsh handling the system is rebooted
> > and grub2 hangs during stage 1.5-2. Once grub2 has
> > encountered this problem it is consistent. It will
> > hang on every consecutive boot.
> > 
> > However, if the filesystem (on a CF) is mounted by
> > another system there are no problems reported.
> > Furthermore, once the filesystem has been mounted
> > by another system grub2 has no problems booting it
> > again afterwards. There is no need to do anything
> > else with the fs than mounting it by another system
> > and then umount it again.
> > My preliminary analysis is:
> >  * Nilfs2 is left in a disturbed state, due to some
> >    rough handling (still unknown in detail).
> >  * A normal mount has no problem to recover the fs
> >    in such case.
> >  * Grub2 lacks some of the recovery features
> >    performed during a normal mount and will have
> >    problem reading files on the fs.
> > 
> > Currently I do not have a more exact description of
> > the problem. I still have to figure out exactly what
> > handling that triggers this state for the fs.
> > 
> > This is an embedded project and a previous version
> > 
> > is running grub legacy and ext2 without any signs of
> > similar problems. Grub legacy has never failed, even
> > with a (partly) corrupt ext2.
> > 
> > My own knowledge in the nilfs2/grub2 internals is
> > limited and it is hard to troubleshoot since I
> > have no recipe reproduction. However, I have observed
> > it on several occasions on our test systems. I am on
> > a tight schedule, but when time permits, I will try
> > to find a way to reproduce this.
> > 
> > Have anyone experienced similar behavior?
> > 
> > Brgds
> > /Sven
> 
> Thank you for reporting the issue in the nilfs2 boot loader of grub2.
> 
> Your analysis seems right to me.
> 
> The nilfs2 grub code looks to be lacking roll forwarding and crc
> verification (the latter both for super blocks and log blocks).
> 
> It is incomplete, or rather I should say it took a good trade-off
> between simplicity and reliability as an early practicable
> implementation.
> 
> Actually it works without trouble in most cases since most checkpoints
> coherently include files needed to boot up system even though that
> omission may lead the boot loader to read not-updated files after
> unclean shutdown.
> 
> In my opinion, nilfs2 grub code does not have to do recovery, but it
> should scan the latest checkpoint in order to minimize troubles.
> However, I don't know whether it's possible or not in the boot loader.
> 
> Of course, there is a possibility that simply an unknown bug caused
> your trouble.  In that case, inserting debug print functions in the
> nilfs2 grub code and booting up with it, would be helpful to narrow
> down the cause of the problem.
> 
> 
> Thanks,
> Ryusuke Konishi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-05-04  5:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-01 10:38 Nilfs2 and Grub2 Sven-Göran Bergh
     [not found] ` <1335868737.71789.YahooMailNeo-/W4/QBBOCLIMe+d1jY/0H5EhsgyP+Z75VpNB7YpNyf8@public.gmane.org>
2012-05-03  6:49   ` Ryusuke Konishi
     [not found]     ` <20120503.154904.13275655.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-05-04  5:13       ` Jiro SEKIBA

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).