GnuBee Personal Cloud 2 -- 'Open Source NAS' for 6 x 3.5" disks

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • GnuBee Personal Cloud 2 -- 'Open Source NAS' for 6 x 3.5" disks



      Quoting the campaign on CrowdSupply: A low-cost, low-power NAS for 3.5" drive

      This is some sort of an open enclosure combined with a PCB based on a MIPS MediaTek SoC with 3 GbE ports and 3 ASM106x SATA controllers hanging off a dedicated PCIe lane each so in theory a pretty decent setup to access up to 6 SATA disks. Unfortunately I've not seen any reasonable benchmark numbers so far using this SoC accessing more than one disk in parallel (all I've came accross were single disk benchmarks with slow 2.5" HDD or these pretty low numbers from Mqmaker's WiTi board -- but as we know without some tweaks slow ARM or MIPS SoCs won't perform well as OMV/NAS boxes anyway).

      Some thoughts/considerations as usual on CNX: GB-PC2 as well as the older 2.5" variant (check especially the comments section)

      While I really love the idea behind (creating a NAS relying only on FLOSS components) I don't understand the implementation (obviously only outdated kernels available, loading a binary firmware recommended and since this device needs Debian mipsel architecture you're dependent on such a repo for OMV too). Since GNUBee folks advertise OMV capabilities they might comment here?

      Anyway: it feels kinda bizarre assuming that a MIPS based NAS thingie couldn't be the right choice in 2017 given that almost all the customers 2 decades ago that had really large storage setups were running on MIPS (SGI servers with IRIX and XFS which wasn't available anywhere else back then) and that the most beautiful UNIX box I ever had running also felt pretty fast wrt storage back then :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 2 times, last by tkaiser ().

    • ness1602 wrote:

      looks good
      Hmm... after thinking a little bit longer about center of gravity, rotation, vibrations, impact on performance (maybe longevity too?) the device with its current design (the side plates) definitely does not look good to me any longer :)

      And then dealing with a Debian mipsel architecture here is something different compared to the officially supported architectures (speaking about armhf and arm64)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Why would this mounting be any different than a server that stores the spindles vertically (like an N40L) that doesn't have any vibration dampening (stored rigidly in a hot swap tray)?
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Why would this mounting be any different than a server that stores the spindles vertically (like an N40L) that doesn't have any vibration dampening (stored rigidly in a hot swap tray)?
      Since it's somewhat different if you only fix the drive at 4 points below gravity centre with a the spindles allowed to swing freely above?


      I did a quick test with a 3TB Seagate Barracuda one time fixed in a drive cage, the other time simulating the GnuBee fixation using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2':

      Source Code

      1. GnuBee style random random
      2. kB reclen write rewrite read reread read write
      3. 102400 4 58791 73148 69835 70883 1152 919
      4. 102400 16 112256 149872 138120 146112 4325 3830
      5. 102400 512 148584 148143 154176 163686 60286 99389
      6. 102400 1024 146546 144482 156688 166931 85745 115663
      7. 102400 16384 132835 148271 158633 161372 152230 132610
      8. Fixed random random
      9. kB reclen write rewrite read reread read write
      10. 102400 4 64330 71447 69835 72784 1153 924
      11. 102400 16 135730 153744 143659 152118 4350 4311
      12. 102400 512 150105 149943 154109 163434 61183 95582
      13. 102400 1024 148360 148200 154675 163333 86938 83239
      14. 102400 16384 138317 151907 151418 161071 154072 136433
      Display All
      Only minimal advantages with 16K blocksize but this might change once there are a few more disks adding to overall vibrations? I wonder whether GnuBee folks should not consider making the side plates taller and fix the disks on top too.

      Edit: One of my personal heroes explaining how they found one missing screw not properly fixating a disk somewhere in a huge storage box with dtrace since this single disk showed latency too high. Worth watching IMO :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser ().

    • New

      I understand how vibration affects drives. I've done plenty of vibration analysis on finegrinders that are accurate to a few millionths of an inch. I was just asking why you thought it was worse than other styles especially hot swap sleds.

      tkaiser wrote:

      Since it's somewhat different if you only fix the drive at 4 points below gravity centre with a the spindles allowed to swing freely above?
      They don't really swing freely above since they are secured in the sata port on the bottom. Very few systems secure all four sides. The amount of flex or distortion in a 3.5" drive is minimal since most are ribbed and the lid layers the enclosure making it even more rigid.

      tkaiser wrote:

      a few more disks adding to overall vibrations? I wonder whether GnuBee folks should not consider making the side plates taller and fix the disks on top too.
      More disks attached to the single plate transferring vibration to all the other drives is worse than the direction and mounting points of the drives. I was never impressed with my N40Ls sleds since they were not tight in the slot and would rattle with a couple of old 7200 rpm drives in it. I think the gnubee folks should figure out some isolation dampers between the plates and the drives.
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Users Online 1

      1 Guest