Benoire
-
Posts
239 -
Joined
-
Last visited
-
Days Won
1
Everything posted by Benoire
-
@Jun (using @ doesn't actually work does it?!) Are you able to find the time to patch a rackstation model with the dynamic patch? The RS18016xs+ should be using LSI cards (9211-8is) with the SAS drive numbering remapped to get the actual physical slot sorted. This would give those with SAS HBAs of the LSI range access plus proper drive numbering. I have no idea what you have done with the patch, nor could I find it to see but I reckon the community would greatly appreciate it! Cheers, Chris
-
Not until drivers are compiled and included.
-
No, there is no gui way to upgrade from EXT4 to BTRFS. You can apparently do it via the command line but I've heard it can be a bit dodgy.
-
You can, but I believe the adaptec will do port numbering correctly via mini-sas cables fine and will link port to cable if you have iPASS cables with the SGPIO connection.
-
For the LSI, its just the way they work. Anything based on the broadcom chipsets do this; i.e. anything that can be crossflashed to an LSI card. I know that the Adaptec 1000-8i/16i will do drive enumeration (there is a post discussing LSI cards from me where this is posted by a user, search for threads started by me to confirm) but in the same post the person said that they didn't have SMART monitoring up! You could also run a SATA based controller through the backplane instead of a SAS one and that would work too fine out of the box. FreeNAS also suffers from the same problem with drive numbering if you use LSI cards.
-
I won't be able to confirm the portcfg values but I will try to answer your questions: 1) USing an LSI card, HDDs are not enumerated in order of slot but in order of spinup and detection, if you look at fdisk -l in the console you'll see that your drives are probably not starting with SD(A) as you would expect. This is a function of the LSI cards and is only fixed using a rackmount bootloader that supports SAS cards; presently there isn't one! 2) See above, except that the DS3615xs only supports 12 HDDs connected without the expander. This means on an initial install, it will not be able to detect more than 12 drives, and drives enumared above SDm may not show. 3) Is this after editing the config or just after installing? What people ahve to do normally is install DSM on to say a single disk in slot 1, edit the config files that have been installed to pick up the portcfg values, reset and then slide your drives in to the machine... If you run all drives before install then it gets confused as it has more drives than its programmed for and doesn't know what is happening; once installed and edited it will survive reboots but only until you update... Once you update, you generally have to do the same thing again. Now, for item 3 you might be able to get around it by downloading the correct PAT file first, unpacking the synoinfo.cfg file and editing the values, re-injecting in to the PAT and then use this modified pat to update manually, that should keep your config assuming that there are no checksums done on the PAT file before installation. Hope this helps a wee bit. Chris
-
Oh ok, so we could create a boot loader for a SAS rackmount, edit the config to do the above and that would work?
-
Jun had to mimic certain missing PCI functions within the patcher, or there abouts, that are required for the boot loader to run. As a result, this loader is hard coded for the DS3615xs. To access another model, you have to determine what pci functions are not covered in the loader and edit them in to the module he created; just chaning the grub data doesn't work... I know the module name but I still haven't found the module itself as I wanted to look at enabling a rackstation with LSI drivers! The lack of SHR is something that I would miss, and despite BTRFS containing good work, I'd rather have SHR2 then fork out for 8 4tb drives for example!
-
DSM 6 on the DS3615xs (which this boot loader is based on) does not support hybrid raid aka disk groups. You can only do jbod, or raid groups now.
-
Only the mid level rackstation has SHR/SHR2 now and that doesn't support SAS either so no drivers for LSI cards.
-
Does this way of loading DSM 6 allow for Synology Hybrid Raid creation for new arrays? It appears as if transferring an old array keeps access to it but can you do it with new arrays too?
-
I just tried making a shr-1 volume in the xpenology 5.2, then swapped usb and put my 6.0 stick in. Had to reinstall to the box, but it worked! It kept my shr-1 volume and seems to be working. Right now I am testing expanding the volume by adding another drive (gonna take a while). Then I might try replacing a drive with a larger one to make sure that works. One note, this will only get you ext4. I may try and build a small btrfs volume using my 1513+ and try moving that over. Interesting, at least it carries it over. I presume you still can't create a new one (if you have spare slots and two spare discs).
-
Yeah sorry, what I meant was that as we're now using a untouched synology kernel/PAT that means that we can't have it back unless the kernel is patched again which appears to be opposite to what this loader is trying to achieve. Moving model would allow us to have it back without needing to edit the bootloader. Happy if I'm wrong, as I use SHR as doing 12 bays using all 3tb drive is prohibitive and especially if trying to expand to more than that.
-
You might also have eSATA enabled which might be enumerated before an additional controller, worth checking whether you can disable this in the bios.
-
So it looks like the official DS3615xs no longer supports SHR1/2 at all. Does that mean that the dev team should be looking towards an alternative model that supports SHR? It looks like the models below this: RackStation RS2416+/RS2416RP+ support SHR only now, with the enterprise range (DS3615xs belongs here) only supporting traditional RAID modes. The enterprise range is also the only one with native SAS support using the LSI cards.
-
Once its working with LSI cards, I would happily move across as all my data is backed up to crashplan and photos/music etc. is additionally on Google Drive/OneDrive... I can suffer complete failure and repopulate so while it would be annoying, it wouldn't be devastating now.
-
Can you elaborate a bit on that, what do you mean by "establish the PCI" ? Just that official devices have a predetermined set of pci devices that must be present in order for the system to work. On a generic machine, these do not exist in the same way or with the same IRQ etc. Apparently the PCI devices must be modified by the patcher which means understanding the pci devices required and then altering the loader to make them appear as they would in an official device; once this is done then I think it would load. I don't know which module Jun has created to patch so I can't see what he has done yet, hoping to find out soon
-
So Jun has confirmed that we need to establish the PCI devices in the model we wish to run in order to then modify the patcher to run correctly.
-
After reviewing the RS3617xs vs RS18016 models for SAS and HBA's, I think the RS3617xs model is best suited to go after. It also has mp2tsas and mpt3sas drivers compiled for it out of the box. Not to mention it is their current flagship that won't dissappear for a while. Sent from my SM-N930T using Tapatalk Ah yes, I had forgot that they had released a new model! I'm not sure what Jun has done with the bootloader but has your experience with it so far indicated that it should be ok? The RS PAT files contain all they need so we just need the loader to be able to patch the kernel.
-
The DS series DOES NOT have support for any SAS based HBA. There is specific code in the PAT files for those models that disregards any SAS HBA detected drives; you need to patch that out like team did originally so it detects as SATA and not SAS. I'm going to take a look at the rackstation models that support SAS as I'm hoping that the new bootloader can patch those too, in which case we can have two different bootloaders, one for pure SATA systems and one for SAS based systems.
-
Yup the PAT file does actually contain the BIOS files required, I know that Trantor was playing around with creating a bootloader using the RS18016xs+ (I started looking at the files and it seemed to get Trantor intrigued) but at the time it was based on the DS kernel patches. If Juns bootloader can patch anything and not just the DS series, then it should be a matter of simply extracting the right images from the RS PAT file, re-compacting in to the image for the bootloader and edit grub like you did. In fact, you might be able to use the image trantor created, search either for my name or the RS18016xs+ and it should pull up my thread... he posted an image in there and it contains the modified zimage for the RS; that might work now with this new loader... Not sure if you need to merge it or extract, replace the core bits... I'm not sure!
-
I believe you have to replace the image as the rackmounts have a different image which needs to run. I'm going to have a play later with redoing the bootloader using the image from the RS as if the kernel patch works for the DS series it should also work for the RS with the right files. This will not only give native LSI SAS support but also proper drive numbering using the LSI SAS cards too which you can't do right now due to the way LSI work.
-
Can the loader be used on other units? The rackmount units have LSI cards in then (9211-8is I believe) so if you have a 12 bay unit then you should get proper drive numbering and support if it works.
-
I know that the 16 port PMC Adaptec HBA 1000-16i appears to work with dsm5.2 using the standard bootloader but the person who was using it said it didn't do SMART. Not sure how related that is to the 7 series.
-
My understanding with MDADM was that each array is separate and independent to the others, so converting your raid 6 array to a raid 5 array should leave MD0/1 intact as Raid 1s; these are effectively mirrors on each drive. The question would remain however, what config file is written in DSM to record the array setup, or does it read from the array itself? I.e. changing from raid 6 to raid 5 (same as shrinking an array to remove a drive) be reflected in DSM or would it read from a file for what it has committed and therefore not reflect CLI changes.