Jump to content
XPEnology Community

Leaderboard

Popular Content

Showing content with the highest reputation on 07/12/2018 in all areas

  1. Hi! I made a little tool which can help you to get your XPEnology up & running without installing any software. It contains (as portable versions): - Nirsoft's USB device view (helps to identify the VID & PID of your USB boot media) - V2.76 - XPEnology Serial Generator for DS3615XS, DS3617XS and DS916+ (a converted version of the HTML site) - Win32 DiskImager (to write your modified synoboot.img to your USB boot media) - V1.0 (only available in V1.4.1) - OSFMount x64 (to mount the synoboot.img and modifiy it) - V1.5 - Notepad++ (best editor for changing values inside grub.cfg) - V7.5.3 - Synology Assistant (useful tool from Synology to find your XPEnology and install DSM) - V6.2-23733 - TFTP/DHCP portable (a small TFTP, DHCP and Syslog server by Ph. Jounin) - V4.6.2 - MiniTool Partition Wizard 10 (helps assigning already formatted/written USB devices to modify existing grub.cfg) - V10.3 - SoftPerfect Network Scanner - V6.2.1 - USB Image Tool - V1.75 - New: Rufus - V3.3 In the section "Downloads" all links open corresponding websites to download the files. For beginners I added a small HowTo for bare-metal installation. Update New link for download: https://mega.nz/#F!BtViHIJA!uNXJtEtXIWR0LNYUEpBuiA The download link/folder also contains @IG-88's extra.lzma (V0.6) for the DS918+. You'll have to run it "As Administrator" because some of these tools (like Win32 DiskImager) need to be executed with higher rights. It's possible that the SmartScreen filter will give you a warning, because the EXE isn't signed. Bug reports and comments are welcome Cheers Current version: V1.4.2 (2018-11-19)
    1 point
  2. J4205 seems to work fine out of the box. I do have a PCIe SATA adapter which was recognized just fine. I also have 3 bonded NIC connections (1 internal, 2 gigabit ethernet USB 3.0 dongles), so I did have to increase the settings in synoinfo to reflect the additional NIC (standard is 2, had to bump to 3). Thank you guy that figured that out before me!!! Hw accelerated transcoding seems to work. One stream is averaging about 20-35% cpu via Emby streaming when I was playing it in a different resolution. Idles at 1-3% when running native resolution. The system has been rock solid for me. No resets, no dropped connections, no errors that I can see. I have 6x4TB WD Gold drives. Overall, 1.03a2 configured as DS918+ on the Asrock J4205 is running great.
    1 point
  3. Поставил 6.2 с загрузчиком 1.03а2 еще 3 июля. Все стало на железо, мигрировал. Все настроилось. МАК и SN от настоящего 918+. Все работает, один серьезный баг, при простое (при отключенном спящем режиме), все равно уходит в сон, и из него уже не возвращается, только перезагрузка. Если активно пользоваться (файлы, фильмы и прочее) , то проблем нет. Уже даже штатно обновился на 6.2 -update 1. Железо N3700-ITX - сетевухи две, встроенная и дополнительная интел EXPI9300PT. Обе видны и объединены в BOND.
    1 point
  4. USING PHYSICAL RDM TO ENABLE NVMe (or any other ESXi accessible disk device) AS REGULAR DSM DISK Summary: Heretofore, XPEnology DSM under ESXi using virtual disks is unable to retrieve SMART information from those disks. Disks connected to passthrough controllers work, however. NVMe SSDs are now verified to work with XPEnology using ESXi physical Raw Device Mapping (RDM). pRDM allows the guest to directly read/write to the device, while still virtualizing the controller. NVMe SSDs configured with pRDM are about 10% faster than as a VMDK, and the full capacity of the device is accessible. Configuring pRDM using the ESXi native SCSI controller set specifically to use the "LSI Logic SAS" dialect causes DSM to generate the correct smartctl commands for SCSI drives. SMART temperature, life remaining, etc are then properly displayed from DSM, /var/log/messages is not filled with spurious errors, and drive hibernation should now be possible. EDIT: SAS controller dialect works on 6.1.7 only (see this post). Like many other posters, I was unhappy with ESXi filling the logfiles with SMART errors every few seconds, mostly because it made the logs very hard to use for other things. Apparently this also prevents hibernation from working. I was able to find postings online using ESXi and physical RDM to enable SMART functionality under other platforms, but this didn't seem to work with DSM, which apparently tries to query all drives as ATA devices. This is also validated by synodisk --read_temp /dev/sdn returning "-1" I also didn't believe that pRDM would work with NVMe, but in hindsight I should have known better, as pRDM is frequently used to access SAN LUNs, and it is always presented as SCSI to the ESXi guests. Here's how pRDM is configured for a local device: https://kb.vmware.com/s/article/1017530 If you try this, understand that pRDM presents the whole drive to the guest - you must have a separate datastore to store your virtual machine and the pointer files to the pRDM disk! By comparison, a VMDK and the VM that uses it can coexist on one datastore. The good news is that none of the disk capacity is lost to ESXi, like it is with a VMDK. Once configured as a pRDM, the NVMe drive showed up with its native naming and was accessible normally. Now, the smartctl --device=sat,auto -a /dev/sda syntax worked fine! Using smartctl --device=test, I found that the pRDM devices were being SMART-detected as SCSI, but as expected, DSM would not query them. NVMe device performance received about a 10% boost, which was unexpected based on VMWare documentation. Here's the mirroring operation results: root@nas:/proc/sys/dev/raid# echo 1500000 >speed_limit_min root@nas:/proc/sys/dev/raid# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [raidF1] <snip> md2 : active raid1 sdb3[2] sda3[1] 1874226176 blocks super 1.2 [3/1] [__U] [==>..................] recovery = 11.6% (217817280/1874226176) finish=20.8min speed=1238152K/sec <snip> Once the pRDM drive mirrored and fully tested, I connected the other drive to my test VM to try a few device combinations. Creating a second ESXi SATA controller has never tested well for me. But I configured it anyway to see if I could get DSM to use SMART correctly. I tried every possible permutation and the last one was the "LSI Logic SAS" controller dialect associated with the Virtual SCSI controller... and it worked! DSM correctly identified the pRDM drive as a SCSI device, and both smartctl and synodisk worked! root@testnas:/dev# smartctl -a /dev/sdb smartctl 6.5 (build date Jan 2 2018) [x86_64-linux-3.10.102] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: NVMe Product: INTEL SSDPE2MX02 Revision: 01H0 Compliance: SPC-4 User Capacity: 2,000,398,934,016 bytes [2.00 TB] <snip> SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Disabled or Not Supported === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 26 C Drive Trip Temperature: 85 C <snip> root@testnas:/dev# synodisk --read_temp /dev/sdb disk /dev/sdb temp is 26 Finally, /var/log/messages is now quiet. There is also a strong likelihood that drive hibernation is also possible, although I can't really test that with NVMe SSD's. Postscript PSA: My application for pRDM was to make Enterprise NVMe SSD's accessible to DSM. As DSM recognizes the devices as SSDs, it then provides the option for scheduled TRIM support (which I decided to turn on over 18 months later). The TRIM job resulted in a corruption of the array and flagged the member disks as faulty. While a full recovery was possible, I don't know if that is was due to incompatibility of NVMe drives with the DSM TRIM implementation, or if it is an unexpected problem with pRDM not supporting TRIM correctly. You've been warned!
    1 point
  5. Unfortunately this didn't help. It turned out that 918+ has a different tools in /usr/bin and /usr/syno/bin. There are for example new these binaries that are missing on DS3515xs: root@DSM:~# nvme nvme-0.9 usage: nvme <command> [<device>] [<args>] The '<device>' may be either an NVMe character device (ex: /dev/nvme0) or an nvme block device (ex: /dev/nvme0n1). The following are all implemented sub-commands: list List all NVMe devices and namespaces on machine id-ctrl Send NVMe Identify Controller id-ns Send NVMe Identify Namespace, display structure list-ns Send NVMe Identify List, display structure create-ns Creates a namespace with the provided parameters delete-ns Deletes a namespace from the controller attach-ns Attaches a namespace to requested controller(s) detach-ns Detaches a namespace from requested controller(s) list-ctrl Send NVMe Identify Controller List, display structure get-ns-id Retrieve the namespace ID of opened block device get-log Generic NVMe get log, returns log in raw format fw-log Retrieve FW Log, show it smart-log Retrieve SMART Log, show it smart-log-add Retrieve additional SMART Log, show it error-log Retrieve Error Log, show it get-feature Get feature and show the resulting value set-feature Set a feature and show the resulting value format Format namespace with new block format fw-activate Activate new firmware slot fw-download Download new firmware admin-passthru Submit arbitrary admin command, return results io-passthru Submit an arbitrary IO command, return results security-send Submit a Security Send command, return results security-recv Submit a Security Receive command, return results resv-acquire Submit a Reservation Acquire, return results resv-register Submit a Reservation Register, return results resv-release Submit a Reservation Release, return results resv-report Submit a Reservation Report, return results dsm Submit a Data Set Management command, return results flush Submit a Flush command, return results compare Submit a Compare command, return results read Submit a read command, return results write Submit a write command, return results write-zeroes Submit a write zeroes command, return results write-uncor Submit a write uncorrectable command, return results reset Resets the controller subsystem-reset Resets the controller show-regs Shows the controller registers. Requires admin character device discover Discover NVMeoF subsystems connect-all Discover and Connect to NVMeoF subsystems connect Connect to NVMeoF subsystem disconnect Disconnect from NVMeoF subsystem version Shows the program version help Display this help See 'nvme help <command>' for more information on a specific command The following are all installed plugin extensions: intel Intel vendor specific extensions lnvm LightNVM specific extensions memblaze Memblaze vendor specific extensions See 'nvme <plugin> help' for more information on a plugin Or: root@DSM:~# synonvme Usage: synonvme --is-nvme-ssd <nvme path> check if a device is a nvme ssd --sn-fr-get <nvme path> get controllor SN and firmware reversion --model-get <nvme path> get nvme disk model --vendor-get <nvme path> get nvme disk vendor --get-location nvme_path / nvme_name get the pcie slot and card slot --smart-info-get nvme_path / nvme_name get the smart information --remaining-life-get nvme_path / nvme_name get the remaining life --temperature-get nvme_path / nvme_name get the temperature I have manually copies those binaries from 918+ to my XPEnology, commands are executed fine, but DSM is still not able to find the drive nor syno_hdd_util. It looks to me that there are also changes to the other binaries under /usr/bin and /usr/syno/bin. I suppose it's not a wise thing to overwrite everything by data from 918+ image on my XPEnology?
    1 point
×
×
  • Create New...