GerryGER
-
Posts
51 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by GerryGER
-
-
On 3/26/2024 at 10:08 AM, JorgeB said:
And it never happens after a reboot, if the server doesn't go to sleep?
So far, no. Only after sleep it seems. But at the other hand... I never kept the server running... I will keep the server running for today and tomorrow and check what happens.
Edit: Ironically, that just happened. I rebooted the server, deactivated S3 sleep, copied files, worked for a few GB and then stuck at 1.1MB/S again.
Diagnostic attached.
-
23 hours ago, itimpi said:
It might be worth posting new diagnostics taken while this is happening.
So far I couldn't reproduce the mid transfer drop, but attached a log where it got stuck on 1-3MB/s again. Before going to sleep, I copied some files and it worked fine...
23 hours ago, JorgeB said:This is after waking up?
Yes.
-
9 hours ago, JorgeB said:
I suspect more a compatibility issue with the S3 plugin.
I wonder what could cause this? I have been using the S3 plugin for the last 10 years and never experienced something like this.
Just now, again it started out perfectly fine, even topping out at 110MB/s, but then gets stuck at 1,xxMB/s...
-
Hi,
for a few days now, my unRAID had been bugging me:
Sometimes when I write to a share, my write speed gets stuck on 1,1MB/s. At other times the write speed starts out good (40-110MB/s), but then drops. Reading can get slow too, but more like 10-15MB/s. And sometimes it just works!
I tried different PCs and they all suffer the same problem. Writing to a Windows share from PC to PC works fine. Mounting an external SMB share to unRAID and copying files from it to the array, suffers from the same problem.
It doesn't matter what HDD is getting accessed inside unRAID and the SSD Cache has the same problem.
Rebooting unRAID or the PCs/SMB share sometimes helps. No change if I turn all Dockers off.
My network hardware hasn't been touched (PCs <-> GBit Switch <-> a good 10m Cat. 7 cable <-> Router <-> unRAID connected to Router), the only thing that changed with unRAID was a new drive (Toshiba MG09 18TB, pre-cleared and then used as Parity) - a quick parity checked showed 140MB/s+ speed. Router reboot doesn't help. Connection from my PC to the router gives full 1GBit/s to the internet, so these cables are fine. I also switched out the cable from unRAID to the router - that worked for a day, next day (after S3 Sleep) the write speed started out ok and later dropped to 1.1MB/s again... I have a feeling that the NIC gets stuck on 10MBit/s after S3 Sleep, but ethtool gives me advertised link mode as 1000baseT, partner too, NIC is supposedly in "1000MBit/s" Mode.
I have absolutely no idea what the heck is going on...
-
5 minutes ago, JorgeB said:
Nothing unless you move the data yourself.
So that means I could just keep it there and start the Parity Rebuild?
-
3 minutes ago, JorgeB said:
You can try, but if there are a lot it might be easier to restore from a backup, if one exists.
Only for a few of those (very personal stuff), but most is just Entertainment like movies etc., who don't get an extra backup.
So: Move stuff out of lost+found and then do a parity rebuild? What happens with the lost+found folder during/after the rebuild?
-
3 minutes ago, JorgeB said:
Start the array, it should mount now, then look for a lost+found folder.
Yeah that's there and filled with 3000 folders and files without a file ending. Should I move these files and folders and try to puzzle everything back together or...? No to mention that Parity is still not rebuild, since I started the rebuild and stopped it.
-
Updated last post, how should I proceed? Contend on the disk is currently only emulated.
-
10 minutes ago, JorgeB said:
That won't work, please see check filesystem and use the GUI.
"Phase 1 - find and verify superblock... bad primary superblock - bad sector size !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now."
Ah I'm dumb, had -n on...
after removing -n and going with only -v:
Phase 1 - find and verify superblock... bad primary superblock - bad sector size !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock - block cache size set to 1420144 entries Phase 2 - using internal log - zero log... zero_log: head block 493884 tail block 493884 - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x43d440, xfs_agf block 0x1/0x200 agf has bad CRC for ag 0 Metadata CRC error detected at 0x468740, xfs_agi block 0x2/0x200 agi has bad CRC for ag 0 bad magic # 0x0 for agf 0 bad version # 0 for agf 0 bad length 0 for agf 0, should be 268435455 bad uuid 00000000-0000-0000-0000-000000000000 for agf 0 bad magic # 0x0 for agi 0 bad version # 0 for agi 0 bad length # 0 for agi 0, should be 268435455 bad uuid 00000000-0000-0000-0000-000000000000 for agi 0 reset bad agf for ag 0 reset bad agi for ag 0 bad levels 0 for btbno root, agno 0 bad agbno 0 for btbno root, agno 0 bad levels 0 for btbcnt root, agno 0 bad agbno 0 for btbcnt root, agno 0 bad levels 0 for refcountbt root, agno 0 bad agbno 0 for refcntbt root, agno 0 bad levels 0 for inobt root, agno 0 bad agbno 0 for inobt root, agno 0 bad levels 0 for finobt root, agno 0 bad agbno 0 for finobt root, agno 0 agi unlinked bucket 0 is 0 in ag 0 (inode=0) agi unlinked bucket 1 is 0 in ag 0 (inode=0) agi unlinked bucket 2 is 0 in ag 0 (inode=0) agi unlinked bucket 3 is 0 in ag 0 (inode=0) agi unlinked bucket 4 is 0 in ag 0 (inode=0) agi unlinked bucket 5 is 0 in ag 0 (inode=0) agi unlinked bucket 6 is 0 in ag 0 (inode=0) agi unlinked bucket 7 is 0 in ag 0 (inode=0) agi unlinked bucket 8 is 0 in ag 0 (inode=0) agi unlinked bucket 9 is 0 in ag 0 (inode=0) agi unlinked bucket 10 is 0 in ag 0 (inode=0) agi unlinked bucket 11 is 0 in ag 0 (inode=0) agi unlinked bucket 12 is 0 in ag 0 (inode=0) agi unlinked bucket 13 is 0 in ag 0 (inode=0) agi unlinked bucket 14 is 0 in ag 0 (inode=0) agi unlinked bucket 15 is 0 in ag 0 (inode=0) agi unlinked bucket 16 is 0 in ag 0 (inode=0) agi unlinked bucket 17 is 0 in ag 0 (inode=0) agi unlinked bucket 18 is 0 in ag 0 (inode=0) agi unlinked bucket 19 is 0 in ag 0 (inode=0) agi unlinked bucket 20 is 0 in ag 0 (inode=0) agi unlinked bucket 21 is 0 in ag 0 (inode=0) agi unlinked bucket 22 is 0 in ag 0 (inode=0) agi unlinked bucket 23 is 0 in ag 0 (inode=0) agi unlinked bucket 24 is 0 in ag 0 (inode=0) agi unlinked bucket 25 is 0 in ag 0 (inode=0) agi unlinked bucket 26 is 0 in ag 0 (inode=0) agi unlinked bucket 27 is 0 in ag 0 (inode=0) agi unlinked bucket 28 is 0 in ag 0 (inode=0) agi unlinked bucket 29 is 0 in ag 0 (inode=0) agi unlinked bucket 30 is 0 in ag 0 (inode=0) agi unlinked bucket 31 is 0 in ag 0 (inode=0) agi unlinked bucket 32 is 0 in ag 0 (inode=0) agi unlinked bucket 33 is 0 in ag 0 (inode=0) agi unlinked bucket 34 is 0 in ag 0 (inode=0) agi unlinked bucket 35 is 0 in ag 0 (inode=0) agi unlinked bucket 36 is 0 in ag 0 (inode=0) agi unlinked bucket 37 is 0 in ag 0 (inode=0) agi unlinked bucket 38 is 0 in ag 0 (inode=0) agi unlinked bucket 39 is 0 in ag 0 (inode=0) agi unlinked bucket 40 is 0 in ag 0 (inode=0) agi unlinked bucket 41 is 0 in ag 0 (inode=0) agi unlinked bucket 42 is 0 in ag 0 (inode=0) agi unlinked bucket 43 is 0 in ag 0 (inode=0) agi unlinked bucket 44 is 0 in ag 0 (inode=0) agi unlinked bucket 45 is 0 in ag 0 (inode=0) agi unlinked bucket 46 is 0 in ag 0 (inode=0) agi unlinked bucket 47 is 0 in ag 0 (inode=0) agi unlinked bucket 48 is 0 in ag 0 (inode=0) agi unlinked bucket 49 is 0 in ag 0 (inode=0) agi unlinked bucket 50 is 0 in ag 0 (inode=0) agi unlinked bucket 51 is 0 in ag 0 (inode=0) agi unlinked bucket 52 is 0 in ag 0 (inode=0) agi unlinked bucket 53 is 0 in ag 0 (inode=0) agi unlinked bucket 54 is 0 in ag 0 (inode=0) agi unlinked bucket 55 is 0 in ag 0 (inode=0) agi unlinked bucket 56 is 0 in ag 0 (inode=0) agi unlinked bucket 57 is 0 in ag 0 (inode=0) agi unlinked bucket 58 is 0 in ag 0 (inode=0) agi unlinked bucket 59 is 0 in ag 0 (inode=0) agi unlinked bucket 60 is 0 in ag 0 (inode=0) agi unlinked bucket 61 is 0 in ag 0 (inode=0) agi unlinked bucket 62 is 0 in ag 0 (inode=0) agi unlinked bucket 63 is 0 in ag 0 (inode=0) sb_icount 146880, counted 212288 sb_ifree 1301, counted 727 sb_fdblocks 1475402857, counted 1098436740 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims in-use inode 131 is free, correcting imap imap claims in-use inode 132 is free, correcting imap imap claims in-use inode 133 is free, correcting imap imap claims in-use inode 134 is free, correcting imap imap claims in-use inode 135 is free, correcting imap imap claims in-use inode 136 is free, correcting imap imap claims in-use inode 139 is free, correcting imap imap claims in-use inode 140 is free, correcting imap imap claims in-use inode 141 is free, correcting imap imap claims in-use inode 142 is free, correcting imap imap claims in-use inode 143 is free, correcting imap imap claims in-use inode 144 is free, correcting imap imap claims in-use inode 145 is free, correcting imap imap claims in-use inode 146 is free, correcting imap imap claims in-use inode 147 is free, correcting imap imap claims in-use inode 148 is free, correcting imap imap claims in-use inode 149 is free, correcting imap imap claims in-use inode 150 is free, correcting imap imap claims in-use inode 151 is free, correcting imap imap claims in-use inode 152 is free, correcting imap imap claims in-use inode 153 is free, correcting imap imap claims in-use inode 154 is free, correcting imap imap claims in-use inode 155 is free, correcting imap imap claims in-use inode 156 is free, correcting imap imap claims in-use inode 157 is free, correcting imap imap claims in-use inode 158 is free, correcting imap imap claims in-use inode 159 is free, correcting imap imap claims in-use inode 160 is free, correcting imap imap claims in-use inode 161 is free, correcting imap imap claims in-use inode 162 is free, correcting imap imap claims in-use inode 163 is free, correcting imap imap claims in-use inode 164 is free, correcting imap imap claims in-use inode 165 is free, correcting imap imap claims in-use inode 166 is free, correcting imap imap claims in-use inode 167 is free, correcting imap imap claims in-use inode 168 is free, correcting imap imap claims in-use inode 169 is free, correcting imap imap claims in-use inode 170 is free, correcting imap imap claims in-use inode 171 is free, correcting imap imap claims in-use inode 172 is free, correcting imap imap claims in-use inode 173 is free, correcting imap imap claims in-use inode 174 is free, correcting imap imap claims in-use inode 175 is free, correcting imap imap claims in-use inode 176 is free, correcting imap imap claims in-use inode 177 is free, correcting imap imap claims in-use inode 178 is free, correcting imap imap claims in-use inode 179 is free, correcting imap imap claims in-use inode 180 is free, correcting imap imap claims in-use inode 181 is free, correcting imap imap claims in-use inode 182 is free, correcting imap imap claims in-use inode 183 is free, correcting imap imap claims in-use inode 184 is free, correcting imap imap claims in-use inode 185 is free, correcting imap imap claims in-use inode 186 is free, correcting imap imap claims in-use inode 187 is free, correcting imap imap claims in-use inode 188 is free, correcting imap imap claims in-use inode 189 is free, correcting imap imap claims in-use inode 190 is free, correcting imap imap claims in-use inode 191 is free, correcting imap - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 entry "Anime" in shortform directory 128 references non-existent inode 1097794569 junking entry "Anime" in directory inode 128 entry "Serien" in shortform directory 128 references non-existent inode 1654179027 junking entry "Serien" in directory inode 128 - agno = 3 entry "[SNIP PRIVATE ;)]" at block 0 offset 3320 in directory inode 131 references non-existent inode 470699848 clearing inode number in entry at offset 3320... entry "[SNIP PRIVATE ;)]" at block 1 offset 4008 in directory inode 131 references non-existent inode 470699851 clearing inode number in entry at offset 4008... entry "[SNIP PRIVATE ;)]" at block 2 offset 3520 in directory inode 131 references non-existent inode 1654179040 clearing inode number in entry at offset 3520... [a bit more of this] bad hash table for directory inode 4394447249 (no data entry): rebuilding rebuilding directory inode 4394447249 bad hash table for directory inode 4394448335 (no data entry): rebuilding rebuilding directory inode 4394448335 entry ".." in directory inode 4402441515 points to non-existent inode 947597284, marking entry to be junked bad hash table for directory inode 4402441515 (no data entry): rebuilding rebuilding directory inode 4402441515 entry ".." in directory inode 4402453480 points to non-existent inode 947620170, marking entry to be junked bad hash table for directory inode 4402453480 (no data entry): rebuilding rebuilding directory inode 4402453480 bad hash table for directory inode 4402459807 (no data entry): rebuilding rebuilding directory inode 4402459807 entry ".." in directory inode 4402462710 points to non-existent inode 947627638, marking entry to be junked bad hash table for directory inode 4402462710 (no data entry): rebuilding rebuilding directory inode 4402462710 entry ".." in directory inode 4402473729 points to non-existent inode 947633416, marking entry to be junked bad hash table for directory inode 4402473729 (no data entry): rebuilding rebuilding directory inode 4402473729 entry ".." in directory inode 4461736554 points to non-existent inode 1654179027, marking entry to be junked bad hash table for directory inode 4461736554 (no data entry): rebuilding rebuilding directory inode 4461736554 entry ".." in directory inode 4464777177 points to non-existent inode 2132507164, marking entry to be junked bad hash table for directory inode 4464777177 (no data entry): rebuilding rebuilding directory inode 4464777177 [more of this] bad hash table for directory inode 25774422906 (no data entry): rebuilding rebuilding directory inode 25774422906 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 159, moving to lost+found disconnected inode 160, moving to lost+found disconnected inode 161, moving to lost+found disconnected dir inode 2533438893, moving to lost+found disconnected dir inode 2533438895, moving to lost+found disconnected dir inode 2636384149, moving to lost+found disconnected dir inode 2638402822, moving to lost+found disconnected dir inode 2638402854, moving to lost+found disconnected dir inode 2638606000, moving to lost+found disconnected inode 2638606162, moving to lost+found disconnected inode 2638606163, moving to lost+found disconnected inode 2638606164, moving to lost+found disconnected inode 2638606165, moving to lost+found disconnected inode 2638606166, moving to lost+found disconnected inode 2638606167, moving to lost+found [...] Phase 7 - verify and correct link counts... resetting inode 128 nlinks from 15 to 13 resetting inode 131 nlinks from 145 to 141 resetting inode 137 nlinks from 2 to 1323 resetting inode 4368292562 nlinks from 42 to 38 resetting inode 8594108591 nlinks from 31 to 29 resetting inode 8729374599 nlinks from 7 to 6 resetting inode 8873887464 nlinks from 21 to 20 resetting inode 6725417451 nlinks from 28 to 26 resetting inode 11132024064 nlinks from 13 to 12 resetting inode 6727076067 nlinks from 16 to 15 resetting inode 8896771389 nlinks from 44 to 40 resetting inode 4394423285 nlinks from 18 to 17 resetting inode 8574919624 nlinks from 17 to 13 resetting inode 25784296244 nlinks from 5 to 4 Note - stripe unit (0) and width (0) were copied from a backup superblock. Please reset with mount -o sunit=,swidth= if necessary XFS_REPAIR Summary Wed Jun 7 12:07:23 2023 Phase Start End Duration Phase 1: 06/07 12:06:24 06/07 12:06:24 Phase 2: 06/07 12:06:24 06/07 12:06:25 1 second Phase 3: 06/07 12:06:25 06/07 12:06:47 22 seconds Phase 4: 06/07 12:06:47 06/07 12:06:47 Phase 5: 06/07 12:06:47 06/07 12:06:48 1 second Phase 6: 06/07 12:06:48 06/07 12:07:07 19 seconds Phase 7: 06/07 12:07:07 06/07 12:07:07 Total run time: 43 seconds done -
1 minute ago, JorgeB said:
What was the command you've used with xfs_repair?
It was xfs_repair -v /dev/sdc
-
Hi,
yesterday my Disk 2 went "Unmountable: Wrong or no file system", so I tried "xfs_repair", but that went on for 6+ hours and I stopped it, since there was no indication on how long it would continue to take (endless spam of "...." and it initially started with an error about the superblock being damaged/not found). A friend of mine recommended me to just do a parity rebuild and be done with it. So I stopped the array, took Disk2 out, started the array, stopped it, re-added Disk 2 and started the Parity rebuild, 20 seconds later, the "Unmountable" option popped up again.
How should I proceed? I didn't dare to format it, since there is the warning about "update Parity to reflect this", which sounded like the data can't be recovered by parity rebuild anymore...
-
Using the Add-on "Cookie Quick Manager" and deleting the Cookies for my unRAIDs IP actually worked. Dunno why FFs onboard cookie deleting didn't work.
-
Yeah, I later figured out that this had to be a problem with Firefox, since I could still access the WebGUI with Brave from my Smartphone. On my PC Chrome also works. Deleting the Cookies for "192.168.178.89" (my unRAID IP) doesn't help though.
-
Hey,
I just clicked on the "Mover" via WebGUI as always (to move stuff from the SSD to the array). Normally the Mover then gets grayed out and does its thing, but this time nothing happened, so I F5ed/refreshed and was greeted by "400 bad Request Header Or Cookie Too Large nginx". Reboot didn't do anything, I still have SSH access though.
I have no idea what I could do or what happened... -
Got a question regarding the Clear Array Disk Script:
Is it normal that it only does 1,5MB/s - 3MB/s in the beginning? Will it get faster?
If it's fucked, can I just abort it? Because with that speed it will take like 2 weeks to get done.
-
Hi,
I wanted to do some changes to my unRAID and for that I need to remove 3 drives first. Because of that, I wanted to use the Clear driven, then remove Method. But now after clearing the drive (via unBalance and by hand), I have 33,6MB left on my first test drive. Do I need to get rid of the remaining 33,6MB or is that just some internal config stuff? The Disk itself says "0 files / folders left" via the WebGUI and when accessing the Disk via SMB, it's just empty.
-
Replaced and Synced, how should I proceed?
-
So I did the reiserfsck --fix-fixable, was then instructed to use the --rebuild-tree option. Well, I looked at the Web GUI today (left it to run overnight) now aaand "device is disabled, contends emulated". But the rebuild is still doing its thing, currently rebuilding some data after the full scan. Did the drive really fail and is doing it all on the fly from the parity drive?
Please, how bad is it Doctor?
Thanks for the great Xmas present I guess.
-
Hi,
I guess I got an unwanted Christmas present regarding my server. This problem shows like this:
Share is either set to Private, Secure or even Public.
I try to add new files -> You don't have the permission.
I try to delete files -> Delete window pops up "windows deletes the file"... it's still there. Or even funnier, it gets deleted, disappears from the folder... and reappears a second later. But not all shares have the problem, others work perfectly fine.
So I checked the Log and was spammed with
Dec 25 07:28:58 Tower kernel: REISERFS error (device md1): vs-5150 search_by_key: invalid format found in block 376233083. Fsck?
Dec 25 07:28:58 Tower kernel: REISERFS error (device md1): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [290096 331613 0x0 SD]
over several thousand lines.
When I tried to read/delete/add a file these popped up:
Dec 25 07:27:58 Tower shfs/user: err: shfs_readdir: fstatat: FileNameX (13) Permission denied
Dec 25 07:27:58 Tower shfs/user: err: shfs_readdir: readdir_r: /mnt/disk1/X/Y (13) Permission denied
Dec 25 08:56:06 Tower shfs/user: err: shfs_mkdir: mkdir: /mnt/disk1/X/Neuer Ordner (30) Read-only file system
Oh well...
-
Hi,
I got my unRAID some new HW (proper Server MB, ECC RAM, a Xeon 1220 v3 and a old but nice rombus server case
) so I have been wondering if there is anything I should take care of before moving all the HW.Already made a backup of my USB Drive and wrote down the order of my HDDs, anything I forgot or should take care of?
-
Great to see the 6.2 Stable Release, had been following the Beta/RC development quite a bit but didn't dare to update.
Did the update via Web GUI yesterday and it worked flawlessly as far I can tell. Even Auto Sleep works for me again.
BUUUT: Is there a more detailed writeup on Turbo Write available than the short text block from the blog (and wiki)? A friend and I are slightly confused on how exactly it's done / works. Why does it spin up all the disks? Does unRAID do striping now? Or does it just distribute files in a different way over the HDDs (ignoring settings like high water/fill up etc.)? How exactly does the new writing algo work?
Would be nice to read a bit more about it.
-
Hi,
as the subject says, I was doing a pre-clear and suddenly the server didn't respond anymore - Web GUI unreachable/timed out and Host not reachable with Ping. Funny thing is, it's still running (at least the fans are still going). Can't wake it with my regular WoL or connect with Telnet.
How should I proceed from here?
Edit: unRAID 6.1.9, only official plug-ins (the Bergware stuff).
-
thanks for posting... what is the 'top process?'
http://linux.about.com/od/commands/l/blcmdl1_top.htm
This is how it looks (on a RPi though):
htop is a more fancy version (doesn't come with standard Linux though):
-
I still think its likely a problem on the Windows side. Unmap all mapped drives and then do
net use * /delete
from a Windows command prompt.
Then try accessing the folders with the UNC path like \\tower\sharename instead of mapping a drive.
Ok weird, that didn't help. BUT, while doing that I saw the "Login with different login information" (or however it's translated in English), I ticked the option, inserted my login name/pw and got the error that something else was already accessing the share with the same login. After 3 more times it stopped rejecting me and finally worked.
After a few quick tests it looks like everything works as it should. Don't know if Win 8.1 saved some wrong login info (even though I looked into the credential manager) or what ever else.
I don't even.... gaaaaah. Thanks for the help.
) so I have been wondering if there is anything I should take care of before moving all the HW.
Low write and read speeds to/from unRAID (after sleep?)
in General Support
Posted
Meh, I actually wanted to say "Latest unRaid update fixed this", but the problem just occurred again, after working for the last few days...
Diagnostics is right after it happened again, first the files were written to unRaid with like 50-60MB/s and after a few GB written dropped to 1,3MB/s.
tower-diagnostics-20240404-1559.zip