Btrfs devel - Jun 2013 - Possible solution to the "open_ctree" boot bug ...

I am seeing a huge improvement in boot performance since doing a system 
wide file by file defragementation of metadata.  In fact in the four 
sequential boots since completing this process, I have not seen one 
open_ctree failure so far.  This leads me to suspect that the open_ctree 
boot failures that have been plaguing me since install have been related 
to metadata fragmentation.  So I would advise anyone else experiencing 
open_ctree boot problems to defragment their metatdata and see if that 
helps.  It certainly seems to have helped me in that regard.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

George Mitchell <george@chinilu.com> schrieb:
> I am seeing a huge improvement in boot performance since doing a system
> wide file by file defragementation of metadata.  In fact in the four
> sequential boots since completing this process, I have not seen one
> open_ctree failure so far.  This leads me to suspect that the open_ctree
> boot failures that have been plaguing me since install have been related
> to metadata fragmentation.  So I would advise anyone else experiencing
> open_ctree boot problems to defragment their metatdata and see if that
> helps.  It certainly seems to have helped me in that regard.
I suspect this observation comes from btrfs being able to faster initialize 
itself during kernel detection since you defragmented it. Try to add 
root_delay=2 to your kernel command line and see if it improves on this 
particular problem.

I had this myself and root_delay=1 fixed it for me. Before, in about 90% of 
all boots it came up with the ctree error. After, it never happened again.

Regards,
Kai

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

On 06/06/2013 01:58 PM, Kai Krakow wrote:
> George Mitchell <george@chinilu.com> schrieb:
>
>> I am seeing a huge improvement in boot performance since doing a system
>> wide file by file defragementation of metadata.  In fact in the four
>> sequential boots since completing this process, I have not seen one
>> open_ctree failure so far.  This leads me to suspect that the
open_ctree
>> boot failures that have been plaguing me since install have been
related
>> to metadata fragmentation.  So I would advise anyone else experiencing
>> open_ctree boot problems to defragment their metatdata and see if that
>> helps.  It certainly seems to have helped me in that regard.
> I suspect this observation comes from btrfs being able to faster initialize
> itself during kernel detection since you defragmented it. Try to add
> root_delay=2 to your kernel command line and see if it improves on this
> particular problem.
>
> I had this myself and root_delay=1 fixed it for me. Before, in about 90% of
> all boots it came up with the ctree error. After, it never happened again.
>
> Regards,
> Kai
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
Thanks,  I tried that route and it, unfortunately, did not do anything 
for me.  But the defragmentation continues to do the job every time.  I 
am now going to make everything on the OS side "nodatacow" and am 
expecting that will further relieve the problem. The problem NEVER 
occurs in a normal environment, only in the initrd environment.  There 
is something uniquely different about the initrd environment that 
triggers this problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 06/09/2013 01:24 AM, Kai Krakow wrote:
>
> Actually it should be called "rootdelay"... My fault...
>
Thanks again,  I have added it, will see what happens, I am looking for 
anything that might help at this point, so I am very appreciative!  - George

> Am 07.06.2013 01:48 schrieb "George Mitchell"
<george@chinilu.com
> <mailto:george@chinilu.com>>:
>
>     On 06/06/2013 01:58 PM, Kai Krakow wrote:
>
>         George Mitchell <george@chinilu.com
>         <mailto:george@chinilu.com>> schrieb:
>
>             I am seeing a huge improvement in boot performance since
>             doing a system
>             wide file by file defragementation of metadata.  In fact
>             in the four
>             sequential boots since completing this process, I have not
>             seen one
>             open_ctree failure so far.  This leads me to suspect that
>             the open_ctree
>             boot failures that have been plaguing me since install
>             have been related
>             to metadata fragmentation.  So I would advise anyone else
>             experiencing
>             open_ctree boot problems to defragment their metatdata and
>             see if that
>             helps.  It certainly seems to have helped me in that regard.
>
>         I suspect this observation comes from btrfs being able to
>         faster initialize
>         itself during kernel detection since you defragmented it. Try
>         to add
>         root_delay=2 to your kernel command line and see if it
>         improves on this
>         particular problem.
>
>         I had this myself and root_delay=1 fixed it for me. Before, in
>         about 90% of
>         all boots it came up with the ctree error. After, it never
>         happened again.
>
>         Regards,
>         Kai
>
>         --
>         To unsubscribe from this list: send the line "unsubscribe
>         linux-btrfs" in
>         the body of a message to majordomo@vger.kernel.org
>         <mailto:majordomo@vger.kernel.org>
>         More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>     Thanks,  I tried that route and it, unfortunately, did not do
>     anything for me.  But the defragmentation continues to do the job
>     every time.  I am now going to make everything on the OS side
>     "nodatacow" and am expecting that will further relieve the
>     problem. The problem NEVER occurs in a normal environment, only in
>     the initrd environment.  There is something uniquely different
>     about the initrd environment that triggers this problem.
>     --
>     To unsubscribe from this list: send the line "unsubscribe
>     linux-btrfs" in
>     the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I tried this once before and it didn''t work and now I tried it again
and
it still didn''t work.  But then I became a bit suspicious of WHY it was
not working.  I used a number of different delay intervals and carefully 
compared them with each other and with no delay specified in the system 
logs (journal).  What I found was absolutely identical boot orders. How 
on earth can bootdelay work if dracut/initrd is not honoring bootdelay 
option presented by grub?  This becomes so maddening when trying to deal 
with one bug only to run straight into the jaws of another.  In any 
case, thanks Kai for trying to help with this.  At this point I have 
opened a bug report against dracut on this issue.  One way or another we 
will get there I suppose.  In the mean time I suppose I had better just 
try to relax and enjoy all the excitement.  - George

On 06/09/2013 01:24 AM, Kai Krakow wrote:
>
> Actually it should be called "rootdelay"... My fault...
>
> Am 07.06.2013 01:48 schrieb "George Mitchell"
<george@chinilu.com
> <mailto:george@chinilu.com>>:
>
>     On 06/06/2013 01:58 PM, Kai Krakow wrote:
>
>         George Mitchell <george@chinilu.com
>         <mailto:george@chinilu.com>> schrieb:
>
>             I am seeing a huge improvement in boot performance since
>             doing a system
>             wide file by file defragementation of metadata.  In fact
>             in the four
>             sequential boots since completing this process, I have not
>             seen one
>             open_ctree failure so far.  This leads me to suspect that
>             the open_ctree
>             boot failures that have been plaguing me since install
>             have been related
>             to metadata fragmentation.  So I would advise anyone else
>             experiencing
>             open_ctree boot problems to defragment their metatdata and
>             see if that
>             helps.  It certainly seems to have helped me in that regard.
>
>         I suspect this observation comes from btrfs being able to
>         faster initialize
>         itself during kernel detection since you defragmented it. Try
>         to add
>         root_delay=2 to your kernel command line and see if it
>         improves on this
>         particular problem.
>
>         I had this myself and root_delay=1 fixed it for me. Before, in
>         about 90% of
>         all boots it came up with the ctree error. After, it never
>         happened again.
>
>         Regards,
>         Kai
>
>         --
>         To unsubscribe from this list: send the line "unsubscribe
>         linux-btrfs" in
>         the body of a message to majordomo@vger.kernel.org
>         <mailto:majordomo@vger.kernel.org>
>         More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>     Thanks,  I tried that route and it, unfortunately, did not do
>     anything for me.  But the defragmentation continues to do the job
>     every time.  I am now going to make everything on the OS side
>     "nodatacow" and am expecting that will further relieve the
>     problem. The problem NEVER occurs in a normal environment, only in
>     the initrd environment.  There is something uniquely different
>     about the initrd environment that triggers this problem.
>     --
>     To unsubscribe from this list: send the line "unsubscribe
>     linux-btrfs" in
>     the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html