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@xxxxxxxxxxx
<mailto:george@xxxxxxxxxxx>>:
On 06/06/2013 01:58 PM, Kai Krakow wrote:
George Mitchell <george@xxxxxxxxxxx
<mailto:george@xxxxxxxxxxx>> 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@xxxxxxxxxxxxxxx
<mailto:majordomo@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
<mailto:majordomo@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
