Jump to content
XPEnology Community

Benoire

Member
  • Posts

    239
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Benoire

  1. @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

  2. 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.

  3. 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

  4. Thanks for the info! Yeah I knew about the bitrot prevention (something I have personally never seen), but haven't ever heard many hard facts about the deduplication and cloning options, just a lot of either "btrfs is the worst, doesn't do what it says and is slower" or "you are ignorant and irresponsible if you are using a file system other that btrfs."

     

    Is there anything that ties this installation directly to the 3615xs aside from the model number? I haven't tried changing that but wasn't sure if you could swap that out in the grub.cfg and download a pat for a different model. Obviously there are other issues with sn and mac addresses for quickconnect. But it would be awesome to just get a btrfs volume created, then migrate that to the 3615xs that seems to be working great.

     

    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!

  5. Has anyone gotten a rackstation vm image with Jun's loader working with this?

     

    I ask, as the 3615xs does not have the SHR/SHR2 config anymore.

    Only the mid level rackstation has SHR/SHR2 now and that doesn't support SAS either so no drivers for LSI cards.

  6. 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?

  7. 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.

     

    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).

  8. 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.

  9. 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.

  10. 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.

  11. 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.

     

    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 :smile:

  12. 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.

    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.

  13. 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.

  14. That would be great !!!

     

    Just fyi, it's not all the RS versions that are sas compatible, as far as I can find on synology's page, it's only these: RS18016xs+, RC18015xs+ and RS10613xs+, where the RS18016xs+ is the most up-to-date one.

    Is it possible to find these files on the web, or do we need some one with access to a RS18016xs+?

     

    Thanks.

    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!

  15. Hi Jun.

     

    Would it be possible to make a RS18016xs+ Version? This one have SAS Support, and should support the LSI-9211 card.

     

    Is it easy to change this my self?

    I tried changing DS3615xs to RS18016xs+ in the grub.cfg file, but no luck.

     

    Thank you very much for this great boot image.

    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.

  16. 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.

  17. 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.

×
×
  • Create New...