Scrub CPU usage ...

Scrub CPU usage ...

[George Mitchell]

I just subscribed to this list so in case this subject has already been 
discussed at length, my apologies.  I have been waiting for btrfs 
forever.  I have been waiting for it to become reasonably stable.  In 
the wake of escalating problems with my old hardware RAID setup, I 
decided now was the time to make the transition.  At this point I have 
been completely transitioned to btrfs for nearly a month with the only 
exception being a backup mirror drive formatted jfs that gets mounted 
and updated hourly via cron'd rsync and then immediately unmounted until 
the next update.  I am using btrfs raid 1 across five 500GB Seagate 
nearline drives and btrfs single on a Seagate 4TB backup drive.  I am 
absolutely delighted with how this system is working.  This is my 
primary day in and day out system.  I have to date hard crashed this 
system at least three times without sustaining any apparent damage to 
the filesystems.  Perhaps I have just been extremely lucky, but it seems 
like most of the major holes have been closed at this point.  Actually I 
have only two significant issues currently with btrfs.

1)  The system fails to boot intermittently due to dracut/initrd issues 
(btrfs: open_ctree failed).  This is being worked on upstream and I am 
seeing a continual flow of patches addressing it, but so far no fix.  
This will take time to fix and it usually leaps to life in 3 attempts or 
less.

2)  My real concern is scrub CPU usage.  Running a scrub simply exhausts 
all available CPU and make they system nearly unusable.  In my case I 
have a whole lot more hard drive resources that CPU resources, so it is 
CPU that gets saturated.  My question is, is there anything being done 
upstream to address this issue?  Like, for example, a command line 
option to limit CPU usage to some predetermined %?  Or, better yet, some 
sort of intellegence that would cause scrub to back off in deference to 
user usage?  I am thinking that this should be something that can happen 
in the background and take twice as long as it does now, but allow other 
processes room to fly at the same time.  Of the few issues I am 
currently facing with btrfs, this is probably the most irritating one 
for me right now.

There are other minor issues that I am seeing that are almost completely 
related to existing utilities not understanding btrfs. These are 
problems that need to be solved by the maintainers of those specific 
utilities.  I am not worried about these.

Thanks for any thoughts anyone might have on these issues!

Re: Scrub CPU usage ...

[Kai Krakow]

George Mitchell <george@chinilu.com> schrieb:

> 1)  The system fails to boot intermittently due to dracut/initrd issues
> (btrfs: open_ctree failed).  This is being worked on upstream and I am
> seeing a continual flow of patches addressing it, but so far no fix.
> This will take time to fix and it usually leaps to life in 3 attempts or
> less.

Try rootdelay=1 or a higher number. This solved exactly that problem for me. 
It will delay mounting the rootfs by the given number of seconds. You need 
to pass this on the kernel command line, probably using grub. This seems to 
only be needed with multi-device btrfs as rootfs.

Greetings,
Kai

Re: Scrub CPU usage ...

[George Mitchell]

On 05/04/2013 06:21 PM, Kai Krakow wrote:
> George Mitchell <george@chinilu.com> schrieb:
>
>> 1)  The system fails to boot intermittently due to dracut/initrd issues
>> (btrfs: open_ctree failed).  This is being worked on upstream and I am
>> seeing a continual flow of patches addressing it, but so far no fix.
>> This will take time to fix and it usually leaps to life in 3 attempts or
>> less.
> Try rootdelay=1 or a higher number. This solved exactly that problem for me.
> It will delay mounting the rootfs by the given number of seconds. You need
> to pass this on the kernel command line, probably using grub. This seems to
> only be needed with multi-device btrfs as rootfs.
>
> Greetings,
> 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 immensely for that tip.  I will give it a try.  - George

Re: Scrub CPU usage ...

[Martin Steigerwald]

Hi George!

Am Samstag, 4. Mai 2013, 11:39:59 schrieb George Mitchell:
> the next update.  I am using btrfs raid 1 across five 500GB Seagate 
> nearline drives and btrfs single on a Seagate 4TB backup drive.  I am 
> absolutely delighted with how this system is working.  This is my 
> primary day in and day out system.  I have to date hard crashed this 
> system at least three times without sustaining any apparent damage to 
> the filesystems.  Perhaps I have just been extremely lucky, but it seems 
> like most of the major holes have been closed at this point.  Actually I 
> have only two significant issues currently with btrfs.

Are you aware that BTRFS RAID-1 works differently than block based RAID? BTRFS 
will only be holding two copies of every data or metadata chunk on two 
different drives, regardless how many drives you use. So only one drive may 
fail.

Well, I think you will have notices with df output for the filesystem, but I 
thought I mention it, just in case.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: Scrub CPU usage ...

[George Mitchell]

On 05/05/2013 02:22 AM, Martin Steigerwald wrote:
> Hi George!
>
> Am Samstag, 4. Mai 2013, 11:39:59 schrieb George Mitchell:
>> the next update.  I am using btrfs raid 1 across five 500GB Seagate
>> nearline drives and btrfs single on a Seagate 4TB backup drive.  I am
>> absolutely delighted with how this system is working.  This is my
>> primary day in and day out system.  I have to date hard crashed this
>> system at least three times without sustaining any apparent damage to
>> the filesystems.  Perhaps I have just been extremely lucky, but it seems
>> like most of the major holes have been closed at this point.  Actually I
>> have only two significant issues currently with btrfs.
> Are you aware that BTRFS RAID-1 works differently than block based RAID? BTRFS
> will only be holding two copies of every data or metadata chunk on two
> different drives, regardless how many drives you use. So only one drive may
> fail.
>
> Well, I think you will have notices with df output for the filesystem, but I
> thought I mention it, just in case.
>
> Thanks,
Yes indeed!  I was aware of this from the beginning.  All I am looking 
for is duplication across hardware.  The advantage of more than two 
drives is that in case you lose a drive, you don't end up losing a lot 
of space, and you are much less likely to end up in an unduplicated 
state for a significant amount of time.  But thanks for your thoughts!  
What I am NOT missing about the old 3ware card is the resyncs.  I used 
to spend half a day doing drive resyncs when a drive dropped out for 
some reason.  Hardware RAID is great when it works, but I much prefer 
btrfs.  Software RAID has its own problems.  Its gotten better I hear, 
but when I used it for a long time, I was a pain.  But both forms of 
block RAID saved me from ever losing data.  - George