October 6, 201411 yr I am running beta 10a, and booting into Xen mode. Most of my data disks are in Reiserfs format, but some are XFS formatted and the cache disk is BTRFS. I did a 'new config' and re-assigned all the disks, and then started the array. When the array was started all the Reiserfs disks had their format set correctly and the cache disk was correctly set to btrfs. However the XFS formatted disks were showing the format as 'auto' in the GUI, and the GUI was indicating they were unformatted. Stopping the array; explicitly setting the format for the XFS disks and then restarting the array bought everything up as expected with all disks showing as OK. Looks like there is some sort of issue with auto-recognizing the XFS format?
October 11, 201411 yr I am running beta 10a, and booting into Xen mode. Most of my data disks are in Reiserfs format, but some are XFS formatted and the cache disk is BTRFS. I did a 'new config' and re-assigned all the disks, and then started the array. When the array was started all the Reiserfs disks had their format set correctly and the cache disk was correctly set to btrfs. However the XFS formatted disks were showing the format as 'auto' in the GUI, and the GUI was indicating they were unformatted. Stopping the array; explicitly setting the format for the XFS disks and then restarting the array bought everything up as expected with all disks showing as OK. Looks like there is some sort of issue with auto-recognizing the XFS format? Tried exactly this using -beta10a on both xen-boot and non-xen boot and cannot reproduce, that is, works for me. Please get it to happen again and this time post your system log thx
October 11, 201411 yr Author I am running beta 10a, and booting into Xen mode. Most of my data disks are in Reiserfs format, but some are XFS formatted and the cache disk is BTRFS. I did a 'new config' and re-assigned all the disks, and then started the array. When the array was started all the Reiserfs disks had their format set correctly and the cache disk was correctly set to btrfs. However the XFS formatted disks were showing the format as 'auto' in the GUI, and the GUI was indicating they were unformatted. Stopping the array; explicitly setting the format for the XFS disks and then restarting the array bought everything up as expected with all disks showing as OK. Looks like there is some sort of issue with auto-recognizing the XFS format? Tried exactly this using -beta10a on both xen-boot and non-xen boot and cannot reproduce, that is, works for me. Please get it to happen again and this time post your system log thx OK - I am going to introduce a new 6TB disk into the configuration (it is currently pre-clearing), so will do a new config as part of the process. Ideally as I understand the current expected behaviour with beta 10a, if I simply assign the drives with default settings the new disk should be auto-formatted to XFS, and my existing XFS formatted disks should be recognised as such without me needing to explicitly specify the format?
October 11, 201411 yr Author Reproduced the problem easily enough. First an observation that might be relevant to shutdown problems? I was running a pre-clear, but as that was not part of the array I decided I could do the test anyway, so issued a shutdown via the GUI. This appeared to 'hang' and looking at the syslog the last entry shown mentioned a sync. Samba had been shutdown. but the system was otherwise fine and telnet was still available. A manual sync command via telnet also appeared to hang. I left it in this state for an hour or so but the shutdown did not complete. I then aborted the pre-clear and the array shutdown immediately proceeded as normal. My guess was that the sync command was stopped from completing because the pre-clear was continually writing to a disk (although it was not part of the array). This raises the question of whether the sync is actually necessary when shutting the array - does an umount command automatically flush data for the particular device being unmounted? This could explain some cases where people have reported 'hangs' if activity on a non-array device can cause an apparent hang in the GUI when you try and do a shutdown. Back to the problem for this defect report. I have attached screen shots via as to what the GUI showed at the various stages, and also the syslog . When the shutdown completed I immediately did a new config and assigned the devices to the array. At this point the GUI was showing all drives as 'auto'. I then started the array, and disk3 (which is XFS format) still showed as 'auto' and as unformatted. All other drives showed correct format of 'reiserfs' for remaining data drives and btrfs for the cache drive. I now stopped the array. I went into the settings for disk3. It showed 'auto' and I changed this to 'XFS'. I now started the array again and drive 3 was no longer showing as unformatted and was correctly shown as XFS. If you want me to run any other test or get different diagnostics then please let me know. syslog.zip
October 11, 201411 yr Here is the problem detailed in the syslog: Oct 11 16:17:14 DJW-UNRAID logger: mount: /dev/md3: more filesystems detected. This should not happen, Oct 11 16:17:14 DJW-UNRAID logger: use -t <type> to explicitly specify the filesystem type or Oct 11 16:17:14 DJW-UNRAID logger: use wipefs( to clean up the device. Oct 11 16:17:14 DJW-UNRAID logger: Oct 11 16:17:14 DJW-UNRAID logger: mount: you must specify the filesystem type I have to go find the source code to mount.c to find out wtf that means. Meanwhile, what is the history of that drive? Meaning, how did you initially format to xfs?
October 11, 201411 yr Here is the problem detailed in the syslog: Oct 11 16:17:14 DJW-UNRAID logger: mount: /dev/md3: more filesystems detected. This should not happen, Oct 11 16:17:14 DJW-UNRAID logger: use -t <type> to explicitly specify the filesystem type or Oct 11 16:17:14 DJW-UNRAID logger: use wipefs( to clean up the device. Oct 11 16:17:14 DJW-UNRAID logger: Oct 11 16:17:14 DJW-UNRAID logger: mount: you must specify the filesystem type I have to go find the source code to mount.c to find out wtf that means. Meanwhile, what is the history of that drive? Meaning, how did you initially format to xfs? Is this http://comments.gmane.org/gmane.comp.file-systems.btrfs/38323 applicable?
October 11, 201411 yr Author I have to go find the source code to mount.c to find out wtf that means. Meanwhile, what is the history of that drive? Meaning, how did you initially format to xfs? The drive was formatted to XFS using the unRAID GUI. Not sure exactly what beta release - it could have been beta 7 or beta 8 in case the data corruption bug might be relevant.. Just had a quick look using gdisk, and their is definitely only one partition on the drive. I have also had the problem where I was getting kernel errors when running parity checks in KVM mode - not sure if that is relevant. Am currently running in Xen mode where I do not get kernel errors. As I currently have a 6TB drive that has just been pre-cleared I could use that to move all the data off that drive, and then reformat it to see if that makes a difference? However doing that would take several days so I will wait to see if you would prefer me to do anything else.
October 11, 201411 yr I recently did an initconfig with no problem. I had been moving data off of my drives and converting them to xfs. In doing that I had a few empty drives so I removed them. So when I did the init config and started the array, all my data drives were showing auto. I panicked for a bit thinking I was going to be screwed but when the array started, my data drives were correctly showing as being xfs drives. The drives were all formatted on b10a.
October 12, 201411 yr I have to go find the source code to mount.c to find out wtf that means. Meanwhile, what is the history of that drive? Meaning, how did you initially format to xfs? The drive was formatted to XFS using the unRAID GUI. Not sure exactly what beta release - it could have been beta 7 or beta 8 in case the data corruption bug might be relevant.. Just had a quick look using gdisk, and their is definitely only one partition on the drive. I have also had the problem where I was getting kernel errors when running parity checks in KVM mode - not sure if that is relevant. Am currently running in Xen mode where I do not get kernel errors. As I currently have a 6TB drive that has just been pre-cleared I could use that to move all the data off that drive, and then reformat it to see if that makes a difference? However doing that would take several days so I will wait to see if you would prefer me to do anything else. How was it formatted before being re-formatted to xfs?
October 12, 201411 yr Here is the problem detailed in the syslog: Oct 11 16:17:14 DJW-UNRAID logger: mount: /dev/md3: more filesystems detected. This should not happen, Oct 11 16:17:14 DJW-UNRAID logger: use -t <type> to explicitly specify the filesystem type or Oct 11 16:17:14 DJW-UNRAID logger: use wipefs( to clean up the device. Oct 11 16:17:14 DJW-UNRAID logger: Oct 11 16:17:14 DJW-UNRAID logger: mount: you must specify the filesystem type I have to go find the source code to mount.c to find out wtf that means. Meanwhile, what is the history of that drive? Meaning, how did you initially format to xfs? Is this http://comments.gmane.org/gmane.comp.file-systems.btrfs/38323 applicable? Nice find, thank you. Yes this is basically the same issue. When '-t auto' is passed to mount, we are asking mount to go analyze the drive and see if it can determine the file system type. To do so it typically checks the file system "superblock" stored in a well-known location for each file system type. However file systems also store 'backup' superblocks and if mount finds a valid backup it can get into this state of being confused about which file system type it should try to mount - hence the message. The solution is for unRaid to issue an explicit 'wipefs' command prior to running 'mkfs'. I'll put this fix in, but not sure how to correct an existing drive that exhibits this - reformatting would work of course.
October 12, 201411 yr Author How was it formatted before being re-formatted to xfs? It was not formatted. It was a new drive that had just completed a pre-clear. Just for interest I did a new config and added my new 6TB drive that has just been pre-cleared in preparation for copying the data off the problem 6tb disk. When I started the array both the new disk and the problem disk were still set to auto and unformatted - should the pre-cleared one have been preset to XFS? I stopped the array and set them both explicitly to XFS and on restarting the array the problem disk now showed as XFS and containing data while the new one showed as XFS and unformatted (as expected). I now initiated the format of the new disk which completed without issues. I have started copying data off the problem disk so that I can (potentially) reformat it if required. However I am not intending to do that unless you say you cannot get any more useful information from the drive I have in the 'problem' state. This particular problem is not really causing me a problem personally as setting the format XFS explicitly avoids the issue. However I can see it being a potential support issue if the auto-recognise is not working correctly if a user inadvertently formats a disk after doing a new config thus losing data.
October 12, 201411 yr How was it formatted before being re-formatted to xfs? It was not formatted. It was a new drive that had just completed a pre-clear. Interesting... do you happen to have any VM image files on that disk, or the Docker image file?
October 12, 201411 yr Author How was it formatted before being re-formatted to xfs? It was not formatted. It was a new drive that had just completed a pre-clear. Interesting... do you happen to have any VM image files on that disk, or the Docker image file? No - it purely holds media (films) as either iso images or .mkv files. I did a LOT of copying to/from that drive under beta 7 and beta 8 as I was re-organising data. There was definitely file system corruption that I had to fix a few files by getting them from backups so I wonder if this is a side effect of that?
October 12, 201411 yr How was it formatted before being re-formatted to xfs? It was not formatted. It was a new drive that had just completed a pre-clear. Interesting... do you happen to have any VM image files on that disk, or the Docker image file? No - it purely holds media (films) as either iso images or .mkv files. I did a LOT of copying to/from that drive under beta 7 and beta 8 as I was re-organising data. There was definitely file system corruption that I had to fix a few files by getting them from backups so I wonder if this is a side effect of that? Please run a 'file system check' on that drive and let me know if it reports anything "strange".
October 13, 201411 yr Author How was it formatted before being re-formatted to xfs? It was not formatted. It was a new drive that had just completed a pre-clear. Interesting... do you happen to have any VM image files on that disk, or the Docker image file? No - it purely holds media (films) as either iso images or .mkv files. I did a LOT of copying to/from that drive under beta 7 and beta 8 as I was re-organising data. There was definitely file system corruption that I had to fix a few files by getting them from backups so I wonder if this is a side effect of that? Please run a 'file system check' on that drive and let me know if it reports anything "strange". I did - nothing was reported. I have nearly finished copying files off this disk (I would guess another 5-6 hours) and unless I hear otherwise my intention is to clear this disk; 'zero' it to clear any remnants of the current format; and reformat it and afterwards see if I can recreate this problem I am assuming that at the moment this problem is some sort of side-effect of something that happened earlier so it seems sensible to see if the problem is a 'beta' related one that is no longer valid.
Archived
This topic is now archived and is closed to further replies.