Announcement

Collapse
No announcement yet.

OpenSUSE Looks To Switch To Btrfs For Next Release

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

  • #46
    Originally posted by liam View Post
    You missed the formal verification part (hence the use of alloy).
    What you've described provides no such guarantees.
    The largest piece of formally verified kernel software that is seL4, which is roughly 10,000 lines:

    http://www.ertos.nicta.com.au/research/sel4/

    Filesystems often have 100,000 lines and are not isolated components. Formal verification of the filesystem code would require formal verification of the rest of the kernel. At that point, the amount of code that requires formal verification is on the order of 10 million lines. It is infeasible with current techniques.

    With that said, you said verification, not formal verification. The two are different. One can be done with rigorous testing. The other is currently a pipe dream.

    Comment


    • #47
      Originally posted by ryao View Post
      The largest piece of formally verified kernel software that is seL4, which is roughly 10,000 lines:

      http://www.ertos.nicta.com.au/research/sel4/

      Filesystems often have 100,000 lines and are not isolated components. Formal verification of the filesystem code would require formal verification of the rest of the kernel. At that point, the amount of code that requires formal verification is on the order of 10 million lines. It is infeasible with current techniques.

      With that said, you said verification, not formal verification. The two are different. One can be done with rigorous testing. The other is currently a pipe dream.
      I said verification, I then said using a tool like alloy. I don't feel like pointing out yet another aspect of my post that you missed. Since you care more about scoring petty points than listening to another person I'm not responding to this thread any further.

      Comment


      • #48
        hm,

        btrfs makes great progress & it survived 1-2 hardcrashes for me (where in the past I would get data corruption or lost files), that even on /home


        at least after the following (and some other most recent ones) patch it should be somewhat good to go in the data integrity department: http://marc.info/?l=linux-btrfs&m=137993254917058&w=2

        I actually expected it to do that already from the beginning or for some time

        but apparently I was proven wrong


        not sure how this couldn't have been detected earlier
        (was a shocking discovery, in a negative way, for me at first - but it can only get better, can't it ?)

        great work by Filipe David Borba Manana
        Last edited by kernelOfTruth; 09-23-2013, 05:38 PM.

        Comment


        • #49
          Originally posted by liam View Post
          I said verification, I then said using a tool like alloy. I don't feel like pointing out yet another aspect of my post that you missed. Since you care more about scoring petty points than listening to another person I'm not responding to this thread any further.
          liam, telling others how to do things will always end in failure because you are the only person in the world competent enough to implement your vision. If you want things to get done, you will need to spend your time doing them yourself instead of posting on forums in the vain hope that one of the incompetent masses will somehow manage to do what you want.

          With that said, I look forward to seeing the results of your work.

          Comment


          • #50
            Originally posted by kernelOfTruth View Post
            hm,

            btrfs makes great progress & it survived 1-2 hardcrashes for me (where in the past I would get data corruption or lost files), that even on /home


            at least after the following (and some other most recent ones) patch it should be somewhat good to go in the data integrity department: http://marc.info/?l=linux-btrfs&m=137993254917058&w=2

            I actually expected it to do that already from the beginning or for some time

            but apparently I was proven wrong


            not sure how this couldn't have been detected earlier
            (was a shocking discovery, in a negative way, for me at first - but it can only get better, can't it ?)

            great work by Filipe David Borba Manana
            If btrfs had an analog to ZFS' ztest tool, this would have been caught a long time ago.

            With that said, I just passed on the link to the Gentoo kernel team. Thanks for posting it.

            Comment


            • #51
              Originally posted by ryao View Post
              liam, telling others how to do things will always end in failure because you are the only person in the world competent enough to implement your vision. If you want things to get done, you will need to spend your time doing them yourself instead of posting on forums in the vain hope that one of the incompetent masses will somehow manage to do what you want.

              With that said, I look forward to seeing the results of your work.
              Let this stand as a testament to your inability to argue as an adult.
              You are now on my ignore list, so you need not respond to my response on the other thread.

              Comment


              • #52
                Originally posted by liam View Post
                Let this stand as a testament to your inability to argue as an adult.
                You are now on my ignore list, so you need not respond to my response on the other thread.
                You have ideas that everyone else consider infeasible. You are the only one with the motivation to try implementing them anyway. If you think they can be done, by all means try. If you succeed, you will demonstrate that you were the only competent one. There is nothing to argue.

                Comment


                • #53
                  Originally posted by ryao View Post
                  If btrfs had an analog to ZFS' ztest tool, this would have been caught a long time ago.

                  With that said, I just passed on the link to the Gentoo kernel team. Thanks for posting it.
                  they do seem to have tests (xfstest ?!) but that doesn't seem to cover the wide range of zfs tests (?), yet


                  anyways, there's another one on the highly critical side:

                  http://permalink.gmane.org/gmane.com...ms.btrfs/28394


                  there's another one: that the filesystem (superblock ?) isn't written to when it's mounted read-only - but I currently don't have its name at hand


                  with using btrfs so it probably means: using the latest rc and/or the latest stable + patchset from next kernel release/btrfs-next

                  to be sure that everything works as expected


                  I'll monitor progress closely - since, unfortunately, zfs can't be used in all cases for me

                  but where I can, zfs seems to be capable to ensure data integrity more

                  Comment


                  • #54
                    Originally posted by kernelOfTruth View Post
                    they do seem to have tests (xfstest ?!) but that doesn't seem to cover the wide range of zfs tests (?), yet


                    anyways, there's another one on the highly critical side:

                    http://permalink.gmane.org/gmane.com...ms.btrfs/28394


                    there's another one: that the filesystem (superblock ?) isn't written to when it's mounted read-only - but I currently don't have its name at hand


                    with using btrfs so it probably means: using the latest rc and/or the latest stable + patchset from next kernel release/btrfs-next

                    to be sure that everything works as expected


                    I'll monitor progress closely - since, unfortunately, zfs can't be used in all cases for me

                    but where I can, zfs seems to be capable to ensure data integrity more
                    The XFS Test Suite tests the VFS API for POSIX conformance. It does not test the filesystem's resilience to unclean unmounts. Its design does not permit that as it would mean crashing the system running them. Passing them also does not mean 100% POSIX conformance. LLNL uses them to test ZFSOnLinux and so far, there have been several patches merged to fix POSIX compatibility bugs (specific to the Linux port) that they missed.

                    As for ZFS fitting your use cases, is the main problem for you compatibility with the realtime kernels? It has been on my to do list, but I am right now in the middle of a memory management rewrite that should make ZFSOnLinux usable on 32-bit systems, such as the Raspberry Pi.

                    Comment

                    Working...
                    X