Jump to content
XPEnology Community

flyride

Moderator
  • Posts

    2,438
  • Joined

  • Last visited

  • Days Won

    127

Posts posted by flyride

  1. 55 minutes ago, DrStorage said:

    I use a LS controller passthrough to the VM in ESXi all the drives serial numbers are sdb -> sbi. This makes it hard to find a faulty drive. Any workaround for this?

     

    see bold text below

     

    On 5/28/2022 at 9:50 AM, flyride said:

    System-Specific Parameters and SATABOOT

    <snip>

    The Drive Slot Mapping configuration step is the same, but the outcome is different when SATABOOT is in use.

    • ./rploader.sh satamap will enforce the prohibition on data disks attached to SATA0 and warn if this configuration exists.
    • SataPortMap and DiskIdxMap are configured to remove a blank slot between the SATA0 and SATA1 controllers.
    • SCSI/SAS controllers or HBAs (either passthrough or virtual) ignore satamap functionality. When SATABOOT is also in use, there is an unavoidable blank slot between the last SATA controller and the first SCSI/SAS controller or HBA.

     

    56 minutes ago, DrStorage said:

    my network upload is extremely slow, and gets an network error seconds after trying to move a file to the server. Moving files off are fine. Copying files from one share to another on the same server is fine. Upload from a windows VM in the same ESXi server is slow and getting network error. I'm using virtual vmxnet3 driver. Anyone experienced the same issue?

     

    I haven't encountered anything like that in many years of ESXi hosting of 6.x and 7.x DSM guests.  You'll probably need to post more information (preferably in a new thread request for help) for diagnostic help.

  2. 16 hours ago, phone guy said:

    I have a kind of related question for everybody.... I have a proxmox redpill DS3622 build. Running paravirtual NIC in Proxmox with V9F ext drivers. I also have a PCI passthru Ethernet port, I used one of the intel ports onboard from the server motherboard. Both work fine, the Intel NIC in pci pass thru didn't require any additional ext drivers to work.  Each has its own different IP, they are not bonded, so I know which port I am using.  I am getting different smb speeds when copying over the network in Windows.

     

    Scenario 1:

    In windows, open network, open icon for DS3622, open temp shared folder, now drag and drop 1.1gb file.. I get a maximum transfer of 60mb/sec (\\ds3622\temp)

     

    Scenario 2:

    Change location in windows explorer to direct ip (\\192.168.1.100\temp) I get 110mb/sec. The proxmox virtual nic is ip 100, and the pci passthru is ip 101 (\\192.168.1.101\temp), same speeds on either direct ip.

     

    So if the window shows a direct ip in the location, the speed is nearly doubled. If it show ds3622 its about half speed...? any clue?

    This is a repeatable experiment. I get similar results from different pcs on the lan, different files, and the results almost always the same, give or take a few mbs/sec

    There are a bunch of different ways for name resolution to happen.  Do you know which is in use for the test?

     

    I would control that to the simplest, fastest possible exchange.  If you have a small number of clients, define it in the hosts files.

  3. 5 hours ago, Bullseye said:

    Anybody have same feeling, that 7.1 is much slower when i copy file over LAN than on 6.2.3 ?
    On 6.2.3 i have almost 90MB/s, on 7.1 i have less than 10MB/s.

     

    You don't suppose after all this development that someone would have noticed a 90% speed decrease?

     

    There is some other problem, it's not 7.1 or RedPill.

    • Like 2
    • Haha 2
  4. In the troubleshooting section there are several strategies to mitigate bad ports.

     

    It may not always be possible to resolve the problem depending upon the motherboard design.  If that is the case, consider virtualizing where individual ports can be selected and attached to a virtual SATA controller (i.e. ESXi RDM) or choose a Device Tree platform where each port is specified.

    • Like 1
  5. 8 minutes ago, mrmvd said:

    Unfortunately, DSM 7.1 does not work very well with the number of disks greater than 16, all these problems with Sataportmap do not allow us to think that in the future, with the restructuring of the disk system, DSM 7.1 will not fail and will not be blocked.

     

    Anyone who thinks there is a guaranteed upgrade path to new DSM versions via XPenology should spend some time reviewing the FAQ and the support for prior DSM versions.  Regardless, I don't think this is a reason to compromise the DSM installation you have and are using now.  But to each their own.

     

    With direct access to disk devices, DSM offers valuable features that hardware RAID simply cannot do, including proactive device management and repair, dynamic btrfs fire corruption repair using redundant information within the array, and RAIDF1.

  6. It's nothing more than a way to differentate the platforms.

    The underlying DS3622xs+ platform supports the largest number of CPU cores, and technologies (RAIDF1, HBA support) consistent with larger-scale arrays.

     

    The loaders can override the total number of drives on any platform so that is a practical irrelevance.  But a loader cannot add kernel core support, or the RAIDF1 code.

  7. It isn't a matter of software RAID working with the motherboard.  The OS is providing the RAID.  You don't want the controllers, or the BIOS to be doing it.

     

    A motherboard with 6 AHCI compliant ports is a good base for DSM.  If you add additional ports with an AHCI-compliant controller, no drivers are required.  The ASR-7805 will likely require drivers as it is a host bus adapter.  HBAs are usually quite a bit more expensive than plain AHCI SATA controllers.  

     

    Look for @IG-88's threads on good AHCI controller options for something to start with, unless you really need 24 ports or whatever you will get from an HBA.

    • Like 1
  8. The point of DSM is to provide RAID via software.  It adds many features that "hardware" RAID cannot provide, such as self-healing with integration with btrfs, and RAID modes that are not possible with hardware, such as RAIDF1.

     

    So you should be looking for AHCI-compliant controllers to connect your disks.  Some HBAs can do this (aka "IT" mode).  Simple SATA controllers can do it as well.

  9. 24 minutes ago, unmesh said:

    I've been successfuly running DSM 6.2.3 on the DS3615xs platform as a VM on ESXi7 with Jun's bootloader and a single RDMed hard drive for a while now and was wondering if there was any consensus on whether TCRP was stable enough to migrate one's data to it.

     

    The unusual situation with RedPill compared with Jun's loaders is that many different parties are always tinkering and improving it.  So there is always code that is untested/alpha if you want to try it. 

     

    The stickied links in the FAQ and Tutorials (such as this) refer to the code and procedures that are part of "stable" TCRP which is deliberately frozen with the idea that it would remain stable and predictable.  There are things about DSM 7 that are more finicky than DSM 6, but TCRP is more flexible in how it can be configured.

     

    If you are chasing the latest stuff on every dev thread, good luck to you.

     

    28 minutes ago, unmesh said:

    If so, would a best practice be to first get DSM 7.1.0 up and running with a virtual disk as the target drive and then add the RDMed drive (and then optionally removing the virtual drive) or would that mess up the sata diskmap generation process that is done in TCRP?

     

    Best practice would be the testing and migration procedure specifically outlined in the tutorial here:

    https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

     

    29 minutes ago, unmesh said:

    If I use the DS918+ platform instead of DS3615xs, would I be able to retain the data on the RDMed drive?

     

    Yes, the migration install doesn't require the platforms to be identical.

  10. 3 hours ago, Timon-H said:

    Found "00:17.0 Intel Corporation Device 7ae2 (rev 11)"
    Detected 8 ports/3 drives. Bad ports: 1 2 3 4. Override # of ports or ENTER to accept <8>

    Computed settings:
    SataPortMap=8
    DiskIdxMap=00

    WARNING: Bad ports are mapped. The DSM installation will fail!

     

    I haven't seen anyone successfully map over bad ports with Sata remap.  The rploader satamap is reporting your bad ports above by searching for DUMMY values in dmesg and reindexing the information to your controllers.

     

    The B660 chipset appears to share silicon with the H670 which has 8 SATA ports.  Intel locks out the first 4 in your motherboard.

    https://images.anandtech.com/doci/17162/2022_CES_Pre-Brief_Dec 15 Final-page-029.jpg

     

    DSM won't install with ports that are electrically present and not functional (hence the DUMMY status).

     

    See the tutorial troubleshooting section for some workaround options, although they aren't really good.

    https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

     

    You will have the best results with one of the folllowing:

    1. Convert to a virtualized installation, connect the storage to the hypervisor and then attach the disks to a virtual SATA controller (RDM in ESXi, for example)
    2. Use a device tree platform (i.e. DS920+) which doesn't use SATAMAP.  There is some evidence that you can use a device tree configuration manually on any platform version, but this is incompletely tested.
    3. Disable your on-board SATA controller and add a PCIe SATA controller that doesn't have bad ports (this is probably least desirable with an ITX motherboard)

     

  11. 7 hours ago, urundai said:

    @flyride, does this mean that the 21GB disk is now attached SATA 0 controller - as Sata 0:1? I have this exact setup and trying to understand what deleting SATA 1 controller means :)

     

    Most of the ESXi XPe tutorials suggest that the user installs a virtual disk as an example device, separate from the loader vmdk.  Maybe you want to use a virtual disk in your installation, and maybe you would rather use a passthrough controller.  It is not always clear and often people install the virtual disk when it isn't necessary.

     

    Because we map the loader vmdk away (with SataPortMap=10 and DiskIdxMap=1) that causes the vmdk to be assigned outside of the addressable port range (assuming 16 ports).  Any SATA devices on that same controller (SATA0) would be similarly not addressable, so we ask the user to add a second SATA controller (SATA1) for the virtual disks (or RDM devices) to be attached to.  Those are then addressed at the beginning of the port range (SataPortMap=1000 and DiskIdxMap=1n, where n is the number of virtual disks).

     

    In @aerolite's case, they did not need a "21GB" virtual disk because data drives were being delivered via LSI HBA but it appears they had created one and set up the virtual controller as above.  Non-SATA ports tack onto the end of whatever SATA ports are reserved by SataPortMap/DiskIdxMap.  So they were asking how to get the starting port for the HBA back to the beginning of the range.

     

    Therefore, since they do not need the 21GB disk it can be deleted, the SATA1 controller also deleted, and SataPortMap and DiskIdxMap adjusted.  With no SATA devices in the system (aside from the loader vmdk) then SataPortMap=1000 and DiskIdxMap=1.  Unusually, the last SataPortMap 00 is required so that the HBA knows where to start addressing its ports.  Unfortunately, there is an anomaly exhibited with TCRP/DSM7/HBA's that causes a single port gap between the last SATA disk and the first HBA disk.  I haven't figured out how to make that go away outside of a device tree configuration.

    • Like 1
×
×
  • Create New...