zOnk.oNe

Hello. Yes...I am using NFS. My recent (and past) searches on Koki forums are saying that NFS is faster than SMB. I checked Plex nerds posts too and they seem to say the same. If I do make that switch, I'll have to remap all shares to both Kodi and Plex. Maybe it's not unraid...? Maybe my router is player hating (Asus RT-N66R with current firmware)?

Hello, I did a search about this and found some advice about spinup groups, but that hasn't helped my situation. I'm still getting these pause+buffering issues when playing files from my UnRaid server. Since it just happened, I jumped up from watching a movie to grab a diagnostic.zip. My setup is super simple...no VM's, no dockers, no scripts....just a straight up file server. This occurs whether I stream to my main client (Kodi) or the rare occasion I use Plex (no transcoding). Files are all .mkv container. Unraid version 6.8.3 Board: X9SCM-F CPU: Intel Xeon E3-1220V2 RAM: 8Gigs Diagnostics attached. Hopefully I provided all the info needed to help a brother out. Thanks in advance, zOnk tower-diagnostics-20201022-2054.zip

JorgeB, You are radical. Many thanks for the reply and well explained/laid out directions. I followed your guidance and all looks good so far. I'm at 47% on the data rebuild. I didn't want to reply too early, all excited, and then find errors/etc. Hopefully things continue smoothly, without error. Again...muchos gracias. -zOnk.oNe

Here's the summary: I was getting a lot of CDC UDMA errors so I ordered a new SAS cable (card: LSI Logic SAS 9207-8i). One drive (disk2) was disabled due to write errors, so I disable/reenabled to rebuild drive contents. During that operation, UnRaid froze...I couldn't change from dashboard to main, for example. Hard restarted. Before the new cable arrived, I fired up UnRaid and now couldn't boot into UnRaid...just an error msg about the SAS card and then a black screen with a blinking cursor. Ordered a new card (SAS9211-8I) figuring the other card was dead and that a new card was the easiest fix. New card, new cables, launch into UnRaid...all drives show up, but now my one drive that was emulated (disk2) is still there, but another drive (disk5) shows as unassigned. If I hover over the red X on disk5 I see "device is missing (disabled), contents emulated". Disk5 can be assigned (it shows up and is available), but I'm not sure if that's what I'm supposed to do. Not sure what to do. From my limited knowledge...2 disks down is not good. Unfortunately for me, I rebooted and THEN remembered never reboot without saving logs. I'll attach what the current log shows. Unraid version 6.8.3 No dockers, VM's. 10 disks, plus parity. Thanks in advance for help/reading. tower-diagnostics-20201011-1323.zip

so... I'll go with: 'rsync -avPX --info=progress2 /mnt/disk10/ /mnt/disk11/' tomorrow once my next disk is ready. Gracias Well...that did work.

I'm in the middle of copying contents and saw this post. Where exactly do I add the '--info=progress2' to the 'rsync -avPX /mnt/disk10/ /mnt/disk11/' command? I'd rather ask than guess. Thanks in advance :)

Muchos gracias. Glad I went fishing yesterday instead of starting...gave time for you to post that and me to properly plan with Rsync.

Got it. Just heard about unBalance...I'll start moving contents and ditch the old filesystem. I also ordered a LSI Logic SAS 9207-8i Storage Controller LSI00301 to replace these two SATA cards that I currently have. The cards I've had work...but I've had many issues with them. **I created a new account to start this thread, not realizing I had an old one. I wanted to mark the thread SOLVED, but can't log in to that newer account. **

Upgrade complete. Loving the new interface so far. Can't believe it took me this crazy event to convince me to upgrade. That unformatted disk is now XFS and 100% empty. Do I leave all the other disks as ReiserFS? Again, thanks to all the folks that posted to educate a brother. Much appreciated.

Understood. I just haven't found anything 'missing' yet. I've got thousands of movies, series, music vids...so, I guess, I just haven't found what's missing. I'm sure I will as time passes and normal usage begins again. So...how do I add Disk10 as a new drive back to the array?

What sucks is that I can't just copy the files off that disk. It's inaccessible (I'm sure that's known by you guys), but I don't seem to be missing any files when I fire up UnRaid. If this is a dead end, what is possible? Is starting the disk as a new disk (lose all data on it) an option? I'm currently running DirLister to make a txt file of all the files on the user share that Disk10 (the bad one) is part of. Then, at least, if I lose all the data on disk10, I have a list to check. Again, thanks in advance for taking the time to help me out.

My bad. I never noticed those (sdX) labels. Tower login: root Linux 3.9.11p-unRAID. root@Tower:~# fdisk -l /dev/sdk Disk /dev/sdk: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdk1 2 62016336 1953514552 83 Linux Partition 1 does not end on cylinder boundary. root@Tower:~# fdisk -l /dev/sdg WARNING: GPT (GUID Partition Table) detected on '/dev/sdg'! The util fdisk doesn 't support GPT. Use GNU Parted. Disk /dev/sdg: 5001.0 GB, 5000981078016 bytes 256 heads, 63 sectors/track, 605626 cylinders Units = cylinders of 16128 * 512 = 8257536 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdg1 1 266306 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. root@Tower:~# fdisk -l /dev/sdi WARNING: GPT (GUID Partition Table) detected on '/dev/sdi'! The util fdisk doesn 't support GPT. Use GNU Parted. Disk /dev/sdi: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdi1 2 62016336 1953514552+ 83 Linux Partition 1 does not end on cylinder boundary. root@Tower:~# fdisk -l /dev/sda WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn 't support GPT. Use GNU Parted. Disk /dev/sda: 4000.8 GB, 4000787030016 bytes 256 heads, 63 sectors/track, 484501 cylinders Units = cylinders of 16128 * 512 = 8257536 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 266306 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. root@Tower:~# fdisk -l /dev/sdd Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes 1 heads, 63 sectors/track, 46512336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdd1 2 46512336 1465138552+ 83 Linux Partition 1 does not end on cylinder boundary. root@Tower:~#

Here's the output (figured out 'sd' needed to be 'md'): Tower login: root Linux 3.9.11p-unRAID. root@Tower:~# fdisk -l /dev/sd10 root@Tower:~# fdisk -l /dev/sd1 root@Tower:~# fdisk -l /dev/sd2 root@Tower:~# fdisk -l /dev/md10 Disk /dev/md10: 2000.4 GB, 2000398901248 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md10 doesn't contain a valid partition table root@Tower:~# fdisk -l /dev/md1 Disk /dev/md1: 2000.4 GB, 2000398901248 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md1 doesn't contain a valid partition table root@Tower:~# fdisk -l /dev/md2 Disk /dev/md2: 4000.8 GB, 4000786976768 bytes 255 heads, 63 sectors/track, 486401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md2 doesn't contain a valid partition table root@Tower:~# fdisk -l /dev/md3 Disk /dev/md3: 1500.3 GB, 1500301877248 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md3 doesn't contain a valid partition table root@Tower:~# fdisk -l /dev/md4 Disk /dev/md4: 1500.3 GB, 1500301877248 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md4 doesn't contain a valid partition table root@Tower:~# fdisk -l /dev/md5 Disk /dev/md5: 2000.4 GB, 2000398901248 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/md5 doesn't contain a valid partition table root@Tower:~#

Ok. ran the --rebuild-tree. Here's the result: Tower login: root Linux 3.9.11p-unRAID. root@Tower:~# reiserfsck --rebuild-tree /dev/md10 reiserfsck 3.6.24 ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ************************************************************* Will rebuild the filesystem (/dev/md10) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Fixed. ########### reiserfsck --rebuild-tree started at Thu Sep 5 17:59:49 2019 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 456426578 blocks marked used init_source_bitmap: Bitmap 2009 (of 32768 bits) is wrong - mark all blocks [6583 0912 - 65863680] as used init_source_bitmap: Bitmap 2010 (of 32768 bits) is wrong - mark all blocks [6586 3680 - 65896448] as used init_source_bitmap: Bitmap 2011 (of 32768 bits) is wrong - mark all blocks [6589 6448 - 65929216] as used init_source_bitmap: Bitmap 2012 (of 32768 bits) is wrong - mark all blocks [6592 9216 - 65961984] as used init_source_bitmap: Bitmap 2013 (of 32768 bits) is wrong - mark all blocks [6596 1984 - 65994752] as used init_source_bitmap: Bitmap 2014 (of 32768 bits) is wrong - mark all blocks [6599 4752 - 66027520] as used init_source_bitmap: Bitmap 2015 (of 32768 bits) is wrong - mark all blocks [6602 7520 - 66060288] as used init_source_bitmap: Bitmap 2016 (of 32768 bits) is wrong - mark all blocks [6606 0288 - 66093056] as used init_source_bitmap: Bitmap 2017 (of 32768 bits) is wrong - mark all blocks [6609 3056 - 66125824] as used init_source_bitmap: Bitmap 2018 (of 32768 bits) is wrong - mark all blocks [6612 5824 - 66158592] as used init_source_bitmap: Bitmap 2019 (of 32768 bits) is wrong - mark all blocks [6615 8592 - 66191360] as used init_source_bitmap: Bitmap 2020 (of 32768 bits) is wrong - mark all blocks [6619 1360 - 66224128] as used init_source_bitmap: Bitmap 2021 (of 32768 bits) is wrong - mark all blocks [6622 4128 - 66256896] as used init_source_bitmap: Bitmap 2022 (of 32768 bits) is wrong - mark all blocks [6625 6896 - 66289664] as used init_source_bitmap: Bitmap 4736 (of 32768 bits) is wrong - mark all blocks [1551 89248 - 155222016] as used init_source_bitmap: Bitmap 4737 (of 32768 bits) is wrong - mark all blocks [1552 22016 - 155254784] as used init_source_bitmap: Bitmap 4738 (of 32768 bits) is wrong - mark all blocks [1552 54784 - 155287552] as used init_source_bitmap: Bitmap 4739 (of 32768 bits) is wrong - mark all blocks [1552 87552 - 155320320] as used init_source_bitmap: Bitmap 4740 (of 32768 bits) is wrong - mark all blocks [1553 20320 - 155353088] as used init_source_bitmap: Bitmap 4741 (of 32768 bits) is wrong - mark all blocks [1553 53088 - 155385856] as used init_source_bitmap: Bitmap 4742 (of 32768 bits) is wrong - mark all blocks [1553 85856 - 155418624] as used init_source_bitmap: Bitmap 4743 (of 32768 bits) is wrong - mark all blocks [1554 18624 - 155451392] as used init_source_bitmap: Bitmap 4744 (of 32768 bits) is wrong - mark all blocks [1554 51392 - 155484160] as used init_source_bitmap: Bitmap 4745 (of 32768 bits) is wrong - mark all blocks [1554 84160 - 155516928] as used init_source_bitmap: Bitmap 4746 (of 32768 bits) is wrong - mark all blocks [1555 16928 - 155549696] as used init_source_bitmap: Bitmap 4747 (of 32768 bits) is wrong - mark all blocks [1555 49696 - 155582464] as used init_source_bitmap: Bitmap 4748 (of 32768 bits) is wrong - mark all blocks [1555 82464 - 155615232] as used init_source_bitmap: Bitmap 4749 (of 32768 bits) is wrong - mark all blocks [1556 15232 - 155648000] as used init_source_bitmap: Bitmap 4750 (of 32768 bits) is wrong - mark all blocks [1556 48000 - 155680768] as used init_source_bitmap: Bitmap 4751 (of 32768 bits) is wrong - mark all blocks [1556 80768 - 155713536] as used init_source_bitmap: Bitmap 4752 (of 32768 bits) is wrong - mark all blocks [1557 13536 - 155746304] as used init_source_bitmap: Bitmap 4753 (of 32768 bits) is wrong - mark all blocks [1557 46304 - 155779072] as used init_source_bitmap: Bitmap 4824 (of 32768 bits) is wrong - mark all blocks [1580 72832 - 158105600] as used init_source_bitmap: Bitmap 4825 (of 32768 bits) is wrong - mark all blocks [1581 05600 - 158138368] as used init_source_bitmap: Bitmap 4826 (of 32768 bits) is wrong - mark all blocks [1581 38368 - 158171136] as used init_source_bitmap: Bitmap 4827 (of 32768 bits) is wrong - mark all blocks [1581 71136 - 158203904] as used init_source_bitmap: Bitmap 4828 (of 32768 bits) is wrong - mark all blocks [1582 03904 - 158236672] as used init_source_bitmap: Bitmap 4829 (of 32768 bits) is wrong - mark all blocks [1582 36672 - 158269440] as used init_source_bitmap: Bitmap 4830 (of 32768 bits) is wrong - mark all blocks [1582 69440 - 158302208] as used init_source_bitmap: Bitmap 4831 (of 32768 bits) is wrong - mark all blocks [1583 02208 - 158334976] as used init_source_bitmap: Bitmap 4832 (of 32768 bits) is wrong - mark all blocks [1583 34976 - 158367744] as used Skipping 23115 blocks (super block, journal, bitmaps) 457595811 blocks will be r ead 0%.. left 414643572, 32343 /se block 311144394: The number of items (5135) is incorrect, should be (1) - correc ted block 311144394: The free space (1024) is incorrect, should be (3792) - correcte d pass0: vpf-10110: block 311144394, item (0): Unknown item type found [4229627906 436217958 0xd70040f1 (15)] - deleted left 0, 25316 /secc Could not find a hash in use. Using "r5" Selected hash ("r5") does not match to the hash set in the super block (not set) . "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 457595811 Leaves among those 1 - leaves all contents of which could not be saved and de leted 1 Objectids found 2 Pass 1 (will try to insert 0 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished Flushing..finished 0 leaves read 0 inserted ####### Pass 2 ####### Flushing..finished No reiserfs metadata found. If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you have used one. Then you probably rebuilt the superblock as there was no one. Zero the block at 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfs /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version. Aborted (core dumped) root@Tower:~# What is recommended? I read the above debugreiserfs /dev/xxx but want to make sure before I proceed. Thanks in advance.

Understood. Any guidance as to what I should/could try next?