The Class E Network

    • New

      RE Webmin and the default Samba setting:

      The samba version is (4.8.4) . It's current. The running assumption almost has to be "default" = "negotiate", which starts with the latest (SMB3.0). Otherwise, updated Windows clients wouldn't connect to it.
      ___________________________________________________________________

      ryecoaaron wrote:

      flmaxey wrote:

      I believe BTRFS doesn't handle power outages gracefully.
      XFS doesn't handle power outages all that well either.
      XFS, ZFS and others are examples of LAN administrator/Server Farm file systems that are almost guaranteed to be run on an UPS. This type of user and environs are not what OMV is targeted to.

      ryecoaaron wrote:

      flmaxey wrote:

      if the beta ships in a state that is close to what it is now.
      It will keep changing. Trust me. That is why I haven't ported all of the plugins.

      flmaxey wrote:

      If the latest version of Debian (Buster) is used in the final 5.0 product, it should be good for at least the next few years.
      It will use buster. And Volker won't release it before buster 10.1, I'm guessing. So lots of time for changes.
      So, in so many words, are you suggesting that the "BTRFS only" approach is still on the table? From what I gathered from the discussion thread on GitHub, there are more that a couple of dissenting opinions, about this, from experienced users.

      I'm being honest when I say, I "like" the ideas behind BTRFS. Really. There's kernel integration (automated upgrades), low resource requirements, and there's the novel ability to shrink a RAID array among other unique and novel features. For these reasons, when looking for something for bit-rot protection, BTRFS was my first choice. I even signed up for the projects mailing list and sifted through a chunk of their errata. My sum total impression was, "Not Ready", but I gave it the benefit of the doubt and tried it in a single disk setup. The results? Not so good. Two serious failures, with a device that's not on-line very much.

      These things appear to be obvious to those who really look at it:
      BTRFS is not fully developed, the CLI utilities are still inadequate and even the experts don't really know how to "Rx" a busted file system. (I became painfully aware of this when trying to fix BTRFS filesystem issues.) Again, more votes for, "Not Ready".
      _______________________________________________

      - Let's just assume that BTRFS doesn't like power outages. (My anecdotal experiences are certainly not empirical.) Now, let's look at OMV's target user base which consists primarily of, "small businesses" and "home users". As previously mentioned, I'm going to estimate that thousands of these users are running without an UPS.
      - Given OMV's user base - NOOB's and non-LAN admin types; the base file system requirement should be heavily biased toward stability and reliability. Along those lines, EXT4 is proven - BTRFS is not.
      - Just because BTRFS is easy to write code for, doesn't negate the basic requirement for stability and reliability.

      I can easily see where vfrex's comment about setting up better support for BTRF makes sense. Add support for BTRFS in the GUI and see what happens, as a sort of BETA test. But jumping into BTRFS, without broad based experience and testing, to the exclusion of all else, seems like a reckless move. There's no reason to rush this and risk the loss of a substantial percentage of the user base.

      I'll get off my NOOB'ish soap box now... :)
      I realize the final decision is Volker's and those who are working on this project (unpaid) have the liberty to do as they please.

      On the other hand,, well,,, I guess we'll see what happens...

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • New

      There, I put my 2 cents on github.
      Hopefully, Volker will read it and at least give it due consideration (about 5 seconds ).

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • New

      flmaxey wrote:

      XFS, ZFS and others are examples of LAN administrator/Server Farm file systems that are almost guaranteed to be run on an UPS. This type of user and environs are not what OMV is targeted to.
      xfs is actually the default filesystem for Redhat/CentOS even on desktop systems and laptops
      .

      flmaxey wrote:

      So, in so many words, are you suggesting that the "BTRFS only" approach is still on the table?
      Not sure. I don't get to make that decision.

      flmaxey wrote:

      Just because BTRFS is easy to write code for, doesn't negate the basic requirement for stability and reliability.
      I don't think he would pick it because it is easy to write code for. It is the only option to write code for since he doesn't like the zfs license situation.

      flmaxey wrote:

      BTRFS is not fully developed, the CLI utilities are still inadequate and even the experts don't really know how to "Rx" a busted file system. (I became painfully aware of this when trying to fix BTRFS filesystem issues.) Again, more votes for, "Not Ready".
      I'm not disagreeing with that but there are commerical NASes using btrfs.

      flmaxey wrote:

      Hopefully, Volker will read it and at least give it due consideration
      That is all we can do :)
      omv 4.1.17 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • New

      ryecoaaron wrote:

      xfs is actually the default filesystem for Redhat/CentOS even on desktop systems and laptops
      Redhat :) ... XFS,, coming to us from the same folks that depreciated BTRFS. (Can you see a bit of irony in that? :) )
      Still, XFS has a longer history and performance record when compared to BTRFS.

      Laptops and Desktops, from a file system perspective, are two distinctly different devices. One has an UPS built in, the other does not.
      ____________________________________________________________

      Along these lines, it seems we've come full circle on file systems. Back in the days of Windows 3.X, (FAT) it was possible to lose power and end up with a system that wouldn't boot again. (It happened to me once.)
      Then effort went into writing journaling file systems that could survive dirty shutdowns, with processes built in to "clean" the filesystem (if needed) on the next boot. A good degree of fault tolerance has been achieved, over the years, and EXT4 is a good example.

      Now the marching banner seems to be integrating volume management into the file system, drive aggregation (RAID like options), snapshots, etc. Interestingly, as the power grid ages and gets worse as time goes on, fault tolerance is falling to the wayside as the need for it is ever increasing.
      With the baton handed to a new generation, it appears that we're doomed to learn the same lessons, over and over again. Power and fault tolerance, "dull and boring" where new features have "spark and glitter" and are exciting. Why should fault tolerance hamper the development of the new and improved? (We'll never learn.... :) )

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: edit ().

    • Users Online 1

      1 Member (1 invisible)