April 22, 201610 yr unRAID OS Version: 6.20-beta21 Description: Cannot format and mount new array How to reproduce: 1. Install 6.19 (5 Data drives; 1 Parity; No Cache) 2. Upgrade to 6.20b21 3. Run New Config Tool (Want 2 Parity and I could now see Samsung 950 M.2, using for cache) 4. Reboot 5. Configure new array (2 Parity / 4 Data / 1 SSD cache) 6. Allow Parity to sync (6 hours). Drives are left in Unmountable state with the FS column as empty 7. Attempt to FORMAT the now unmountable 4 drives, leaving me with 4 unmountable drives, as if I never ran the command at all. Expected results: A functional array of 12TB, two Parity drives, and one SSD for cache. Actual results: An array of 4 "Unmountable" drives. Other information: Since this is a brand new installation, I started with 6.19, but my Samsung 950 M.2 was not seen by the OS, no matter what I tried. Eventually it lead me to try 6.20-beta21, and I've seen my SSD ever since, but now I cannot format/mount the array itself I've recreated my system 4 times now. When formatting, it takes almost exactly 65 seconds to step through from drive to drive (watching via LOG). During this time, if I refresh the Web GUI the word "formatting" moves from drive to drive, but the prior drive(s) still show as unmountable. At one point I reformatted the USB stick, installed a fresh version of 6.20b21, booted and ran New Config, used Telnet to get into the unRAID server and used FDISK to delete the single partitions found on each drive (which started at 64). Wrote the partitions and rebooted. I verified that Disk Settings were MBR: 4K-aligned and Default file system: XFS, but after trying again, the individual disks are seen as "Auto", not XFS as expected. Stopping the array, changing each individual disk to XFS and restarting the array forces the Format selections to disappear, but I don't trust the drives then with my data, unless this is an expected step in creating a XFS array (but I don't believe it is). Trying a single drive yields the same results. Hardware: - Asus Z170 Deluxe, Core i7-6700K, 32GB 2666 RAM - Six 3TB drives (1 Hitachi, 1 Seagate Constellation, 2 Seagate NAS, 2 Seagate Barracuda) - Samsung 950 Pro M.2 (retail) - EVGA 980Ti - Thermaltake 850W Power Supply - SanDisk 16G USB ***** Diagnostics output attached. UnRAID.txt tower-diagnostics-20160422-1802.zip
April 29, 201610 yr Author ** Corrected Actions ** I was surprised that I only found one similar issue from the searches I did, where someone was unable to format the unmountable drives. Literally forcing each drive from "Auto" to "xfs" allowed the array to start and has run since. I was very skeptical in doing this, but I've copied almost 4TB of data to the array, and while I did have a failing Seagate Constellation drive as one of my two Parity drives, all data is valid. I just now replaced the Constellation with a Barracuda I already had with me. I have Plex running 24x7, along with a Windows 10 Professional desktop when needed, and use only about a third of my processor when playing a game (Left 4 Dead 2) as a test. I'm really pleased with this and am looking forward to the stable 6.2 release so I can keep my 2nd Parity and use my Samsung 950 M.2 as a Cache/VM drive.
June 10, 201610 yr I have seen this on one or two users systems, and it seems to me to be a potentially dangerous situation. The actual circumstances are that the New Config tool creates a new drive configuration, with no drives assigned. When the user assigns their existing drives on the Main page, the drives have only the default settings, including "File system = Auto". And they aren't taken to the drive configuration page to correctly set that, to set the drive with the actual file system format. The Auto setting does not appear to correctly cause the drive to be mounted with the right file system (should it?), so it then appears 'Unmountable'. For now, we can try to educate users that if they need to use the New Config tool, not only take notes on the drive serial numbers but also note the file system format for each, then after reassigning the drives, make sure that their file system formats are also set correctly, not left at Auto.
June 10, 201610 yr Every time I have tried a New Config the auto setting has correctly determined the existing format. After first starting the array the format is correctly changed from auto to the detected format. Maybe there needs to be some investigation into why it is failing for some people so it can be made more reliable. Also, perhaps some sort of hybrid approach where the user is prompted for more information when attempting to start an array and the disk is currently set to auto and is flagged as unmountable is needed?
June 14, 201610 yr This happened to me when using a disk that was formatted with xfs was then formatted with btrfs, somehow that disk mounts with fs set to btrfs or xfs, with auto it's unmountable because unRAID detects more than one filesystem. Auto: Jun 14 09:41:42 Tower emhttp: Mounting disks... Jun 14 09:41:42 Tower emhttp: shcmd (305): /sbin/btrfs device scan |& logger Jun 14 09:41:42 Tower root: Scanning for Btrfs filesystems Jun 14 09:41:42 Tower emhttp: shcmd (306): mkdir -p /mnt/disk1 Jun 14 09:41:42 Tower emhttp: shcmd (307): set -o pipefail ; mount -t auto -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Jun 14 09:41:42 Tower root: mount: /dev/md1: more filesystems detected. This should not happen, Jun 14 09:41:42 Tower root: use -t <type> to explicitly specify the filesystem type or Jun 14 09:41:42 Tower root: use wipefs( to clean up the device. Jun 14 09:41:42 Tower emhttp: shcmd: shcmd (307): exit status: 1 Jun 14 09:41:42 Tower emhttp: mount error: No file system (1) Jun 14 09:41:42 Tower emhttp: shcmd (308): umount /mnt/disk1 |& logger Jun 14 09:41:42 Tower root: umount: /mnt/disk1: not mounted BTRFS: Jun 14 09:46:05 Tower emhttp: Mounting disks... Jun 14 09:46:05 Tower emhttp: shcmd (531): /sbin/btrfs device scan |& logger Jun 14 09:46:06 Tower root: Scanning for Btrfs filesystems Jun 14 09:46:06 Tower emhttp: shcmd (532): mkdir -p /mnt/disk1 Jun 14 09:46:06 Tower emhttp: shcmd (533): set -o pipefail ; mount -t btrfs -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Jun 14 09:46:06 Tower kernel: BTRFS info (device md1): disk space caching is enabled Jun 14 09:46:06 Tower kernel: BTRFS: has skinny extents Jun 14 09:46:06 Tower emhttp: shcmd (534): btrfs filesystem resize max /mnt/disk1 |& logger Jun 14 09:46:06 Tower kernel: BTRFS info (device md1): new size for /dev/md1 is 250059317248 Jun 14 09:46:06 Tower root: Resize '/mnt/disk1' of 'max' XFS: Jun 14 09:47:21 Tower emhttp: Mounting disks... Jun 14 09:47:21 Tower emhttp: shcmd (681): /sbin/btrfs device scan |& logger Jun 14 09:47:21 Tower root: Scanning for Btrfs filesystems Jun 14 09:47:21 Tower emhttp: shcmd (682): mkdir -p /mnt/disk1 Jun 14 09:47:21 Tower emhttp: shcmd (683): set -o pipefail ; mount -t xfs -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Jun 14 09:47:21 Tower kernel: XFS (md1): Mounting V5 Filesystem Jun 14 09:47:21 Tower kernel: XFS (md1): Ending clean mount Jun 14 09:47:21 Tower emhttp: shcmd (684): xfs_growfs /mnt/disk1 |& logger Jun 14 09:47:21 Tower root: meta-data=/dev/md1 isize=512 agcount=4, agsize=15262410 blks Jun 14 09:47:21 Tower root: = sectsz=512 attr=2, projid32bit=1 Jun 14 09:47:21 Tower root: = crc=1 finobt=1 spinodes=0 Jun 14 09:47:21 Tower root: data = bsize=4096 blocks=61049638, imaxpct=25 Jun 14 09:47:21 Tower root: = sunit=0 swidth=0 blks Jun 14 09:47:21 Tower root: naming =version 2 bsize=4096 ascii-ci=0 ftype=1 Jun 14 09:47:21 Tower root: log =internal bsize=4096 blocks=29809, version=2 Jun 14 09:47:21 Tower root: = sectsz=512 sunit=0 blks, lazy-count=1 Jun 14 09:47:21 Tower root: realtime =none extsz=4096 blocks=0, rtextents=0
June 14, 201610 yr Wow! Yikes! Clearly one or both are not clearing out the initial sectors on format, their signature locations do not coincide, their 'superblock' locations do not coincide, and one or both are not validating very far AT ALL! Did you try an initial root folder access?
June 14, 201610 yr Wow! Yikes! Clearly one or both are not clearing out the initial sectors on format, their signature locations do not coincide, their 'superblock' locations do not coincide, and one or both are not validating very far AT ALL! Did you try an initial root folder access? No, I formatted to Reiserfs and than back to BTRFS and this time worked as expected.
June 14, 201610 yr Perhaps Tom should add a line to zero out the first megabyte, before formatting to XFS or BTRFS.
June 21, 201610 yr Perhaps Tom should add a line to zero out the first megabyte, before formatting to XFS or BTRFS. That's a good idea, looks like this can also be an issue to users coming from ZFS, the quick XFS format dosesn't clear the ZFS info and disks fail to mount in "auto". 2 examples: http://lime-technology.com/forum/index.php?topic=49245.msg472623#msg472623 http://lime-technology.com/forum/index.php?topic=49834.msg478691#msg478691
Archived
This topic is now archived and is closed to further replies.