Announcement

Collapse
No announcement yet.

openSUSE 13.2 To Use Btrfs By Default, Major Changes

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

  • #11
    Originally posted by zanny View Post
    I thought Plasma Next was just the codename for all the qtquick2 based stuff they are changing for kde5. Everyones going to call it kde5 anyway.
    I'm almost sure that KDE Framework 5 is the name for the libraries and the applications, while Plasma Next is the name of the shell/desktop only.

    Comment


    • #12
      Originally posted by cbamber85 View Post
      Didn't they just spend ages porting YasT to Ruby!?
      I think exactly the same but looking at Suse announcement, they will port only de front-end, it seems that the front-end was using Qt so long ago, the core development will continue in ruby.

      Comment


      • #13
        Originally posted by Spittie View Post
        Yes, I know there's no KDE5, but I'm not going to write KDE Framework 5/Plasma-Next all the time.
        PW2 (Plasma Workspaces 2) is one character shorter than "KDE5".

        Comment


        • #14
          Originally posted by Awesomeness View Post
          PW2 (Plasma Workspaces 2) is one character shorter than "KDE5".
          No it's not. Let's count: "PW2 (Plasma Workspaces 2)"

          That's 25 characters.

          And yes, you need all of them, because nobody knows what PW2 is supposed to stand for.

          Comment


          • #15
            Originally posted by smitty3268 View Post
            No it's not. Let's count: "PW2 (Plasma Workspaces 2)"

            That's 25 characters.

            And yes, you need all of them, because nobody knows what PW2 is supposed to stand for.
            Plasma 2 is reasonably fast to type and pronounce though.

            Comment


            • #16
              Originally posted by zanny View Post
              I'm still wondering where my fsck.btrfs is. I use it on all my machines, but whenever something *does* go wrong, like corrupted extents, I have to boot to a usb drive to run btrfsck on my root partition. And even then, btrfsck is like a meat cleaver to fix problems (especially in repair mode) when you really just want a steak knife to prune the damage.
              From what I know, the intention of a fsck.btrfs is not there because it should not be needed just like defragmentation.

              You could mount the partition with the recover mount parameter, but that is not recomended unless you are instructed to do so.

              I'm surprised they declared butterfs stable so fast. Good for them.

              Comment


              • #17
                From what I know, the intention of a fsck.btrfs is not there because it should not be needed just like defragmentation.
                btrfs would be a bad example of "not needing defragmentation" because btrfs volumes do see file fragmentation due to the way CoW works. There is even a mount option of autodefrag to have background processes fixing the most fragmented files.

                Of course, background defragmenting beats the crap out of the mess of running a defragmenter on Windows and crippling the machine until it finishes.

                Also, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.

                Comment


                • #18
                  Originally posted by zanny View Post
                  btrfs would be a bad example of "not needing defragmentation" because btrfs volumes do see file fragmentation due to the way CoW works. There is even a mount option of autodefrag to have background processes fixing the most fragmented files.
                  Yes, I was referring to defrag as a program.

                  Originally posted by zanny View Post
                  Of course, background defragmenting beats the crap out of the mess of running a defragmenter on Windows and crippling the machine until it finishes.
                  If done properly.

                  Originally posted by zanny View Post
                  Also, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.
                  Then fix your setup .

                  Comment


                  • #19
                    Originally posted by zanny View Post
                    Also, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.
                    Real question: would fsck help in such case (for some other file system)?

                    Comment


                    • #20
                      ZFS is production for large data, use ECC RAM. Btrfs welcome.

                      BTRFS is all great for Linux (had it been ported anywhere else?) , and I would definitevely use it for Linux installs for Workstations and some servers.
                      But, isnt ZFS in productioin for, say at least 8 years now and counting?

                      I got used to not to worry about FSCK on boot, because it does not exist on ZFS and that could be decesieve factor when you have large number of disks and do not want to wait for eons for server to boot.
                      And oh, yes, OpenZFS is supported in Linux with ZFSOnLinux kernel module (booting from ZFS), ZFS on FUSE, FreeBSD's default, Solaris (up to v28) and illumos distros (Openindiana, SmartOS etc) and OSX with 2+ implementations (think that Windows is on the way).

                      At the present time I would definatevly give thumbs up to Btrfs on Linux for Boot from it and finally, after 8+ years catching up with Opensolaris file system.
                      But everyone wanting to be able to count on their (large) data is better off with ZFS data pools in production and multiplatform use.

                      Seems like expensive RAID controller cards are going to the history and large (ECC!) RAM is "new RAID".
                      Last edited by Markore; 04-13-2014, 04:06 AM.

                      Comment

                      Working...
                      X