Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 46

Thread: Btrfs On Ubuntu Is Running Well

  1. #31
    Join Date
    Jul 2013
    Posts
    1

    Default beware of UREs.

    Quote Originally Posted by Brane215 View Post
    This I don't really understand. You add a few drives, add them to the raid as hot-swap, then remove one by one of the small drives until mdadm activates all big drives and rewrites them with new stuff. Then you remove old drives.

    Repeat until done. After you have all drives done, you grow the array. After that, you expand fs. All the time, all your data is on the RAID-5/6.

    Does btrfs even offer RAID-5/6 at the moment ?
    The real danger with mdadm raid 5 arrays is tripping on an unrecoverable read error rate (URE) on a second drive while trying to re-silver the array. I've come across posts that made me worry: http://www.zdnet.com/blog/storage/wh...ng-in-2009/162 .

    People suggest backing up the data (if not having done so already) BEFORE replacing the failed drive to avoid danger of hitting an URE. For arrays near or over 12TB the danger is real.

    I've got a 4x2TB raid 5 ext4 array and I've successfully replaced 2 bad drives over a period of time, but I'm looking forward to replacing it with btrfs when its raid 5 and btrfs-tools become mature enough.

    I hope you enjoy your large array, but please make sure you take regular backups.

  2. #32
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote Originally Posted by Brane215 View Post

    3. Data/metadata protection:

    All that is fine, checksumming stuff. But what good is that protection when filesystem itself is unstable ? I don't expect miracles from filesystem. It's just layer of abstraction between my kernel and the drive itself. It tires to anticipate next reads/writes, to readahead, cache and coalesce. That's about the limit of how much can it "improve" drive's raw speed performance. Unless off course we are talking about FLASH storage without really intelligent and capable driver with good amount of cache. With FLASH, I wand fs that is tailored, not tweaked for it.

    So I don't particularly care if btrfs is 20% or 30% ahead or behind on some test, even more so when this is consequence of the nature of filesystem. As long as this is not huge speed penalty for the common use case.
    And as long it makes optimal use of FLASH, if it is on such HW.

    But if it croaks now and then and when it does, all I'm left with is empty tool box full of spider webs and with dick in my hand, then thanks, but no, thanks. I might test it and play with it, but no way am I using it for important stuff...
    NO Filesystem is 100% stable, and no one is going to walk around with a rubber stamp and slam "stable" onto BTRFS one day. We still find data corruption bugs in ext4 for christs sake.

  3. #33
    Join Date
    Jul 2012
    Posts
    138

    Default

    Quote Originally Posted by Ericg View Post
    NO Filesystem is 100% stable, and no one is going to walk around with a rubber stamp and slam "stable" onto BTRFS one day. We still find data corruption bugs in ext4 for christs sake.
    I know that there is no sharp line between day and night, but it's hard to call this stable enough for serious use in this state.

    I undestand that money seems to be tight and this being an open source, it is understandable that public can expect to have to play betatesters. If you don't pay it with money, expect to invest some time.

    Which is fine with me.


    Annoying thing is that people are vocal about pushing this into hands of unsuspecting public as totally great and certainly good enough for most users.

    All that without good diagnostic, recovery and management tools and with many features missing, untested or working far from as advertised.

  4. #34
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    637

    Default

    Quote Originally Posted by ninez View Post
    By far, the above patchset is the most applicable and best for my use cases. I googled and found the entire patchset (which is actually 7 not 6 - as there was one written after the 6 were released). I had to edit patch 6 to apply properly, but after that it compiled just fine - I haven't done any serious testing yet. But my machine seems to be running faster. (boot time was quicker, certain apps loading quicker, Ardour3 session that i played is lighter on CPU usage too)...



    As soon as the rest of my parts for my embedded ITX box show up (and i get the machine running). I am going to test out btrfs again. If these patches (and possibly others haven't been merged by then_ then i will test them out too (I'm not messing around with this machine..lol). It will be interesting to see how Btrfs is shaping up. I should be able to experiment (even hose the install and not care), so that should be a good scenario for testing.

    the rest i haven't gone through (because i only test X number of patches per compilation and had a couple to test on top of the IPC/sem ones above), but again - a couple of them will probably be useful

    cheerz
    unfortunately I always got issues when trying out the rt-kernel & ZFS doesn't work yet with it - so I'll settle for BFS + tweaking on an up-to-date kernel for now

    most of the recent performance-related improvements & patches for btrfs can be found on http://marc.info/?l=linux-btrfs&r=1&b=201308&w=2 are from August until now


    glad it helps

  5. #35
    Join Date
    Dec 2008
    Posts
    146

    Default

    Quote Originally Posted by benmoran View Post
    You can't expand further than 16TB, as that is the limit for the version of ext4utils that ships with all distributions. A version that supports more than
    16TB exists, but it's not widely tested - even less so than btrfs.
    Nonsense. The last remaining detail preventing ext4 resizing for filesystems larger than 16TB was handled nearly a year ago. Several distributions have incorporated e2fsprogs 1.42.6 or later into their repositories for months now. Besides, XFS has supported >16TB filesystems for years now. Certainly there are viable alternatives to btrfs for >16TB filesystems.

    E2fsprogs 1.42.6 (September 21, 2012)
    http://lwn.net/Articles/517636/

  6. #36
    Join Date
    Dec 2008
    Posts
    146

    Default

    The btrfs issue that has prevented me from adopting it is that if you accidently fill up your filesystem, it is a major operation to fix it. You cannot just delete the offending file(s) since btrfs is COW. The btrfs developers need to come up with a simple way to delete files from a full filesystem.

    Also, finding out exactly how much free space a btrfs filesystem has is difficult. Which makes the above issue even more troublesome.

  7. #37
    Join Date
    Jun 2011
    Posts
    840

    Default

    Quote Originally Posted by kernelOfTruth View Post
    unfortunately I always got issues when trying out the rt-kernel & ZFS doesn't work yet with it - so I'll settle for BFS + tweaking on an up-to-date kernel for now
    About ZFS - that sucks. I use ext4 (as i said before) so it's a non-issue for me.. Is ZFS not thread-safe or something?

    Anyway, After further testing, those initial ipc/sem patches kick ass! ~ it's a definite performance improvment. Next, I'm gonna play around with the cfq-iosched patch, mutex_don't deal with unnecessary waiters patch, sync dont block flusher thread patch and throw in the optimize_strlen_using simd instructions patch too - just adding them to the queue now.

    Quote Originally Posted by kernelOfTruth View Post
    most of the recent performance-related improvements & patches for btrfs can be found on http://marc.info/?l=linux-btrfs&r=1&b=201308&w=2 are from August until now

    glad it helps
    Maybe i will subscribe to btrfs mailing list, once it gets a little closer to me assembling my new machine... Also, yes so far these patches have been useful <that i've tested anyway>. It's funny, I've been slacking recently <as far as digging for patches goes> and on updating my kernel packages for Archlinux - So you pointing out some of these patches is helpful. Even given, that many are in linux-next - they won't be backported to linux-rt 3.10.x - so it's nice to go through and cherry pick, some of the more useful ones to backport...

    thx again, cheerz

  8. #38
    Join Date
    Jul 2012
    Posts
    138

    Default

    Quote Originally Posted by kenneth13 View Post
    The real danger with mdadm raid 5 arrays is tripping on an unrecoverable read error rate (URE) on a second drive while trying to re-silver the array. I've come across posts that made me worry: http://www.zdnet.com/blog/storage/wh...ng-in-2009/162 .

    People suggest backing up the data (if not having done so already) BEFORE replacing the failed drive to avoid danger of hitting an URE. For arrays near or over 12TB the danger is real.

    I've got a 4x2TB raid 5 ext4 array and I've successfully replaced 2 bad drives over a period of time, but I'm looking forward to replacing it with btrfs when its raid 5 and btrfs-tools become mature enough.

    I hope you enjoy your large array, but please make sure you take regular backups.

    1. I know that RAID, as it stands now, has its deficiencies. Or maybe it is too stroong of a word. Raid gets done exactly what is possible within redundancy allowed. If you need more, well add more mechanisms with redundancy.

    2. Even in that example, I don't think it's that bad. In that example with a drive with one bad sector, you could force rebuild around it and be prepared to lose a file or two.
    3. That is solvable with RAID-6.
    4. You always have an option of professional recovery, which shouldn't be too expensive or painfull if we are talking about simple sector copy of the drive.
    5. What makes you think that Btrfs underlying solution wil be superior in practice ?

    I have nothing against Btrfs and I agree that at least its the PR pamphlet adresses _some_interesting problems. I just have hard time believing it is time to jump the Btrfs bandwagon for the majority.

    And, to be blunt, it seems to much of the tutti-fruti solution to me. Instead being focused on one compatible set of objectives with maximum efficiency, they seem to be trying to cover everything they can and end result is less than stellar. Hydroplane is neither competitite as a plane nor as a boat. It "needs" right customer profile. Btrs feels a bit the same way, at least from afar...

  9. #39
    Join Date
    Feb 2009
    Posts
    370

    Default

    Quote Originally Posted by Brane215 View Post
    Who cares about few extra steps ? Do you reshape your disk storage this way several times per day ?
    I USE it every day for most of the time. So, its performance during work is by far primary for me. Qty of work at one-time maintenance work, if it is not excessive or unreasonable is totally irellevant.

    I don't have RAID for fun.
    Your question was whether or not there exist any advantages. Resizing arrays is one. Many of us who deal with big storage arrays daily DO have to use these features. You seem to now be arguing that you don't need any more advanced features, and that's fine.

    Again, I use MDADM extensively. It has it's limitations.

  10. #40
    Join Date
    Jul 2012
    Posts
    138

    Default

    Quote Originally Posted by benmoran View Post
    Your question was whether or not there exist any advantages. Resizing arrays is one. Many of us who deal with big storage arrays daily DO have to use these features. You seem to now be arguing that you don't need any more advanced features, and that's fine.

    Again, I use MDADM extensively. It has it's limitations.
    Yes, but those affect system administrator much more than actual user, which might care more about array performance.

    When you buy new car, is your sole criteria how elegantly will your mechanic be able to replace spark plugs, air filter or oil ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •