flyride
-
Posts
2,438 -
Joined
-
Last visited
-
Days Won
127
Everything posted by flyride
-
Please be assured that array corruption will not occur because USB drives are in the slots where there used to be SATA. Every array member has member information in a superblock metadata. So the worst that can happen is that the array won't start. You might not be able to fix it however until someone can get to the device to remove USB. Just curious though, in the above example of reboot problem, what happens if you eject the USB's using the DSM UI?
-
I don't think this is correct. AFAIK maxdisks always correspond to the internal SATA only, even when Syno has external DX517 etc. This is what you need if you are going to use 6 SATA + 8 LSI + 16 LSI You then need 30 maxdisks and bitmaps to match 30 SATA disks. Does this really happen? I would think that the SATA drives are mapped first in the boot prior to USB. Have you tested this? I do understand if you have a SATA drive failure, then reboot, that a USB drive would then map into the SATA namespace, but the SATA drive already failed, so what is the problem? Fix and reboot. Also, if two or more array members are missing, there will be no RAID5 start, so no damage possible to the array. So again, just fix and reboot. I think you already have your solution to all this.
-
Operationally, if you have all your HDDs in place, the USB work correctly. Why don't you just go with that and understand USB won't map right if you insert while HDD's are down.
-
Yes, that works. The last complaint is doing that makes the USB disk mapper into the /dev/sd namespace broken and USB drives appear in the internal mapping range despite correctly configuring the synoinfo.conf bitmasks. I don't think it can be fixed without the standard and proper alignment of sataportmap and maxdisks which breaks access to >9-port controllers. Of course it would be a moot point with SupportPortMappingV2.
-
Mis-mapping of USB drives interacting with the intended HDD pool may be an inadvertent consequence of leaving the SataPortMap value blank. You may have to make a decision between using the 16-port card for all 16 ports (which is working as we intended now) and having USB drives mapped correctly. Alternatively, a device-tree based solution (DS1621+) will probably work for both, but it would be a complicated manual configuration at the moment.
-
Check and make sure that AHCI mode is selected for both SATA drives in the BIOS.
-
Well you could have started with that. But I'm not going to copy it from the image. You'll need to translate or switch your install to English.
-
It's behaving as if maxdisks = 20 Any thoughts? @pocopico @jumkey @IG-88
-
You will need to post more information. What is the SATA error?
-
A couple of questions: Why are you using DS3615xs? See here for preferences: https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ Are you trying to use SATA boot? That is not the right option for a baremetal NUC install. You need a USB key and choose USB boot.
-
@-iliya- Please check grep -i maxdisks /etc/synoinfo.conf grep -i maxdisks /etc.defaults/synoinfo.conf
-
RedPill TinyCore Loader Installation Guide for DSM 7.1 BareMetal
flyride replied to Peter Suh's topic in Tutorials and Guides
I'm not sure what you are asking. Jun "ESXi" option = SATA Redpill and TinyCore (actually "TinyCore RedPill" = TCRP) are the same loader code, just delivered differently. -
RedPill TinyCore Loader Installation Guide for DSM 7.1 BareMetal
flyride replied to Peter Suh's topic in Tutorials and Guides
If you are running baremetal you should use USB. SATA is for VMware although it may be usable on other hypervisors. -
That is odd. Is the Sandisk your loader device or another USB key? Can you run: ls /sys/block sudo lsusb
-
Not sure, but there is a lot of information suggesting MaxDisks >24 is problematic. Also do you need 14 USB ports? Not sure how many Syno actually supports, but I have never seen someone try to use 14 of them at once. Why don't you try MaxDisks=24, internalportcfg = 0xFFFFFF, usbportcfg = 0xF000000 and see if you get a different result
-
Looks like TCRP is using something from @jumkeythat has been updated? @pocopico need forking?
-
Yes this is working exactly as desired. It is telling you 1) you are assigning ports that are more than maxdisks and 2) sataportmap cannot specify >9 disks so it is setting it to the max of 9. Manually edit user_config.json with new maxdisks and delete the "9" from "SataPortMap=689" and I think you will be ok
-
I have 10Gbe LAN and all-SSD array. Four SATA SSD's will max out the 10Gbe link so it makes no sense to use cache in that case. Additionally all DSMs use whatever RAM is free to cache recently used files, so if you have a heavy multi-user workload that all refer to a small dataset, it already is cached. Personally I think it's a bit of a gimmick/product differentiation. Not too much value if you ask me, other than to stress test the cache device.
-
I'm not seeing those errors. Maybe your image is corrupted, consider reburning it. tc@box:~$ ./rploader.sh update now Checking Internet Access -> OK Checking if a newer version exists on the repo -> There is a newer version of the script on the repo should we use that ? [yY/nN]y OK, updating, please re-run after updating Updating tinycore loader with latest updates Backing up files to /mnt/sda3//mydata.tgz Done.
-
internalportcfg, esataportcfg and usbportcfg are all related. Only one can have a particular bit position set to 1 at a time.
-
The dialog between Peter Suh and pocopico was most informative to me. I don't think it's really documented at all. I'm working to improve that now, with this: https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ and enhancements to the satamap tool, soon a specific device tree tool. Once that is online I'm planning to create some better documentation.
-
If possible, you need to exchange the slots on these cards if you want to use all the ports on the 9201. If one of them is embedded, look in BIOS to see if it can be assigned a different PCI slot. Alternatively, you can build using DS1621+ and manually assign each of the slots using DTS/DTB. This will be automated soon, but not yet.
-
Generally you should add a sataportmap entry for each controller. The current TCRP code will recommend this. The only case not to do so is the >9 port card as you have described. This is dependent on a lot of factors, whether you are trying to use SATABOOT etc. Script enhancement should help folks move their configurations to a more predictable space. Testing across the various hypervisors is inconsistent, so there may be some work to do there.
-
Yes. satamap reported controllers with cards >9 ports incorrectly until very recently. If you ./rploader.sh update now and repeat you will get a different result.
-
It must be the last controller listed in lspci (top to bottom).
