March 14, 20179 yr Hello, I have a disk in my unRaid array that is a WD 1TB Red. As shown below, unRaid is showing this correctly in the disk and device portion. However, in the right side the size, used and free information is showing a 4TB drive, which is clearly incorrect. I've pasted the output of fdisk for the drive also showing it's 1TB. I was going to replace the drive with a 4TB drive until I saw this. Is this a cosmetic issue? Is there a way to "reset" the sized, used and free information? Am I ok to replace it with a bigger drive? Thanks, Al root@Tower:~# fdisk -l /dev/sdc Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdc1 64 1953525167 1953525104 931.5G 83 Linux EDIT: The stat plugin is showing the size correctly. Edited March 14, 20179 yr by ajeffco Added information, updated title
March 14, 20179 yr Author Took a shot and replaced it, and now the GUI is showing correct total size, however used and free haven't changed. Still an oddity however. Not sure why it thought the 1TB had 3.92TB used. Al
March 14, 20179 yr Need more information. That's not cosmetic, that's something that is really wrong. Need to see the diagnostics from the first post, as well as what actions you may have taken before that, as well as what steps you took to replace the drive with the 4TB. Parity is probably completely invalid. Is it possible you restored super.dat from an older backup?
March 14, 20179 yr Also suspiciously similar to this, since its btrfs. Unfortunately in this case the user decided to reformat to XFS (recommended for array drives) and get rid of BTRFS
March 14, 20179 yr Author 3 hours ago, RobJ said: Need more information. That's not cosmetic, that's something that is really wrong. Need to see the diagnostics from the first post, as well as what actions you may have taken before that, as well as what steps you took to replace the drive with the 4TB. Parity is probably completely invalid. Is it possible you restored super.dat from an older backup? By diagnostics, are you talking about the "diagnostics" command output file? This is a new install, nothing was restored. I started with a few drives, migrated some data from my other machine, move drives over, preclear, add to array, etc. Two of the drives were 1TB drives and were replaced to gain more space. Right now, it looks normal in the GUI as shown below. I randomly picked 5 files on the drive and they are correct. Steps to replace the drive were: Preclear a replacement 4TB. When complete, stop the array, in the Disk 3 selection box, choose the "new" 4TB drive, start the array, let parity rebuild. The results of that action are blow, the data rebuild on Disk 3 just completed about an hour ago. I don't doubt that it was a serious problem, just not sure how to proceed to assist with any resolution if there is a problem. I'll read that other thread. Thanks, Al Edited March 14, 20179 yr by ajeffco Add steps for rebuild
March 14, 20179 yr Author Unfortunately I stopped and restarted the array just over an hour ago. The diagnostic zip file looks to be mostly reset to that time. So there's nothing pointing at a problem with Disk 3 in that file.
March 14, 20179 yr Community Expert Post the output of both:btrfs fi show /mnt/disk3btrfs fi df /mnt/disk3
March 14, 20179 yr Community Expert 1 hour ago, ajeffco said: Unfortunately I stopped and restarted the array just over an hour ago. The diagnostic zip file looks to be mostly reset to that time. So there's nothing pointing at a problem with Disk 3 in that file. Stopping and starting does not reset the diagnostics. Reboot does. Did you actually go to Tools - Diagnostics and download the diagnostics zip?
March 14, 20179 yr Author 58 minutes ago, johnnie.black said: Post the output of both: btrfs fi show /mnt/disk3 btrfs fi df /mnt/disk3 root@Tower:~# btrfs fi show /mnt/disk3 Label: none uuid: 25d79d48-80f9-4b90-8091-515048193568 Total devices 1 FS bytes used 3.30TiB devid 1 size 3.64TiB used 3.54TiB path /dev/md3 root@Tower:~# btrfs fi df /mnt/disk3 Data, single: total=3.53TiB, used=3.30TiB System, single: total=4.00MiB, used=416.00KiB Metadata, single: total=5.01GiB, used=3.40GiB GlobalReserve, single: total=512.00MiB, used=0.00B
March 14, 20179 yr Author 24 minutes ago, trurl said: Stopping and starting does not reset the diagnostics. Reboot does. Did you actually go to Tools - Diagnostics and download the diagnostics zip? The server has been up for 25+ hours. I should have been more clear. the syslog files are the only ones that appear to go back to the reboot of the server, the others are timestamped with the restart of the array. I'll work on copying my syslogs to stable storage, think I saw a post on that somewhere.
March 14, 20179 yr Community Expert Does the disk still contain the old 1tb data only or did you copy some more? I find curious that both disk2 and 3 have the exact same free space, I've seem some btrfs "confusion" between disks before, can you try copying a >1GB file to disk2 and check that free space changes only for disk2 and not for disk3 also? Still would like to see current diagnostics.
March 14, 20179 yr Community Expert 31 minutes ago, ajeffco said: The server has been up for 25+ hours. I should have been more clear. the syslog files are the only ones that appear to go back to the reboot of the server, the others are timestamped with the restart of the array. I'll work on copying my syslogs to stable storage, think I saw a post on that somewhere. The files other than syslog are indeed a current snapshot. Doesn't matter whether you start/stop or not. There is no history kept of all the many things that they show.
March 14, 20179 yr Author 34 minutes ago, trurl said: The files other than syslog are indeed a current snapshot. Doesn't matter whether you start/stop or not. There is no history kept of all the many things that they show. That makes sense, thank you for explaining it.
March 14, 20179 yr Community Expert You should post the diags on the thread so everyone can see them, more eyes more chance of getting help, not send them by PM, but there's definitely something going on: Mar 13 15:43:56 Tower emhttp: Mounting disks... Mar 13 15:43:56 Tower emhttp: shcmd (51): /sbin/btrfs device scan |& logger Mar 13 15:43:56 Tower root: ERROR: device scan failed on '/dev/md3': File exists Mar 13 15:43:56 Tower root: ERROR: there are 1 errors while registering devices I almost certain my earlier hunch is correct, ie, space stats showing for disk3 are repeated from disk2, did you try to copy a file to disk2 like I asked? You should reboot to see if this goes away, if not it will need further investigation.
March 14, 20179 yr Author I'm getting ready to move these drives and key back to the original system they came from, more drive bays. I'll test that out once it's complete.
March 14, 20179 yr Community Expert 53 minutes ago, johnnie.black said: You should post the diags on the thread so everyone can see them, more eyes more chance of getting help, not send them by PM, but there's definitely something going on: The last paragraph in the first post of this sticky is relevant PLEASE do not privately ask the moderators or other users for personal support! Helpful moderators and users are just users like yourself, unpaid volunteers, and do not provide official support, so it is better to ask support questions on the forum instead. That way, you get the benefit of having answers from the whole community, instead of just one person who may or may not know, or may be wrong, or may be unavailable. Plus, you will probably get faster help. And, other users in the community can benefit by learning from your problem and its solution.
March 15, 20179 yr Community Expert One more thing, since the the btrfs scan error is right after boot and before you upgraded disk3 keep old disk3 intact, just remembered to check this: /dev/md1 1.9T 1.7T 133G 93% /mnt/disk1/dev/md3 3.7T 3.4T 344G 91% /mnt/disk2 /dev/md4 3.7T 3.4T 257G 94% /mnt/disk4 ... So where's disk3 and what disk was rebuilt?
March 15, 20179 yr Author 49 minutes ago, trurl said: The last paragraph in the first post of this sticky is relevant PLEASE do not privately ask the moderators or other users for personal support! Helpful moderators and users are just users like yourself, unpaid volunteers, and do not provide official support, so it is better to ask support questions on the forum instead. That way, you get the benefit of having answers from the whole community, instead of just one person who may or may not know, or may be wrong, or may be unavailable. Plus, you will probably get faster help. And, other users in the community can benefit by learning from your problem and its solution. Trurl, I didn't ask privately for support. He asked for a diagnostic, my mistake was providing it via PM vs. in thread. My apologies. Edited March 15, 20179 yr by ajeffco
March 15, 20179 yr Author 16 minutes ago, johnnie.black said: One more thing, since the the btrfs scan error is right after boot and before you upgraded disk3 keep old disk3 intact, just remembered to check this: /dev/md1 1.9T 1.7T 133G 93% /mnt/disk1/dev/md3 3.7T 3.4T 344G 91% /mnt/disk2 /dev/md4 3.7T 3.4T 257G 94% /mnt/disk4 ... So where's disk3 and what disk was rebuilt? It's sitting on my desk In the GUI I see all my drives. In the CLI, df is missing disk 3. Screenshots and a new diagnostic attached. Would it be easier for me to start converting to and migrating the data to xfs in a rolling fashion starting with Disk 10? GUI: CLI (Missing /dev/md2 aka /mnt/disk3): root@Tower:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 16G 404M 16G 3% / tmpfs 16G 252K 16G 1% /run devtmpfs 16G 0 16G 0% /dev cgroup_root 16G 0 16G 0% /sys/fs/cgroup tmpfs 128M 2.4M 126M 2% /var/log /dev/sda1 976M 152M 825M 16% /boot /dev/md1 1.9T 1.7T 133G 93% /mnt/disk1 /dev/md3 3.7T 3.4T 344G 91% /mnt/disk2 /dev/md4 3.7T 3.4T 257G 94% /mnt/disk4 /dev/md5 1.9T 1.8T 63G 97% /mnt/disk5 /dev/md6 3.7T 3.6T 76G 98% /mnt/disk6 /dev/md7 3.7T 3.6T 75G 98% /mnt/disk7 /dev/md8 3.7T 3.4T 249G 94% /mnt/disk8 /dev/md9 3.7T 784G 2.9T 22% /mnt/disk9 /dev/md10 3.7T 17M 3.7T 1% /mnt/disk10 shfs 33T 25T 8.1T 76% /mnt/user BTRFS FI output in case it helps root@Tower:~# btrfs fi show /dev/md2 Label: none uuid: 25d79d48-80f9-4b90-8091-515048193568 Total devices 1 FS bytes used 3.30TiB devid 1 size 3.64TiB used 3.54TiB path /dev/md3 root@Tower:~# btrfs fi show /mnt/disk3 Label: none uuid: 25d79d48-80f9-4b90-8091-515048193568 Total devices 1 FS bytes used 3.30TiB devid 1 size 3.64TiB used 3.54TiB path /dev/md3 root@Tower:~# btrfs fi df /dev/md2 ERROR: not a btrfs filesystem: /dev/md2 root@Tower:~# btrfs fi df /mnt/disk3 Data, single: total=3.53TiB, used=3.30TiB System, single: total=4.00MiB, used=416.00KiB Metadata, single: total=5.01GiB, used=3.40GiB GlobalReserve, single: total=512.00MiB, used=0.00B tower-diagnostics-20170314-2025.zip
March 15, 20179 yr Author I moved a 12G file as you requested from another disk to disk2, and in the GUI, Drive 2 and Drive 3 are showing the same information, and free space has gone down by 10GB.
March 15, 20179 yr Author After running the test you mentioned, I thought earlier I had accessed files on Disk3. They are really on Disk2. When I do a find in the cli, it's the same files. An example, a file from my synology backup share: root@Tower:/mnt/disk3/synback/filer_1.hbk# find /mnt -name synobkpinfo.db /mnt/user/synback/filer_1.hbk/synobkpinfo.db /mnt/disk3/synback/filer_1.hbk/synobkpinfo.db /mnt/disk2/synback/filer_1.hbk/synobkpinfo.db root@Tower:/mnt/disk3/synback/filer_1.hbk# md5sum /mnt/user/synback/filer_1.hbk/synobkpinfo.db 103358f0b308ae36349bc17d1103e607 /mnt/user/synback/filer_1.hbk/synobkpinfo.db root@Tower:/mnt/disk3/synback/filer_1.hbk# md5sum /mnt/disk3/synback/filer_1.hbk/synobkpinfo.db 103358f0b308ae36349bc17d1103e607 /mnt/disk3/synback/filer_1.hbk/synobkpinfo.db root@Tower:/mnt/disk3/synback/filer_1.hbk# md5sum /mnt/disk2/synback/filer_1.hbk/synobkpinfo.db 103358f0b308ae36349bc17d1103e607 /mnt/disk2/synback/filer_1.hbk/synobkpinfo.db
March 15, 20179 yr Community Expert 39 minutes ago, ajeffco said: Trurl, I didn't ask privately for support. He asked for a diagnostic, my mistake was providing it via PM vs. in thread. My apologies. No need to apologize. Just trying make sure that good advice was better known.
March 15, 20179 yr Author 6 minutes ago, trurl said: No need to apologize. Just trying make sure that good advice was better known. You'd think I knew better . Good reminder tho.
March 15, 20179 yr Community Expert Just now, ajeffco said: You'd think I knew better . Good reminder tho. I would believe johnnie.black before I would believe myself, but in general, there have certainly been cases where someone gave bad advice in public, and it was corrected by others. So if you take advice in private... And there has been more than one occasion where someone PMed me about something that needed a quick response, and I was out in the wilderness somewhere and didn't get the message till much later.
March 15, 20179 yr Author more oddity... lsblk shows the disk at 4TB however btrfs thinks it's 931GB lsblk output for disk 3: sdg 8:96 0 3.7T 0 disk └─sdg1 8:97 0 3.7T 0 part btrfs fi show for /dev/sdg1: btrfs fi show /dev/sdg1 Label: none uuid: 25d79d48-80f9-4b90-8091-515048193568 Total devices 1 FS bytes used 384.00KiB devid 1 size 931.51GiB used 1.02GiB path /dev/sdg1 And unassigned devices shows: It's really jacked up... Edited March 15, 20179 yr by ajeffco Added unassigned devices screenshot
Archived
This topic is now archived and is closed to further replies.