Videodr0me

Members
  • Posts

    129
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Videodr0me's Achievements

Apprentice

Apprentice (3/14)

27

Reputation

  1. Thanks very much for explaining. I think i understand the issue better now but one question remains. If the uuid is identical how does unraid know which drive to include in the array? Lets say I have the new drive inside the array (the old drive is removed from the server) and everything is already rebuilt: If i now shutdown the server, connect the old drive (now both drives are connected), power on and start the array - how does unraid know which of the two drives to include in the array? Or does it remember the drives not only by uuid but other info as well?
  2. Thanks for the info. I am still unsure exactly when I need to change the UUID. Do i have to do it before i remove the drive, or do i change the UUID before mounting it with unassigned devices for the first time? Is there a reason why i have to change the uuid? I thought that when i set the drive to "not assigned" (step1) and start the array (step 2) unraid will forget that this uuid belongs to the array. Is this assumption wrong?
  3. There are also some other potential bottlenecks/pitfalls: 1) on low cpu powered servers dual parity might be cpu contrained. On my Intel® Atom™ CPU C3538 @ 2.10GHz unraid server going from single to dual more than halved parity speed 2) make sure the cpu scaling governor is set to performance (tipps and tweaks plug-in). This can also make a big difference 3) on systems with a high number of drives the i/o performance of the disk controllers and or number of available pci lanes can make a difference 4) check and optimize the tunables under disk settings - there are a number of threads in the forum give information about this 5) if you use usb drives, make sure that all drives really use > usb 3.0. Because if only one drive falls back to usb 2.0 it completely limits the parity speed.
  4. I have a question regarding the replacment of drives. I want to replace an old smaller drive with a new larger one. As far as i can gather the procedure should be as follows: 1) Stop array and set the old drive to "not assigned" 2) Start array and then shutdown the unraid server 3) replace drive with new larger drive 4) Let unraid rebuilt the data on the new drive 5) unraid automatically expands the rebuilt disk to maximum capacity If this is the correct procedure, will i be able to access the data from the old drive with any xfs capable computer. And more importantly, could i just plug the disk in the unraid server and mount it with unassigned devices to access the data? Or would there be problems because unraid recognizes that the drive was from the array previously?
  5. Same problem here with NFS. The oppo 203 only shows part of a directory (approx 200 entries out of 800). Over SMB everything is fine. NFS had been working on previous unraid versions - but i do not know exactly when it stopped showing all files. I think i found a solution by setting global-share-settings->tunable(enable hard links) to no. The oppo now seems to display all entries again. I will monitor this to see if this is just luck or if its really fixed.
  6. I do not use any of these unofficial builds, nor do i know what they are about and what features they provide that are not included in stock unraid. That being said, i still feel that devs that release them have a point. I think the main issue are these statements by @limetech : "Finally, we want to discourage "unofficial" builds of the bz* files." which are corroborated by the account of the 2019 pm exchange: "concern regarding the 'proliferation of non-stock Unraid kernels, in particular people reporting bugs against non-stock builds.'" Yes technically its true that bug reports based on unofficial builds complicate matters. Also its maybe frustrating that people are reluctant to go the extra mile to go back to stock unraid and try to reproduce the error there. Especially since they might be convinced (correctly or not) it has nothing to do with the unoffial build. Granted from an engineers point of view that might be seen as a nuisance. But from a customer driven business point of view its a self destructive perspective. Obviously these builds fill a need that unraid could not, or else they would not exist and there wouldn't be enough people using them to be a "bug hunting" problem in the first place. They expand unraids capabilities, bring new customers to unraid, demonstrate a lively and active community and basically everything i love about unraid. I think @limetech did not mean it in that way, but i can fully see how people who poured a lot of energy and heart into the unraid ecosystem might perceive it that way. I think if you would have said instead: "Finally we incorporated these new features x,y, and z formerly only available in the builds by A, B and C. Thanks again for your great work A,B and C have being doing for a long while now and for showing us in what way we can enhance unraid for our customers. I took a long time, but now its here. It should also make finding bugs more easy, as many people can now use the official builds." then everybody would have been happy. I think its probably a misunderstanding. I can't really imagine you really wanting to discourage the community from making unraid reach out to more user.
  7. The problem persists on 6.9 beta25. It seems to be related to the docker service. Turning off docker completely in the settings page->docker solved it. This is strange because all containers were already stopped. So maybe its related to the docker service somehow, whether containers are running or not.
  8. Same here. Shutting down docker (in the settings page->docker) fixed it here, too. Strange because all containers were stopped already, so it must be something with the docker service itself.
  9. Same thing here with beta 25. Drive temp of first parity drive is misreported (5588 Degrees). Unfortunately the drive spun down before i could make a screenshot. Smart data was normal.
  10. Just another update after 31 days of uptime with 6.9.0beta22. No pagefaults. I consider this issue fixed (at least in beta22).
  11. Installed 6.9.0 beta 22 and so far so good. No page faults, yet. Will keep you posted.
  12. I wonder if i should go back to 6.8.3 or wait for a new beta. Is there any rough timeframe for when the next beta will be dropped upon us?
  13. As I stated, I did not reboot at all. System is up for 44 days, in this time the page fault occured twice. I find it highly unlikely that the pagefaults have anything to do with these plugins, as others without these plugins report exactly the same page faults. The next time i reboot i might try safe mode for a brief period, but as these pagefaults occur rarely I would not pin to much hope reproducing these faults. Never had any of these with previous versions - not even with the other rc that used a 5.x kernel.
  14. I did not reboot the machine, just to see if more of these page faults show up. And yes it happened again. Will this be fixed in the next beta: May 5 08:46:39 TOWER kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) May 5 08:46:39 TOWER kernel: BUG: unable to handle page fault for address: ffffc900016b3e98 May 5 08:46:39 TOWER kernel: #PF: supervisor instruction fetch in kernel mode May 5 08:46:39 TOWER kernel: #PF: error_code(0x0011) - permissions violation May 5 08:46:39 TOWER kernel: PGD 276c19067 P4D 276c19067 PUD 276c1a067 PMD 276489067 PTE 800000019db60163 May 5 08:46:39 TOWER kernel: Oops: 0011 [#2] SMP NOPTI May 5 08:46:39 TOWER kernel: CPU: 2 PID: 26255 Comm: shfs Tainted: G D 5.5.8-Unraid #1 May 5 08:46:39 TOWER kernel: Hardware name: Insyde AS Series/Type2 - Board Product Name, BIOS V1.37 01/27/2015 May 5 08:46:39 TOWER kernel: RIP: 0010:0xffffc900016b3e98 May 5 08:46:39 TOWER kernel: Code: 00 00 00 30 ca 77 82 88 ff ff d9 b8 07 81 ff ff ff ff 01 96 07 81 ff ff ff ff 98 2a 6a 39 82 88 ff ff 80 0c d6 76 82 88 ff ff <80> 2f ca 77 82 88 ff ff 80 25 6a 39 82 88 ff ff 00 00 00 00 00 00 May 5 08:46:39 TOWER kernel: RSP: 0018:ffffc900098efc08 EFLAGS: 00010282 May 5 08:46:39 TOWER kernel: RAX: ffffc900016b3e98 RBX: ffffc900016b3e98 RCX: 0000000000000000 May 5 08:46:39 TOWER kernel: RDX: 0000000000000000 RSI: ffffc900016b3db0 RDI: ffff888238700c00 May 5 08:46:39 TOWER kernel: RBP: ffff888238700c00 R08: 0000000000000000 R09: ffffc900098efba8 May 5 08:46:39 TOWER kernel: R10: 0000000000000068 R11: ffffc900098efbe0 R12: ffff888236450110 May 5 08:46:39 TOWER kernel: R13: ffff888238700c4c R14: ffff888236450140 R15: ffff888236450120 May 5 08:46:39 TOWER kernel: FS: 000014f6c2c29700(0000) GS:ffff888277d00000(0000) knlGS:0000000000000000 May 5 08:46:39 TOWER kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 5 08:46:39 TOWER kernel: CR2: ffffc900016b3e98 CR3: 000000023d0ec000 CR4: 00000000001006e0 May 5 08:46:39 TOWER kernel: Call Trace: May 5 08:46:39 TOWER kernel: ? fuse_request_end+0x185/0x19a May 5 08:46:39 TOWER kernel: ? fuse_dev_do_write+0xa2e/0xa75 May 5 08:46:39 TOWER kernel: ? step_into+0x5d/0x1b2 May 5 08:46:39 TOWER kernel: ? link_path_walk.part.0+0x225/0x41c May 5 08:46:39 TOWER kernel: ? fuse_dev_write+0x5b/0x75 May 5 08:46:39 TOWER kernel: ? do_iter_readv_writev+0xb3/0xf3 May 5 08:46:39 TOWER kernel: ? do_iter_write+0x7c/0xb8 May 5 08:46:39 TOWER kernel: ? vfs_writev+0x74/0xb4 May 5 08:46:39 TOWER kernel: ? __do_sys_newlstat+0x48/0x6b May 5 08:46:39 TOWER kernel: ? __fget_light+0x3d/0x47 May 5 08:46:39 TOWER kernel: ? do_writev+0x79/0xe7 May 5 08:46:39 TOWER kernel: ? do_syscall_64+0x7a/0x87 May 5 08:46:39 TOWER kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 May 5 08:46:39 TOWER kernel: Modules linked in: md_mod xt_MASQUERADE iptable_filter iptable_nat nf_nat ip_tables it87 hwmon_vid xfs nfsd lockd grace sunrpc tg3 intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_cstate i2c_i801 i2c_core ahci libahci video iosf_mbi fan thermal backlight button [last unloaded: md_mod] May 5 08:46:39 TOWER kernel: CR2: ffffc900016b3e98 May 5 08:46:39 TOWER kernel: ---[ end trace 10a0e1bdc55a4e54 ]--- May 5 08:46:39 TOWER kernel: RIP: 0010:0x5cefea34 May 5 08:46:39 TOWER kernel: Code: Bad RIP value. May 5 08:46:39 TOWER kernel: RSP: 0018:ffffc9000a6a7c08 EFLAGS: 00010202 May 5 08:46:39 TOWER kernel: RAX: 000000005cefea34 RBX: 000000005cefea34 RCX: 0000000000000000 May 5 08:46:39 TOWER kernel: RDX: 0000000000000000 RSI: ffffc9000b857de0 RDI: ffff888238700c00 May 5 08:46:39 TOWER kernel: RBP: ffff888238700c00 R08: 0000000000000000 R09: ffffc9000a6a7ba8 May 5 08:46:39 TOWER kernel: R10: 0000000000000068 R11: ffffc9000a6a7be0 R12: ffff8882387a1b28 May 5 08:46:39 TOWER kernel: R13: ffff8882381713c0 R14: ffff8882387a1b58 R15: ffff8882387a1b38 May 5 08:46:39 TOWER kernel: FS: 000014f6c2c29700(0000) GS:ffff888277d00000(0000) knlGS:0000000000000000 May 5 08:46:39 TOWER kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 5 08:46:39 TOWER kernel: CR2: 000000005cefea0a CR3: 000000023d0ec000 CR4: 00000000001006e0