Jump to content

lalaw

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Quick update here, I was running some benchmarks today. Off the top of my head: 1. local SSD was getting something like 1200 MB/s write and 1500 MB/s read 2. USB connected HDD was getting ~175 MB/s write and 175 MB/s read 3. NAS (not helios) connected at 1 Gbps was getting ~100 MB/s read/write 4. Helios in DAS mode and on Raid 10 was getting approximately 170 write and 250 read. 5. Helios in DAS mode on a single drive was getting 190 write and 220 read. For the capture 1 use case, I think a solid contender. Unfortunately, as I described in the other thread, I can't get my whole array presented in DAS mode (it wants to give me 200GB for a 18TB array). Updated: also ran on a single drive instead of the array. Slightly better write numbers with slightly worse read numbers. Also, frustratingly, drive capacity was off -- this time showing 1.2 TB instead of 10.
  2. One minor update. I managed to create and mount an exFat drive in OMV by installing the fuse extensions. I managed further to mount the drive in DAS mode on my Mac. It is recognized as the full 20TB capacity, BUT I get an error '"macOS can't repair the disk "helios64" You can still open or copy files on the disk, but you can't save changes to the files on the disk. Back up the disk and reformat it as soon as you can." Here's my command: sudo modprobe g_mass_storage file=/dev/md0p1 iManufacturer="Kobol Innovations" iProduct="Helios64" iSerialNumber="1234567890" ro=0 removable=1 stall=0 I am able to read the small test files I put in the partition, but the disk is not writable. When I try to format the disk from the Mac, it drops back down the the 210GB capacity.
  3. Update. Good news: shift to 4.4 makes the array show up via DAS mode. Bad news: I'm pulling my hair out because of some weird issues: 1. Had what seemed like random partitions pop up and that required me to do a bunch of hackery with fdisk/parted 2. Finally got to setting up the array as a 18.2 TB partition. Plugging into the Mac, I always get an uninitialiized (or unrepairable) error. The weird part is that if I try to format or repair the disk, I always get something like 210 GB of capacity. This is using ExFat, HFS+, etc. Occasionally, I can get the Mac to recognize it as an 18TB, unformatted device. But after formatting, it always goes back to 210GB. Anyone with a bit more insight that can help me troubleshoot whats going on?
  4. Continuing from above. Documenting my full process: 1. Put helios64 into recovery mode. 2. Use BalenaEtcher to write Armbian_20.11.10_Helios64_buster_current_5.9.14.img.xz to eMMC. Reboot 3. Go through 1st login on helios64, setup userrname/password. Reboot 4. Go through armbian-config to install OMV. Reboot 5. Per 25-NOV post, created dwc3-0-device.dts and added as an overlay. Reboot 6. Login to OMV. Setup RAID 10 array. 7. RAID array in sync. Added device (sudo modprobe g_mass_storage file=/dev/md0 iManufacturer="Kobol Innovations" iProduct="Helios64" iSerialNumber="1234567890") No device on Mac. 8. Tried unplugging, replugging USB cable. No device on Mac 9. Tried different USB ports. No device. 10. Tried removing and re-adding (modprobe -r, modprobe). No device. 11. Tried removing and re-adding overlay (from /boot/armbianEnv.txt). N device. 11. Tried rebooting Helios64 and repeating 8-11. No device. I'm going to flash 4.4 back again and see what I get. Will report back
  5. No warnings. I wonder if it had to do with trying to export it before it was fully sync'ed. Just tried removing (sudo modprobe -r g_mass_storage) and recreating using just sdf, but nothing showing still on the Mac.
  6. Documenting my full process: 1. Put helios64 into recovery mode. 2. Use BalenaEtcher to write Armbian_20.11.10_Helios64_buster_current_5.9.14.img.xz to eMMC. Reboot 3. Go through 1st login on helios64, setup userrname/password. Reboot 4. Go through armbian-config to install OMV. Reboot 5. Per 25-NOV post, created dwc3-0-device.dts and added as an overlay. Reboot 6. Login to OMV. Setup RAID 10 array. ... To be updated after array is synced. Side note, I remembered that I have a 5th drive that is not part of the array that I could try to mount: Unfortunately, no device detected on the Mac.
  7. Hi! I followed your overlay instructions at the top of this thread. Here's the exact command (after setting up the overlay/rebooting): sudo modprobe g_mass_storage file=/dev/md0 iManufacturer="Kobol Innovations" iProduct="Helios64" iSerialNumber="1234567890" removable=1 (Note: I tried both with/without the 'removable' option specified) I tried plugging/unplugging. Rebooting. Different ports, etc. I'll try to flash back to 5.9 one more time to see if I did something differently. Do you have any idea why the gadget would present as such a small capacity?
  8. Quick follow up with another curiosity. I decide to try to flash the legacy 4.4 image, and the gadget DOES show up in MacOS. Here's the relevant syslog Feb 2 18:21:56 helios64 kernel: [ 754.704394] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 Feb 2 18:21:56 helios64 kernel: [ 754.704408] g_mass_storage gadget: g_mass_storage ready Feb 2 18:21:56 helios64 kernel: [ 755.092846] g_mass_storage gadget: super-speed config #1: Linux File-Backed Storage However, instead of presenting the full 18TB that it should be, the size is only 210GB. Anyone seen this before?
  9. I've been trying to set this up, but can't get my Mac to recognize the g_mass_storage device. Any troubleshooting tips? I don't see anything in the System Information panel; I was able to communicate via USB to the helios64 when in recovery mode (e.g. flashing the Armbian ROM), so I assume my connection is OK. I have the following in the syslog: Feb 2 12:26:13 helios64 kernel: [ 49.903323] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 Feb 2 12:26:13 helios64 kernel: [ 49.903337] g_mass_storage gadget: g_mass_storage ready My goal is to setup the helios64 in DAS mode so I can format the RAID group to exFat and use it for photo processing. But I can't seem to get the device to even be recognized on the Mac (unlike when in recovery mode, it shows up as an uninitilized disk)
  10. Bunch of random questions: 1. Any ETA on when DAS mode would be rolled into kernel 5.x? 2. Any ideas on how I can get around the 1 post per day limitation? If I can take the liberty, I'd like to describe my setup and solicit suggestions. I have am running Capture1 on a Mac connected via USB-C. I'd love to use the Helios64 as a r/w DAS for the Capture1, while still making it available (perhaps ro) to enable network access and backup. Some issues that I foresee: 1. Because the DAS mode is using the Mass Storage Gadget, it seems like my choices are to expose the entire disk/block device or to have a file that simulates the block devices. The problem with the file is that it would no longer appears as a filesystem in NAS mode, correct? 2. If my assumption in (1) is true, then I have to expose the entire disk. For the Mac to read the disk, I assume I need to use exFat or Fat32 (as ext4, ZFS, etc. support on Mac sound spotty for r/w) 3. exFat/Fat32 don't appear to be first class citizens in the world of OMV, but it sounds like I can cobble together support and mount those disks manually 4. Once sorted out, would it be possible to combine the Capture1 disk with other NAS-dedicated disks in a SnapRaid group for redundancy? And expose the Capture1 disk as a (r/o) share on the NAS? My hope is that I can have Capture1 see as a local DAS for work, I can get some level of disk failure redundancy though period SnapRaid parity syncs, and I can create some sort of rsync job to maintain an offsite backup in case I have a bigger failure.
  11. This is my exact use case. My hope is to get DAS mode running for my main machine, while keeping photos accessible to other devices and backing up offsite. My reading seemed to indicate that using Helios64 as a Mass Storage Gadget was still a work in progress; I'd love to know if anyone knows otherwise.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines