Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: openSUSE 13.2 To Use Btrfs By Default, Major Changes

  1. #11
    Join Date
    Nov 2013
    Posts
    145

    Default

    Quote 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.

  2. #12
    Join Date
    Jan 2014
    Posts
    1

    Default

    Quote 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.

  3. #13
    Join Date
    Dec 2010
    Posts
    1,229

    Default

    Quote 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".

  4. #14
    Join Date
    Oct 2008
    Posts
    3,214

    Default

    Quote 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.

  5. #15
    Join Date
    Sep 2012
    Posts
    780

    Default

    Quote 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.

  6. #16
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote 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.

  7. #17
    Join Date
    Dec 2012
    Posts
    573

    Default

    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.

  8. #18
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote 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.

    Quote 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.

    Quote 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 .

  9. #19
    Join Date
    Sep 2012
    Posts
    780

    Default

    Quote 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)?

  10. #20
    Join Date
    Sep 2007
    Posts
    52

    Post 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 at 05:06 AM.

Posting Permissions

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