Mageia forum

I am currently using btrfs pretty much exclusively on my main system and having relatively few problems with it considering. I have had a boot failure problem, but that is pretty much cured at this point. The boot problem is caused by an initial root mount failure which is looking as though it is related more to UUID lookup than mount itself. I also have had a nagging journal problem, but I am beginning to suspect that it is not related to btrfs. Other than that, btrfs itself has performed flawlessly. If anyone else has experiences they would like to share, I would like to hear about that. I really can't be the only one in the world at this point running Mageia on btrfs. - George

Flawlessly except for the few journal log corruptions?

doktor5000 wrote:Flawlessly except for the few journal log corruptions?

Yup. It has been pretty remarkable. The journal log corruptions are a mystery. I moved the journal logs to ext4 filesystem and STILL ended up with the same corruptions. That tells me that btrfs is VERY UNLIKELY to be involved in causing those corruptions. It is certain that btrfs is not causing a problem with the writes to the journal since they happen even when those writes are to a journal on an ext4 filesystem. And I think the boot problem is much more a dracut/initrd issue than a btrfs issue also. I think it is simply a matter of dracut/initrd not giving btrfs the time it needs to be ready for mounting, in much the same way a similar problem can occur with raid arrays. Other than that, I am only seeing a few non-consequential kernel complaints about timeouts on disk write attempts, but they are rare. I think one thing that is helping immensely is the fact that I have a UPS installed to prevent power fail problems. But even with that, I have crashed the system multiple times and still escaped unscathed. I am probably just increadibly lucky, or the fact that I have multiple running backups is scaring my system into good behavior. But so far I am not a bit sorry that I abandoned 3ware raid for btrfs.

Btrfs does not do journaling. It keeps its log in a B-tree (not C-tree) structure (whatever those are ) in a sub-volume and get deleted on its next remount. This eliminates repeated writing on hard-drive or ssd.

Only thing to watch out for using grub2 is when using 'savedefault'; there is a 'misleading' message 'sparse file not allowed. press any key to continue' which boots anyway. But this is due to using sub-volumes. Still, hope the grub developers do something about this minor issue (and minor to resolve, me think).

gohlip wrote:Btrfs does not do journaling. It keeps its log in a B-tree (not C-tree) structure (whatever those are ) in a sub-volume and get deleted on its next remount.

Maybe you misunderstood, the journal corruptions were related to journal as in systemd journal: viewtopic.php?f=7&t=5176

For B-Tree you may want to look at http://www.kylescousin.com/2010/09/a-si ... exes-work/ or https://en.wikipedia.org/wiki/B-tree

doktor5000 wrote:For B-Tree you may want to look at http://www.kylescousin.com/2010/09/a-si ... exes-work/ or https://en.wikipedia.org/wiki/B-tree

Thanks for the links.
[edit] - still don't understand.

It appears like we are perhaps making progress on the boot bug issue. The underlying cause of the boot bug is that, unlike conventional soft raid arrays, btrfs does not use virtual mount points. This means that even though the devices themselves have appeared, the btrfs file system may not have fully synced the raid elements before the kernel tries to mount the root filesystem. Thus the only solution at this point is a brief (one second) "rootdelay". But I have been unable to make the "rootdelay" option work. Barry Jackson has been trying to help me with that and he discovered that even though the /proc filesystem indicates that the kernel received the rootdelay option on boot, the kernel actually did NOT perform any delay before attempting to mount the root filesystem. So at this point this appears to be a kernel bug. Given the fact that btrfs is such a major departure from other previous filesystems, it is to be expected that there will be a few bumps in the road along the way.

'rootdelay' is for grub to wait for bios to detect drives (especially external drives), not for kernel to delay to boot.

See https://www.kernel.org/doc/Documentation/kernel-parameters.txt

It is clearly designated as a "kernel parameter" and not a "bootloader parameter". Multiple users of other distributions are using it and observing the kernel respond accordingly.

Also see: http://unix.stackexchange.com/questions/67199/whats-the-point-of-rootwait-rootdelay

The point of rootdelay is to delay kernel timeout, but still allow it so that it can drop back to the bootloader in case a backup boot partition is defined in the bootloader, but the actual delay should be done by the kernel before attempting to mount the root filesystem.

ghmitch wrote:See https://www.kernel.org/doc/Documentation/kernel-parameters.txt

It is clearly designated as a "kernel parameter" and not a "bootloader parameter". Multiple users of other distributions are using it and observing the kernel respond accordingly.

Also see: http://unix.stackexchange.com/questions/67199/whats-the-point-of-rootwait-rootdelay

The point of rootdelay is to delay kernel timeout, but still allow it so that it can drop back to the bootloader in case a backup boot partition is defined in the bootloader, but the actual delay should be done by the kernel before attempting to mount the root filesystem.

"kernel parameter" means (in your links too) means the parameter of the "kernel line" of grub-legacy - note grub2 uses "linux line" rather than "kernel line"
This has nothing to do with the actual kernel in the true sense. Lot's of distributions use this because they all use grub.
And... mounting 'filesystem' means mounting partition means bios has to detect it first before 'kernel' has a shot at it.

rootdelay - if it doesn't work, use rootwait. but I am not sure if both are deprecated, so just try these.
I've never use these, don't have to.

gohlip wrote:"kernel parameter" means (in your links too) means the parameter of the "kernel line" of grub-legacy - note grub2 uses "linux line" rather than "kernel line"
This has nothing to do with the actual kernel in the true sense.

Sorry, that is not correct, those options are passed to the kernel - you got it completely wrong. Check your /proc/cmdline once your system is running.

Just one example then, the vga=788" in your "kernel" line.
Does your "kernel" boot up to that resolution?

opps: it's vga=795 (in grub2), used to be something else in M2, right?
note; vga=795 => 1152x864

and in menu.lst it's still vga=788, and that's 800x600.

What's your point? vga is a bootloader option, you're comparing apples with oranges.

vga= [BOOT,X86-32] Select a particular video mode
See Documentation/x86/boot.txt and
Documentation/svga.txt.
Use vga=ask for menu.
This is actually a boot loader parameter; the value is
passed to the kernel using a special protocol.

The point being.........not all 'parameters' in the "kernel line" of grub-legacy menu are "kernel parameters".
So you've made your point and mine mine. So let's move on.

Cheers, take care. Let's close this. Oh, you can do that.

And.....ta da.....there's still no journaling in btrfs...

Just for the record. The rootwait parameter does not work for this because, unlike rootdelay which waits for a specified interval, rootwait only waits for the drive to appear. In this case, the drives HAVE appeared (or been detected), but the btrfs kernel modules have not had sufficient time to fully resolve the btrfs filesystem on those drives and in this case strange things happen when operations are attempted on those drives. The btrfs filesystem involves a number of dynamic kernel modules, all of which perform specialized tasks related to the btrfs filesystem. Before the file system is mounted, time is needed for the filesystem to be prepared for mounting. Without the rootdelay parameter being available, mounting of the filesystem is attempted within nanoseconds of drive detection by the kernel. This means a very high chance of various kernel processes coliding at the same moment in time. I believe that rootdelay is a rather old option that was used with things like software raid back in the days when it had similar problems. It is indeed a very obscure and seldom used option now that software raid has matured to the point that it no longer needs it or we are at a point were people no longer use software raid for complex arrays that would require it. But multiple btrfs users have found that it works in solving this boot problem. This is exactly why I am trying to search out other Mageia btrfs users. If we can compare notes on these kinds of things in advance, it will save somebody the headache of having to reinvent the wheel. I would be a bit bananas over this myself if it were not for the kind people on the btrfs mailing list. They are the ones who suggested that rootdelay solves this problem. So, thank you gohlip for tryhing to be helpful with this, you have been much help to me in the past and that is appreciated, but like doktor, I really think that you are wrong on this one. Of course it is going to take time to sort it out definitively as is always the way with brand new technologies like btrfs. In the process we will ALL learn a lot and that is a good thing and is one reason that we all have to be cautious not to take these things to seriously or allow ourselves to become too contentious over them which I, myself, have been guilty of in the past.

gohlip wrote:
The point being.........not all 'parameters' in the "kernel line" of grub-legacy menu are "kernel parameters".
So you've made your point and mine mine. So let's move on.

All of us agree on that point.

gohlip wrote:
Cheers, take care. Let's close this. Oh, you can do that.

Excuse me? This is not and never was a request for support. That is a different forum. This thread was intitiated by me with the intention of becoming a facilitator of discussion between anyone who might be using or exploring the use of btrfs. In fact you never really touched on this but simply jumped in as if this were some sort of request for answers which is was not. I have been pursuing that end of it on the designated support forums, the various mailing lists, and the designated bug reporting platforms. My purpose here is simply to create a small place where anyone using btrfs can meet up with other btrfs users and discuss their experiences, discoveries, and, yes, frustrations. But it is not intended as a problem solving solution although at times that might happen. So please don't request that the thread be closed simply because you, for some reason, don't seem to like its content. If it has become a point of contention, that would only be because you have brought the contention.

gohlip wrote:
And.....ta da.....there's still no journaling in btrfs...

And there never was and nobody, but you, ever suggested that anyone claimed there was. I would think that my statement in my initial post that "I am beginning to suspect that it is not related to btrfs" would give you some sort of clue that I was never talking about btrfs journaling in the first place. You misread my initial post, so why are you still poking at the point as if we are somehow the ones on another planet?

ghmitch wrote:......and that is a good thing and is one reason that we all have to be cautious not to take these things to seriously or allow ourselves to become too contentious over them........

Good point. Acknowledged and accepted.

As for btrfs, I do not have Mageia in btrfs as M2 then cannot have it (without much hassle); I have Kubuntu in btrfs for some time now (quite early, cannot recall exactly when) and I converted my large data file (on the fly, impressive) to btrfs too. My own grub partition is always in ext2 (boots don't need journaling.. ).

I've known about that error message when booting btrfs when I used Kubuntu's boot (through core.img) and Kubuntu/Ubuntu's grub2 use too much unnecessary thingies (recordfail...etc) but I don't have this problem booting using my own grub2 (simple 3 line setup configuration). Other than that minor thing, btrfs is pretty impressive.

So take care, have fun in your 'experimentation' and do continue to let us know your findings.
But be aware we may dispute your 'conclusions'. I promise I'll try not to be 'too contentious' about it.
Cheers.

,.....so why are you still poking at the point as if we are somehow the ones on another planet?

Okay then, I'll go back to Xenu. Ta ta.

gohlip wrote:
As for btrfs, I do not have Mageia in btrfs as M2 then cannot have it (without much hassle); I have Kubuntu in btrfs for some time now (quite early, cannot recall exactly when) and I converted my large data file (on the fly, impressive) to btrfs too. My own grub partition is always in ext2 (boots don't need journaling.. ).

...

THAT is EXACTLY the sort of post I was looking for when I created this thread and it is full of potentially very helpful information. Thanks!!!

And you are ALWAYS welcome to dispute my conclusions because I would be the first to admit that they are often premature and wrong. And when you have effectively demonstrated they are wrong, I will own up to that, but until then they will remain a point where we simply don't agree.