Owel Posted September 15, 2015 Share Posted September 15, 2015 unRAID OS Version: 6.1.2 Description: After a reboot, my drive for Disk 2 is missing: X Disk 2 SAMSUNG_HD204UI_S2H7JX0B300872 - 2 TB (sdf) if I run fdisk -l i got the following result: root@Tower:~# fdisk -l Disk /dev/sda: 515 MB, 515375104 bytes 16 heads, 32 sectors/track, 1966 cylinders, total 1006592 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xeca48859 Device Boot Start End Blocks Id System /dev/sda1 * 32 1006591 503280 6 FAT16 WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes 256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 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 Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 1 4294967295 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes 256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 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 Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 1 4294967295 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. Disk /dev/sdd: 200.0 GB, 200049647616 bytes 1 heads, 63 sectors/track, 6201936 cylinders, total 390721968 sectors Units = sectors of 1 * 512 = 512 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 64 390721967 195360952 83 Linux WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sde: 3000.6 GB, 3000592982016 bytes 256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 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 Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sde1 1 4294967295 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. [b]Disk /dev/sdf: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 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/sdf1 64 3907029167 1953514552 83 Linux[/b] How to reproduce: Behavior persists after several reboots Any hints? Link to comment
itimpi Posted September 15, 2015 Share Posted September 15, 2015 If a disk is missing it can be emulated by using the other data disks + parity. At this point you are running unprotected and if another disk fails this can result in data loss. To get back to a protected state you need to replace and rebuild the missing disk. Link to comment
Owel Posted September 15, 2015 Author Share Posted September 15, 2015 Yes I know that. but the fact is, that the array is stopped! and fdisk -l still list /dev/sdf1 My understanding is, if one drive is missing, unraid will emulate it. But if the array is stopped, the disk is not emulated, correct? i can even do a passed/successful smartctl -a /dev/sdf Link to comment
RobJ Posted September 16, 2015 Share Posted September 16, 2015 Yes I know that. but the fact is, that the array is stopped! and fdisk -l still list /dev/sdf1 My understanding is, if one drive is missing, unraid will emulate it. But if the array is stopped, the disk is not emulated, correct? i can even do a passed/successful smartctl -a /dev/sdf Owel, your description of the behavior here sounds completely correct, just the way unRAID has always handled it. Are you saying that it shouldn't be correct behavior? What do you feel should have happened? I'm probably not understanding the point you are trying to make. Link to comment
JonathanM Posted September 16, 2015 Share Posted September 16, 2015 Shot in the dark, but I think the confusion stems from a lack of knowledge about how unraid uses the underlying /dev/sd? devices to build a parity protected array. The OP says an array slot shows a missing disk, but the underlying disk device is there and appears perfectly fine. The /dev/md? parity protected array devices are only available with the array running, but the underlying /dev/sd? devices are available even when the array is stopped. That is perfectly normal behavior when a write to the underlying device fails, as unraid then drops the physical device from the protected array, and goes on with business as usual by presenting the emulated /dev/md? for use as normal. The "failed" device is no longer being written to, and will become more and more out of sync with the array slot. The drive must be rebuilt to synchronize the data that has been written to the /dev/md? device to the /dev/sd? device that was linked to that slot. Why the drive was dropped is the million dollar question, but since the OP indicates a successful smart test (didn't post results so can't confirm), I'd say rebuilding the drive back to itself is probably the correct action. Link to comment
Owel Posted September 16, 2015 Author Share Posted September 16, 2015 Hey thanks for clarification. So I assume as well, that the drive is gone missing, data was written to it, which the parity drive got, but the missing disk not. So I will try to rebuild it! Link to comment
itimpi Posted September 16, 2015 Share Posted September 16, 2015 Hey thanks for clarification. So I assume as well, that the drive is gone missing, data was written to it, which the parity drive got, but the missing disk not. So I will try to rebuild it! A point of clarification here - the data is not strictly speaking written as such to the parity drive. Instead the parity drive is adjusted to what it would be if the physical drive (that is being simulated) had been written. Because it is disabled the actual write to the physical drive did not happen so now the simulated and real drive are out of sync. This is why it is necessary to do a rebuild to get the simulated drive and physical drive back in sync. Link to comment
jonp Posted September 20, 2015 Share Posted September 20, 2015 Moving this to general support. Not a defect. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.