Announcement

Collapse
No announcement yet.

ZFS On Linux Runs Into A Snag With Linux 5.0

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

  • aht0
    replied
    Originally posted by pal666 View Post
    troll: bla bla bla
    Above quote says all..

    Leave a comment:


  • pal666
    replied
    Originally posted by lichtenstein View Post
    in order to reap the benefits I really would need more than one drive - otherwise zfs/btrfs can report but not correct errors.
    only zfs has such deficiency. btrfs can have multiple copies of data on one drive. and it has multiplie copies of metadata on one drive by default. btrfs is superior to zfs in any way possible

    Leave a comment:


  • pal666
    replied
    Originally posted by cdufour View Post
    this statement is pretty disrespectful to the people who contributed to ZFS *on Linux* since its fork from the original Sun/Oracle codebase.
    why one would respect people pushing out of tree crap?
    next step is respect to nvidia driver
    Originally posted by cdufour View Post
    I bet those people would gladly work without this license imbroglio that Sun has gotten them into.
    But Sun is dead and we all know what Oracle is.
    then those people should pull hands out of their asses and write linux filesystem which uses zfs on-disk format and implements zfs features, instead of shoving shit down your throat
    Originally posted by cdufour View Post
    A very sad state of affair, considering ZFS (on Linux) in the only *serious* (iow. production-grade, even if not advertised as such) open/free filesystem in its category.
    only idiot can consider unsupported buggy crap *serious* and production-grade

    Leave a comment:


  • pal666
    replied
    Originally posted by BeardedGNUFreak View Post
    Linux Slashdot kiddies still bitter over Btrfs crashing and burning.
    LOL
    kid, try to look at zfs bugtracker
    Such a clusterfuck.

    Leave a comment:


  • pal666
    replied
    Originally posted by skeevy420 View Post
    If BTRFS ever reaches feature parity with ZFS I'd likely switch.
    like no ability to run from single drive? why do you need such weakness parity?

    Leave a comment:


  • pal666
    replied
    Originally posted by GruenSein View Post
    This issue is so representative of the weird attitude that seems to cloud the Linux development community.
    if resulting os is the best, then attitude is the best, not "weird"
    Originally posted by GruenSein View Post
    It is because many people have wanted to use ZFS for a long time
    many people are not very smart, there is no reason to hinder linux because there are some idiots on the planet.
    Originally posted by GruenSein View Post
    and it is one of the most advanced FSs for its purpose.
    second only to btrfs. which, you know, already supported by linux
    Originally posted by GruenSein View Post
    They can choose to support a piece of software which would significantly extend the kernels capabilities.
    that piece of software is btrfs and it is already supported
    Originally posted by GruenSein View Post
    Also, I don't get why they don't simply restore the symbols that ZOL uses and mark them "deprecated" or whatever until the software depending on it can adapt (assuming there is an actual reason to remove them at all).
    that is obvious. you don't get trivial things because you are zfs zealot and that requires certain level of idiocy. those symbols were deprecated ten years ago

    Leave a comment:


  • pal666
    replied
    Originally posted by ferry View Post
    Even if ZFS code would be suddenly re-licensed, more is needed to get it upstream.
    that's for sure. it has to be rewritten into proper linux filesystem from "solaris filesystem with buggy solaris-to-linux compatibility layer". it will surely mean more changes than amd dc refactoring for example. imo it has no way to compete with btrfs, which is additionally not obsolete by design
    Last edited by pal666; 01-12-2019, 06:04 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by aht0 View Post
    I think it as a case of upstream breaking the internal API's yet again
    it is a case of typical butthurt idiot commenting. internal apis are internal exactly because they are designed to be broken on every release.
    Originally posted by aht0 View Post
    , not caring in the least how it would affect downstream.
    you are confusing downstream with freeloaders
    Originally posted by aht0 View Post
    Not that I actually particularly care, more power to FreeBSD.
    to freebsd which spends all power on maintaining forks of linux drivers, so that no power left for maintaining their fork of zfs, so that they are switching to maintaining fork of linux zfs driver again? well, next obvious step for powerful freebsd is to switch to btrfs
    Originally posted by aht0 View Post
    What particular efforts you would like to see already?
    upstream your piece of shit properly. including rewriting under proper license
    Originally posted by aht0 View Post
    The problem has just been found..
    that's your problem. feel free to apply ice to your butt
    Originally posted by aht0 View Post
    ZoL's been developed constantly AFAIK.
    s/developed/broken/
    Last edited by pal666; 01-12-2019, 08:53 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by kobblestown View Post
    Well, first of all, I get the impression that they did the extra work to make it not work.
    i get the impression that you are butthurt conspiracy theorist
    Originally posted by kobblestown View Post
    In my opinion ZFS provides the best solution for people who value their data above everything else, like I do.
    in my opinion only idiot would trust their data to be stored in some unsupported crap downloaded from internets

    Leave a comment:


  • oiaohm
    replied
    Originally posted by GrayShade View Post
    kernel_fpu_begin and kernel_fpu_end were switched to GPL exports in this commit from 2015.
    Look closer do note the preempt_disable() and preempt_enable() added to the GPL exported versions. This is to make those functions safe. The __ versions are unsafe.

    2015 look at the Linux kernel mailing list where is a ZoL developer saying hey I need this GPL exported function as normal exported? There is not one.

    Swaped to GPL exported symbols are from exported with a name starting with __ is in fact more permissive. GPL means this is for modules that are out of tree that are planning to merge ie GPL compatible license modules. __ at the start of name was prototype only not for out of tree modules at all. Using a __ starting function in Linux is the same as using a totally undocumented function with windows.

    If you read the 2003 description __kernel_fpu_begin and __kernel_fpu_end are not for out of tree kernel modules at all. Yet ZoL is using these. This is path to trouble. Yes in 2003 developer ask about third party modules and is told no by Linus. Every time Linus is asked that question about __kernel_fpu_begin and __kernel_fpu_end the answer stays the same.

    2 to 3 years is quite common migration allowance by the Linux kernel for kernel API. Something else to be clearly aware of with Linux kernel two exports in kernel space module API doing the same thing one is normally always deprecated this is the oldest one. If ZoL were watching the functions they were using they could have raise the issue to get this address with tones of time to spare.

    There are api rules with the Linux kernel. Do remember the request to remove __kernel_fpu_begin and __kernel_fpu_end goes though because all the internal usage are gone and due to starting with __ they don't have to ask third party modules if they are using it.

    Its one thing to be using a GPL exported symbol with the Linux kernel. Its a far deeper in the pits of hell to be using functions starting with __.

    Leave a comment:

Working...
X