krisha

Members
  • Posts

    25
  • Joined

  • Last visited

Everything 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 :-)
  4. 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. the last times I shutdown by power press there was no parity check after rebooting. Using the power button the PC beeps twice and then after some seconds it is powered off. Can't be that after an parity sync/rebuild the next time it will do a parity check?
  6. I'm running beta14 :-) Where to post features? The annoucement thread has 23 pages, I would recommend something like a bugtracker. PS: Very nice support in the forum. Thanks!
  7. Hope this is the right thread. Two bugs (posted also on seperate threads): 1) On clearing a new disk the webGUI is not available 2) I saw on local screen "run_cmd.... share_size" as login, probably after setting include disks to "disk1 disk2" or after clearing and formatting finished.
  8. I had this issue also twice. webGUI was just showing 'powering of system...'. Log in locally and force a shutdown with "shutdown -h now" Parity check did not occur for me. PS: I have completly different hardware, but I used the physical power button w/o stopping the array first.
  9. 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 ).
  10. I saw a "run_cmd: ... share_size" on the login name. Not sure if it should be there ;-) Just added a new disk, trying that the existing shares will use all new disks I wrote "disk1 disk2 disk3" on the include. probably this was wrong. Actually you need to repower and after the new size is shown correct.
  11. Old topic I know, but beta 14 has same problem. I add a new disk and the GUI hangs till finished (in preclearing step). And I also think it was written, that the array is useable during preclear - I did not try that. so don't know if it is working
  12. just to complete information here: I replaced my parity drive. The next boot after parity sync it automatically started a parity check. And after parity check is complete, the timestamp for the check looks updated.
  13. 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.
  14. Is there a way to read out the vars over the webGUI (http://tower/Utils/Vars) without any HTML header? Best would be XML, but I would be also satisfied with the output there. What can be the content of the variable [status]?
  15. 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.
  16. no, definately not. but during my setup stage I think it started one time automatically. This was aborted with a reboot by me. Now it shows "Last Checked" and did not start again for several boot-ups.
  17. Ok, if it's an optional task then I do not care so much. Also it's not a problem to remember when you started parity check and did a reboot during that. I think the timestamp is saved anyway to flash when you start checking, same if errors are found. I think writting a single byte once in a month will not really decrease life time so much.
  18. Yes, when writing the initial post I had in mind the following articles I somewhen read. Just I did not know (or remember) that the disk will report this error. http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162 http://www.tomshardware.com/news/RAID-5-Doomed-2009,6525.html
  19. ok, thanks for clarification on that. So URE's are only a problem when rebuilding an array ;-) [edit: URE - unrecoverable read error :]
  20. 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.
  21. 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.