Jump to content
XPEnology Community

flyride

Moderator
  • Posts

    2,438
  • Joined

  • Last visited

  • Days Won

    127

Posts posted by flyride

  1. No problem, conservative is good when dealing with arrays.

     

    I think your array is started and should have data.  We absolutely do not want it to rebuild, resync or any other operations.  So don't click on any "fix" buttons in the GUI.

    It also has no redundancy and your drive #0 /dev/sda is presumed to be dead.

     

    I advise to flag the whole array read-only:

    # mdadm --misc -o /dev/md2

    Then reboot and see if your data is there.  Report back on status.

  2. Still quite perplexed about the refusal of this drive to play, but we're probably out of non-invasive options and need to do a create - the path that IG-88 charted out. Before we do that let's get a current state of your system. Please do not reboot or do anything else to change the system state once we start using this information or your data is at risk.  If anything changes at all, please advise.

    # mdadm --detail /dev/md2 | fgrep "/dev/"
    # mdadm --examine /dev/sdb5 /dev/sdc5 /dev/sdd5 | egrep "/dev|Role|Events|UUID"

     

  3. That was going to be my next suggestion.  But, are you sure there was not more output from the last command?  For verbose mode, it sure didn't say very much.  Can you post a mdstat please?

     

    After that, if it still only has assembled with two instead of three drives, let's try:

    # mdadm --stop /dev/md2
    # mdadm -v --assemble --force /dev/md2 --uuid 75762e2e:4629b4db:259f216e:a39c266d

     

  4. I'm also a bit perplexed about /dev/sdc not coming online with the commands we've used.  But I think I know why it isn't joining the array - it has a "feature map" bit set which flags the drive as being in the middle of an array recovery operation.  So it is reluctant to include the drive in the array assembly.

     

    In my opinion zapping off the superblocks is a last resort, only when nothing else will work.  There is a lot of consistency information that is embedded in the superblock (evidence by the --detail command output) and the positional information of the disk within the stripe, and all that is lost when we zero a superblock.

     

    Before we go doing that, let's repeat the last command with verbose mode on and change the syntax a bit:

    mdadm --stop /dev/md2
    mdadm -v --assemble --scan --force --run /dev/md2 /dev/sdb5 /dev/sdc5 /dev/sdd5

    If that doesn't work, we'll come up with something to clear the feature map bit.

  5. Hello, sorry I had to work (I work in health care so very busy lately).

     

    These commands we are trying have not started the array yet, but you are no worse off.  I don't quite understand why the drive hasn't unflagged, but let's try one more combination before telling it to create a new array metadata.

    # mdadm --stop /dev/md2
    # mdadm --assemble --run --force /dev/md2 /dev/sd[bcd]5

     

  6. 26 minutes ago, jbesclapez said:

    I do not get anything from that command. What I am doing wrong?

     

    image.png.f967fe1205a3534244ff31b845a28029.png


    The pound sign I typed was to represent the operating system prompt and so you knew the command was to be run with elevated privilege. When you entered the command with a preceding pound sign, you made it into a comment and exactly nothing was done. 
     

    Please do not click that repair button right now. It won’t be helpful. 

  7. 11 hours ago, jbesclapez said:

    I dont know if it is important but as a reminder,  I did a SMART extended on the "broken" disk- it is now failing.... slowly...

     

    When you say something like this, be very specific as to which disk it is.  Is it disk #1 or disk #3? (please answer)

     

    12 hours ago, jbesclapez said:

    root@DiskStation:~# mdadm --examine /dev/sd[abcd]5 | egrep 'Event|/dev/sd'

    /dev/sdb5: Events : 15405

    /dev/sdc5: Events : 15357

    /dev/sdd5: Events : 15405

     

    This is not too bad, there might be some modest data corruption (IG-88 quantified), but most files would be ok.

     

    Do you know if your filesystem is btrfs or ext4?  (please answer)

     

    And please answer the two questions I asked in the first place.

     

    13 hours ago, flyride said:

    There is an incomplete Warning message that might tell us more about /dev/sda.

     

    13 hours ago, flyride said:

    So first, please investigate and report on the circumstances that caused the failure.

     

  8. Before you do anything else, heed IG-88's advice to understand what happened and hopefully determine that it won't happen again.  From what you have posted, DSM cannot see any data on disk #1 (/dev/sda). There is an incomplete Warning message that might tell us more about /dev/sda.  Also disk #3 (/dev/sdc) MIGHT have data on it but we aren't sure yet.  In order to effect a recovery, one of those two drives has to be functional and contain data.

     

    So first, please investigate and report on the circumstances that caused the failure. Also, consider power-cycling the NAS and/or reset the drive connector on disk #1.  Once /dev/sda is up and running (or you are absolutely certain that it won't come up), complete the last investigation step IG-88 proposed.

      

    17 hours ago, jbesclapez said:

    and this command below does not do anything - or I dont know how to use it:

    # mdadm --examine /dev/sd[bcdefklmnopqr]5 | egrep 'Event|/dev/sd'

     

    You only have four drives.  So adapt the last command as follows:

    # mdadm --examine /dev/sd[abcd]5 | egrep 'Event|/dev/sd'

     

  9. 6.2 has received a few patches for security fixes when 6.1 has not.  However, Synology lags so badly with critical updates versus a normal Linux distro, I personally won't rely on 6.2.2's security state.  My recommendation is that you should assume it's hackable and never expose your NAS to the Internet.  VPN or 2-factor encrypted proxy service are really the only options to safely access it remotely.  If you subscribe to that opinion, the difference between 6.1 and 6.2's security state is really irrelevant.

    • Like 1
  10. 15 hours ago, ruffpl said:

    One more question. Can I " jump" from one platform to another if storage pool with data is already created? F.ex if I create Vm, pass-through all drives, put my data on it, but after some time I would like to try different Ds. Can new VM (with passed-through same list of disks) not going to format the pool?

    Yes, if you do a DSM migration install with the new VM.

     

    15 hours ago, ruffpl said:

    Ps. Will ssd cache work if I pass-through (some cheap) 2x ssd by sata or it have to be some nvme by pci adapter?

    Yes.  They have to be seen as SSD by the DSM instance.  Don't use cheap SSD for write cache or you risk your data.  Better yet, don't use write cache at all.

  11. 1 hour ago, ruffpl said:

    How many disks does DS918 support? Also is it possible to add more than 8 cpu threats in it?

     

    DS918 and DS3615 - 8 threads (4 cores + 4 hyperthreads, or 8 cores if you turn off HT in the BIOS)

     

    DS3617 - 16 threads (8 cores + 8 hyperthreads, or 16 cores if you turn off HT in the BIOS).  But most finicky with regard to hardware compatibility.

     

    You can add as many threads as you want to the VM but DSM won't use more than stated; it's a kernel compile limitation.

×
×
  • Create New...