RobJ Posted April 25, 2014 Share Posted April 25, 2014 Howdy Tom, We have new reports of mount failures resulting in drives being wrongly marked 'Unformatted'. Please see this for the latest one. This problem just won't go away and die! A package was installed, then a newer version of the package was requested, which caused the the older one to be backed out, but the backing out process aggressively removed any folders it found to be empty, including /mnt! Since we can't legislate away bad behavior(!), some additional safeguards are needed. Easy trick is to recreate /mnt if found missing, or pre-fill it with a zero-byte file or link, so it won't appear empty. It would also be safer to check the return codes of mkdir, would have caught this case. The bigger problem is that since we keep coming up with new ways to fail mounts, we need additional checks before ever marking a drive as 'Unformatted'. I'd prefer marking them as 'Mount Failure' and disallow formatting, unless a drive meets a precise criteria for being truly unformatted. I'm sure I don't have to remind anyone that this issue can result in serious data loss, if an uninformed user proceeds to wrongly format the 'Unformatted' drive(s). Link to comment
WeeboTech Posted April 25, 2014 Share Posted April 25, 2014 We have new reports of mount failures resulting in drives being wrongly marked 'Unformatted'. Please see this for the latest one. This problem just won't go away and die! ... The bigger problem is that since we keep coming up with new ways to fail mounts, we need additional checks before ever marking a drive as 'Unformatted'. I'd prefer marking them as 'Mount Failure' and disallow formatting, unless a drive meets a precise criteria for being truly unformatted. I'm sure I don't have to remind anyone that this issue can result in serious data loss, if an uninformed user proceeds to wrongly format the 'Unformatted' drive(s). This is crucial, it can lead to a big mistake. Mount failure is a good choice for this condition. Perhaps there needs to be two checks in emhttp. 1. preclear signature = unformatted. 2. reiserfs or some other condition = mount failure. IE. Only allow formatting on a drive that has a preclear signature. Link to comment
SSD Posted April 26, 2014 Share Posted April 26, 2014 Another option is to do an "fdisk -l" on the drive. It will report if there is a partition defined on the disk already. Only show "unformatted" if there is no partition. Otherwise give a "mount failure" message. Link to comment
Joe L. Posted April 26, 2014 Share Posted April 26, 2014 Another option is to do an "fdisk -l" on the drive. It will report if there is a partition defined on the disk already. Only show "unformatted" if there is no partition. Otherwise give a "mount failure" message. That might work... At the least, do not treat the disk as "unformatted" if it had already been part of the array. (On earlier versions of unRAID, we could look in the disk.cfg file. ) In some cases, it had been found that the MBR had been modified by emhttp to cause the start of the partition to point to the wrong sector. The only way to get those disks back online was to first fix the MBR to point to the correct partition start, then to allow emhttp to attempt to mount. You are correct though, a mount failure could easily be caused by any number of possible issues, from partitioning, to a reiserfsck incorrectly on the raw drive, to a true bad drive sector, to a missing mount-point. ) Link to comment
WeeboTech Posted April 29, 2014 Share Posted April 29, 2014 According to this code from busybox, there's a way to check the superblock. https://casper.berkeley.edu/svn/trunk/roach/sw/busybox-1.10.1/util-linux/volume_id/reiserfs.c Link to comment
dgaschk Posted April 29, 2014 Share Posted April 29, 2014 If the disk is new report "unformatted" and otherwise report "mount failure". I think this is the best we can hope for. Link to comment
WeeboTech Posted April 29, 2014 Share Posted April 29, 2014 I was just thinking about this a few moments ago too. I came to the thought, if the precursor to adding a drive into the array is a preclear signature, then only present an unformatted status with option to format if the preclear signature exists. Otherwise just present a mount failure status with no format option. Link to comment
itimpi Posted April 29, 2014 Share Posted April 29, 2014 I was just thinking about this a few moments ago too. I came to the thought, if the precursor to adding a drive into the array is a preclear signature, then only present an unformatted status with option to format if the preclear signature exists. Otherwise just present a mount failure status with no format option. You also have to allow for a drive that does not have a pre-clear status but also does not have the unRAID partition layout (e.g. a new disk that has just been added). This would also count as unformatted I would have thought. Why not introduce a new status for when the pre-clear signature is detected - something like "awaiting format" although there would probably be a better term. Ideally there would be a new signature written on first adding the drive to show that the pre-clear is needed/in progress. Link to comment
speeding_ant Posted April 29, 2014 Share Posted April 29, 2014 +1 for more thorough error checks. I've recently had a drive fail to mount due to a hardware error, and the array started with the drive unformatted. If a partition is clearly visible, but the mount failed, the drive should not be shown as unformatted. It should instead be shown as 'mount failed'. Link to comment
Recommended Posts