krisha

Members
  • Posts

    25
  • Joined

  • Last visited

Posts posted by krisha

  1. Regarding the cache replacement procedure as described here in the FAQ:

     

    I had problems with the mover moving some symbolic links of docker data, due to:

    - wrong permissions. This was solved using 'New permissions' on just the cache drive

    - symbolic links to content in docker. Those were never moved.

     

    I finally used the plugin 'CA Backup / Restore Appdata' to backup and restore the docker data. The procedure mentioned in the FAQ I followed any way (Backup before moving, restore after moving back), but think this is not really necessary.

     

    Maybe it's possible to extend the FAQ post by those 2 hints.

  2. yes a bug tracker would be a nice thing - I found so many ideas and some bugs, but it's hard to follow and you never know if Tom will ever read it. There's a lot of stuff spread on forum. I think there might be also people helping maintaining the system, removing duplicates etc.

     

    It would be also nice to let the community vote about stuff on any feature/bug list. E.g. a driver rework for faster writes :-)

  3. I'm copying some files to my new unraid, in generally this is 200 GB splitted into ~500k files.

    At startup it was copying mostly small files, with a rate of ~30 MB/s (which is slow already but acceptable). After some hours it dropped to less than 8 MB/s. Currently it's transfering files in the size of 500 MB - which do not need much seek.

     

    The harddisk can be written with ~100 MB/s, Ethernet connection (Realtek 811E) is 1 GBit/s. The drive leds of origin (desktop PC) and unRaid blinks in an interval of ~2 seconds.

     

    Why is this?

     

    Also on 'top' I see that 3,9 GB of RAM out of 4 GB is used. CPU is idle at around 80%. Could it be that there is a memory leak? Attached a picture of 'top' sorted by memory :-)

     

     

    top_unraid.png.22dd581f31c6111fc8979345522f98e1.png

  4. On point 1, that functions as designed and is technically not a bug. It's how unRAID has always functioned as far as I can tell. That is why the community created the preclear_disks tool.

     

    Hm ok, so it's kind of protection. But should be changed, maybe replace the endless waiting with an output "Currently clearing disks, estimated finished in xx min. Do NOT power off.". New users might think that the system is stuck and just force a reboot.

  5. I did not choose my words wisely. Your preclear script I used once and like it very much. Will use this from now on for all new disks. In this case (last post) I let unRAID clear the disk.

     

    Offtopic:

     

    What is the best way to report bugs/issues and features?

     

    webGUI not responding during the time of clearing is a bug.

     

    I want to help to improve this product (also bought two Pro licenses some days ago :)).

     

     

  6. As i understood the regular way to replace a (good) drive is to remove it from the controller and let unRAID rebuild it.

     

    But if something happens to the array during this time, what will happen?

     

    Can I just connect the old drive again and it will work? I saw around 8-9 writes to the data drives during a parity sync.

     

    Best way probably is to just clone the drive before. Is this supported? What happens if the drive is larger in size?

     

    I'm currently replacing the parity and I take the risk. But maybe it would be nice feature to implement.

  7. It would have started a parity calculation the first time you started the array after assigning a parity drive.

    Cancelling that initial calculation should NOT show parity as valid, since it is guaranteed to not be correct.

     

    yes initial parity calculation I did and let it finish. It was also not shown any "checked" date after it. This for sure was started automatically after assigning the drives to the array.

  8. I'm new to unRAID - i like the way it is working, but I saw that parity is not checked on read operations.

     

    Maybe it's better to check parity also on read operations? This might prevent the manual 'check parity' process.

     

    I think ReiserFS does not provide any checksums, so how unRAID is able to detect an error in communication or a wrong bit on HDD? (Maybe this is a special case, it's also unsure how to handle such a error then, since the source of the error could be parity or the data drive; double read might get any hint).

     

    On the other hand the parity drive needs to run also on read operations and might slow down transfer.

  9. I think if you power down unRAID during the parity verification process it will be saved as successfully verified.

     

    Parity check for me was at ~10% (of 1.5 TB) and I pressed the power off button. System went down after some seconds (as usual). But next time I started up, I saw "Last checked on ..., parity valid, no errors."

     

    Maybe better to toggle a flag after successfully completing verification? Or also save the current position of the progress every 5% step.