Announcement

Collapse
No announcement yet.

Lead Btrfs FIle-System Developers Join Facebook

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by michal View Post
    It's almost 7 years old

    commit be0e5c097fc206b863ce9fe6b3cfd6974b0110f4
    Author: Chris Mason <chris.mason@oracle.com>
    Date: Fri Jan 26 15:51:26 2007 -0500

    Btrfs: Initial checkin, basic working tree code

    Signed-off-by: Chris Mason <chris.mason@oracle.com>
    Thanks for the correction!

    Comment


    • #17
      Originally posted by Akka View Post
      Are you sure they plan develop a fsck tool at all? I don't think zfs has it? I thought it was unnecessary for this sort of file system?
      What do you mean by "plan"? They already have one, and have had it for a while. It's not critical, but it exists.

      Comment


      • #18
        Originally posted by GreatEmerald View Post
        enjolras, no, the priorities are quite fine. Btrfs doesn't need a fsck, because it does all the checking and repair at runtime... There is little reason to also make an offline tool for it.
        Well, I had a filesystem that got corrupted somehow after a crash. You could still mount it but it behaved 'weird'. The fsck tool detected some errors but wasn't able to correct them - it crashed instead. In the end you're told that the best option is to format. Few months later I read some news about new compression algorithms and some new raid mode in btrfs.

        I think this is like the definition of 'having the priorities in the wrong order'.

        Comment


        • #19
          Originally posted by jwilliams View Post
          Try 6 years. Development began in late 2007.

          Compare to ZFS. Development started in 2001. Then ZFS was included in the June 2006 update of Solaris 10. That is 5 years from beginning of development to deployment in a production OS.

          But ZFS pioneered a lot of new filesystem concepts. btrfs already had all of those ideas available to build on in 2007, so btrfs should have been ready faster than ZFS. Implementation should be faster when you do not need to invent the wheel (only reinvent it).

          Instead, after 6 years of development, btrfs is still not ready to be the default root filesystem of a stable OS release.

          Unfortunately, I think it is evident that the project management of btrfs is ineffective. Announcements like this that the project management is not changing may be meant to be reassuring, but I am not reassured.
          Blah blah from the sidelines. AFAIK, it is default filesystem for SLES. All your assumptions are just assumptions from a very far distance. Reaching conclusions is a bit rude IMO, because you lack any knowledge or did any investigation at all.

          Comment


          • #20
            Originally posted by bkor View Post
            it is default filesystem for SLES.
            False.

            Comment


            • #21
              Originally posted by xeekei View Post
              Since you commented, I think you care. You're just frustrated like the rest of us. Let's hope Facebook can cram more manhours out of these guys. They probably have deeper pockets than Fusion-IO. Maybe it isn't manhours that's bottlenecking the Btrfs progress though.
              No, I used it, to me as a normal desktop user I don't see a significant difference between it and say ext4. Snapshots etc etc are overrated and mostly useful for advanced users and on the server/cloud.

              The only difference I care about is Btrfs doesn't create the stupid "lost+found" folder.

              Comment


              • #22
                Btrfs is like Gmail - perpetually in beta, and will be used by heaps of regular users before it's officially stable* (as in Debian stable). Some distros already have it as their default. All the core features are pretty stable by this point - it's only the newer features that aren't quite there yet.
                I've been using it for over a year now (for both / and /home), and IMO it's ready for everyday use.

                It's had a fsck utility for a while - it used to be called btrfsck, now it's just 'btrfs check'. The three ways of dealing with integrity issues are, in order of preference:
                • mounting it (it does checks on each mount that ext4 doesn't)
                • mounting it with '-o recovery'
                • running 'btrfs check'

                There is also 'btrfs scrub' for redundant multi-device file systems, which verifies the checksums on everything in the file system, repairs any corruption, and tells you about it. (Great early warning for hard drive failure.)

                Originally posted by mark45 View Post
                No, I used it, to me as a normal desktop user I don't see a significant difference between it and say ext4. Snapshots etc etc are overrated and mostly useful for advanced users and on the server/cloud.
                Snapshots are amazingly useful - I would argue they're the best feature of btrfs, easily enough to justify the performance hit (compared to ext4).
                Yes, most users are never going to use them manually, but if enabled by the distro or given a pretty GUI they won't need to. Ubuntu has apt-btrfs-snapshot that automatically snapshots the root FS on every operation, which is pretty useful in case you have an update that breaks something.

                Another way of looking at it is that snapshots are incredibly cheap backups - they take about a second and cost very little space. Add a cron job to snapshot /home each day, and you won't even notice the overhead. Rsync will take at least a dozen minutes or so just to identify which files have changed when your data is in the TBs. Daily backups are a life saver in case you accidentally delete something, but most people aren't going to be doing them unless they're in an enterprise environment or have less than a few GB.

                * Reasons why btrfs isn't stable yet:
                • there was a performance regression for programs with databases (e.g. Chrome, Firefox) and virtual machines - that's been largely fixed since about a year ago
                • some parts of the RAID implementation are still relatively new (esp. RAID5/RAID6)
                • send/receive doesn't work properly yet (it's supposed to, but I still get 'ERROR: rename o262-5-0 -> snapshots failed. No such file or directory'.)

                Comment


                • #23
                  I used btrfs as a root filesystem for a while, until something was corrupted and it crashed when I tried to mount the filesystem. Will be sticking with ext4 for the foreseeable future.

                  Comment


                  • #24
                    Originally posted by GreatEmerald View Post
                    Btrfs doesn't need a fsck, because it does all the checking and repair at runtime (which can also be manually forced with scrub), while recovery is done via mount options. There is little reason to also make an offline tool for it.
                    How about: your systems are running enterprise kernel foo.2.years.ago. The recovery abilities of the latest fsck would be greatly better than the code in the enterprise kernel.

                    (hypothetical scenario where btrfs is already stable in an EL kernel)

                    Comment


                    • #25
                      Originally posted by mark45 View Post
                      It's been in development for like 5 years already and still no final format, no stable release....
                      Not accurate. Hasn't been true for a while. From the very top of the Btrfs wiki:
                      The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels.
                      The only thing really lacking now is userspace tools. Unfortunately, like curaga pointed out, RAID5/6 is not complete as it's mostly lacking in the userspace tools part. Btrfs RAID1 is similar to the concept of traditional RAID5, so it's not really that big of a deal for arrays with low numbers of disks.

                      The Btrfs-progs package is now being released according to the Linux Kernel schedule, and will be numbered as such. This makes a lot of sense IMO.

                      Comment


                      • #26
                        Originally posted by mark45 View Post
                        It's been in development for like 5 years already and still no final format, no stable release. It's one of those projects I stopped caring about.
                        Author: David Sterba <dsterba@suse.cz>
                        Date: Wed Nov 20 14:32:34 2013 +0100

                        btrfs: update kconfig help text

                        Reflect the current status. Portions of the text taken from the
                        wiki pages.

                        Signed-off-by: David Sterba <dsterba@suse.cz>
                        Signed-off-by: Chris Mason <chris.mason@fusionio.com>
                        The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels.
                        So what do you mean by final format?

                        Comment


                        • #27
                          Thank You!

                          Originally posted by PuckPoltergeist View Post
                          So what do you mean by final format?
                          THANK YOU! Here's a link

                          Comment

                          Working...
                          X