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! -- 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:> 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
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 -- 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
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 -- 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 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 -- 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