Shamutanti

Thanks Jorge, I'll give that a try.

looking at the syslog, probably parity + 1 drive were spun up, rest down.

Don't think so; i'd stopped the docker service a few minutes before but that didn't do anything. It had been running at the slow speed for about 20 hours, then in the space of 30 seconds between running the diagnostics and going back to 'Main', went straight to normal speed. Hard to imagine that was a complete coincidence although I guess not impossible. Server has been up for a few months so that was why I was wondering about some process restarting as part of the diagnostics. That might just be from being more used to Windows though......

Slightly strange one; running a parity check since last night and noticed that the speed was much lower than usual - averaging around 70-75 mb/s insterad of 140-150 (about half). Stopped docker and that didn't make any difference (didn't think it would given what was running). Having looked at some posts online, I ran diagnostics - and immediately speed jumped back up to 150 Mb/s. Does the diagnostics process restart a service, anything like that? Kicked something back into life? Not a particularly serious problem, just seemed weird. I've attached the diagnostics archive. Thanks, tower-diagnostics-20260303-1853.zip

Thanks Jorge, I'll get some replacement cables in first (and move data off in the meantime)

Hi Jorge, Array has restarted without problems; the second disk which was problematic (disk 9) is enabled and working in the array; disk 4 as expected still showing as disabled/emaulted. Neither showing in unassigned devices now. No obvious SMART problems for either (updated syslog and diags attached) ; only unusual thing my amateur eye can spot in the syslog is this bit : ov 15 11:22:41 Tower emhttpd: shcmd (207): xfs_admin -U generate /dev/md4p1 Nov 15 11:22:41 Tower root: ERROR: The filesystem has valuable metadata changes in a log which needs to Nov 15 11:22:41 Tower root: be replayed. Mount the filesystem to replay the log, and unmount it before Nov 15 11:22:41 Tower root: re-running xfs_admin. If the filesystem is a snapshot of a mounted filesystem, Nov 15 11:22:41 Tower root: you may need to give mount the nouuid option. If you are unable to mount Nov 15 11:22:41 Tower root: the filesystem, then use the xfs_repair -L option to destroy the log and Nov 15 11:22:41 Tower root: attempt a repair. Note that destroying the log may cause corruption -- Nov 15 11:22:41 Tower root: please attempt a mount of the filesystem before doing this.So in theory I could just to a rebuild in place for disk 4 that is disabled; just slightly concerned in as much as at the moment I think all the data on the disk is intact, but if something goes wrong during a rebuild with another drive it might be lost....But if that's the right thing to do then I'll give it a go. - edited to add, I do have enough space on another drive that i could move all the data off this drive first. Although after that i don't know if doing a full rebuild for any empty drive would be worth it.... Thanks, tower-diagnostics-20251115-1126.zip tower-syslog-20251115-1122.zip

I'm runinng Unraid 7.14, syslog and diagnostics attached. Only realised this morning but two drives have become disabled last night. From the syslog it looks like a power glitch (similar output I saw before from a loose cable); both drives are in the same cage. One drive is showing as 'disabled' with an x in 'main' and claiming to be emulated. The other one is still showing as enabled in 'Main', however it doesn't have a temperature reading, can't access SMART directly, can't spin it down with the button. Basically it's like it's disabled but without an x. This drive (disk 9) was streaming a file at the time, in the Syslog I've replaced the filename with [FILENAME]. I appear to be able to access data from the emulated drive; although I can see the filenames etc. on the second drive (disk9) I can't access them from Windows, it just errors out. - edited to add, i can access files on the emulated drive but they're gibberish, since presumably it can't get the data from disk9... Both drives are showing in unassigned devices (I assume with new ID's); the diagnostics was able to access the SMART info from both and I can't see any problems. The data on both I think is very likely to be intact. So I could power down the server, reseat the cables etc., and power it back up again. However I can't do a rebuild in place (this is what I did before when 1 drive had this problem), as two drives are disabled. Or since disk 9 doesn't seem to be marked as disabled, perhaps it will just work on powering back up. Or, can I in some fashion mark both of these drives as 'good', then just rebuild parity?. Or if some other procedure would be appropiate, any advice would be much appreciated. Thanks, tower-syslog-20251114-1844.zip tower-diagnostics-20251114-1848.zip

Thanks Jorge, I will give that a try and report back if any problems.

Running v. 7.1.4, I'm in the middle of carrying out the 'remove disk' procedure, using the 'parity-preserve method'; I've removed the files from one drive (disk 10) and I'm currently zeroing the disk using dd before removing it from the array. I'd turned on 'reconstruct write' to speed the process. I've attached the syslong and diagnostics. After about an hour (although I didn't see this until some hours later), one of the other disks (disk 11) becamed disabled and is now being emulated; looking in the syslog there are some SAS errors at around 17:11; followed by a load of read and write errors (possiblu caused by the disk being disabled). I've turned off reconstruct write, and so now the zeroing is continuing just with the disk for removal (and parity) being accessed. So my first question is; can I complete the removal process? Let the zeroing finish; stop array; reset configuration (keeping assignments); unassign the drive to be removed; and restart the array with parity valid. Or, will this cause problems with one of the other drives being emulated? Then, what steps should I take in terms of investigating the failed drive? It might be as simple as a cable connection (as I have been replacing some drive cages, although not the one with this drive); or a problem with the drive. I do have drives of an appropiate size that I could easily enough use as a replacement (with the normal rebuild procedure) if that would be the most sensible thing to do before anything else. Thanks for any advice, Edited to add - the disabled disk is showing in unassigned devices; can be spun up and SMART report seems fine, so I guess a cable problem or temporary glitch? tower-syslog-20251011-2251.zip tower-diagnostics-20251011-2356.zip

Scenario is, I have two servers, and I want to replace a disk in the main server with a larger one. I have the new disk precleared and ready to go in the 2nd server; and no free drive bays in the main server. Ideally, I'd like to mount the new drive remotely in the main server (unassigned devices plugin?); make a bit-for-bit copy of the existing drive onto the new one (dd?); expand the filesystem on the new one (if that's the right term), and then simply swap them over, with parity already valid. No need to do any rebuilding, thrash all the disks for a couple of days etc. etc. Hunting around on the forums it seems that all these things are theoretically possible, I'm just not really sure of the commands I would use (particularly for the copy and expand parts). Any pointers (or existing guides etc.) gratefully appreciated.

Thanks Jorge, I'm rebuilding parity now, seems to be going smoothly. I checked the cabling and the latch on that particular SATA connector wasn't clicking, so I've swapped that one to the drive I'm removing and ordered a replacement. I'll report back if any further problems crop up.

Just an update on this; the disabled drive appears to be healthy and to have all the data intact (I've been able to mount it and browse the files with the array stopped). If so, probably the best plan will be to do a new configuration and rebuild parity? Specifically : Stop Array New config ; preserve current assignments Unassign the empty/unmountable disk (that I want to remove anyway) Do nothing with the disabled drive (that I think is fine in terms of data) start the array, which will rebuild parity. Does that sound reasonable? I'm happy to try and rebuild the data drive first (onto itself) but I don't know if that will work with an unmountable drive as well

Hi, I was running the Shrink Array process (from here) to zero an empty drive (disk 2) out then remove it. However just as the zeroing started, I noticed that another drive (disk 15) was showing as disabled ('a mandatory smart command failed'). I assumed that it was a glitch, something to do with unmounting / zeroing the initial drive, so I stopped the zeroing process, and rebooted the server. Unfortunately I rebooted without grabbing any logs so I don't have anything from when the error happened; I've attached the current diagnostics anyway. The disabled drive is now reporting SMART normally, and showing no errors; however it is still in a disabled/emulated state. Also the drive I was zeroing, is showing as unmountable (because, I assume, it has been zeroed enough to wipe out the file system). I am reasonably confident all the drives are healthy, did a parity check a few days ago with no problems, and as of now none of the drives have any SMART errors. I also only upgraded to 6.9.2 from 6.8.3 earlier today but I assume that's not relevant. But I'm not sure how I should proceed to restore things to health. Should i rebuild the disabled drive? I assume it will be out of sync now with parity since I was writing zeros to the initial drive when it became disabled. But - can I do this with that (empty) drive unmountable? Or should I start the zeroing process again, let that finish (30hrs or so), remove that drive, and then rebuild the emulated drive? Or of course, something else altogether. Any advice gratefully recieved... tower-diagnostics-20220304-1951.zip

Hi - not sure if anyone can help; I've had a read around but I haven't quite managed to answer my questions. I'm aiming to replace an existing 3tb ReiserFS data disk with a new 8tb XFS drive, then physically remove the existing 3tb drive (to leave space for a future large drive when needed). Rather than convert everything now, I'll just add larger replacement XFS drives as I need more space. I'm running version 6.2.1, with one parity drive. I've followed the File System Conversion procedure, currently on step 8 (data is all copying with rsync to the new drive, about 80% done). I'd misunderstood what excluding the disk did (I thought it excluded it from parity, understand better now), so I can't simply remove the old disk and have parity stay valid. I believe I still follow the procedure down to step 16 (restart the array with 'parity already valid' checked.). But what should I do next? I could, I think, unassign the old drive then rebuild parity, but ideally I'd like to keep protected. Should I follow the procedure to Shrink Array? That is, remove the share exclusion, format the disk (as XFS) to clear it quickly, run the 'Clear Me' user script, and follow the assorted other steps to remove the drive? If that is the case, then my only remaining confusion would be whether to remove the exclusion, then format, or the other way round. But I'd also like to know if (a) there's a better/faster way of removing my now-unneeded duplicate data disk, and (b) since I'll be repeating the procedure at some future point, if my aim from the start is just to remove the original disk once the data is copied, is there a simpler overall method? Ideally I suppose to make a duplicate of the original disk, onto the new XFS file system, but without changing parity (so I could just copy the drive, swap assignments, and be done). Thanks in advance for any help that can be offered, TC