Skip to contentSkip to conversation

Possible solution to the "open_ctree" boot bug ...

DISCUSSION George Mitchell 2 participants 5 messages Jun 2, 2013 – Jun 11, 2013 1 message not in the archive Btrfs file system

lore
Share & tools
lore

George Mitchell

author
#0 lore raw

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.

#1 lore raw
Quoted 8 lines · George Mitchell

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

author
#2 lore raw
Quoted 18 lines · Kai Krakow
Quoted 8 lines · George Mitchell

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.

Quoted 9 lines

Regards,
Kai

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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.

A message that is not in the archive (sent off-list or not yet received): CAMthOuPif30y4JPrNGhnUteajkck65FjwTss0vVFvCs7EM+gvQ@mail.gmail.com

author
#4 lore raw
Quoted 3 lines · Kai Krakow

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

Quoted 61 lines

Am 07.06.2013 01:48 schrieb "George Mitchell" <[email protected] <mailto:[email protected]>>:

On 06/06/2013 01:58 PM, Kai Krakow wrote:

George Mitchell <[email protected]
<mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
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 [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#5 lore raw
In reply to a message not in the archive

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

Quoted 64 lines · Kai Krakow

Actually it should be called "rootdelay"... My fault...

Am 07.06.2013 01:48 schrieb "George Mitchell" <[email protected] <mailto:[email protected]>>:

On 06/06/2013 01:58 PM, Kai Krakow wrote:

George Mitchell <[email protected]
<mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
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 [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html