Ran hdparm -W1 /dev/sdb and disks freaked out

[sorano]

The latest fix common problems version was complaining that one of my disks did not have write cache enabled.

 

So in order to fix that I ran hdparm -W1 /dev/sdb (while the array was still mounted). hdparm took longer than normal and ended up with a failure, then just seconds after hdparm ended, unraid started reporting errors on all 4 disks connected to the same hdd cabinet as /dev/sdb. Eventually unraid dropped one of the disks and marked it as failed.

 

I stopped the array.

Unassigned the disk that had been marked as failed.

Started the array.

Stopped the array.

Re-assigned the disk that had been failed.

Now it's running Parity-Sync/Data-Rebuild.

 

The thing is, I browsed some of my shares and noticed there were folders that were just empty. Will the files inside those folder be recreated when parity/data-rebuild is completed or did I suffer major dataloss? If so can I do anything to try to recover those files? (No backup).

 

Edit: Forgot diagnostics.

tower-diagnostics-20190516-1724.zip

Edited May 16, 2019 by sorano

[JorgeB]

You should have rebooted before rebuilding, or at least posted the diagnostics.

[itimpi]

A rebuild will never put back something that you cannot already see in the ‘emulated’ disk.    It is possible those folders have simply been created because the split level allowed it but their contents have ended up on another disk?

[sorano]

Ok, I forgot to mention I powercycled the cabinett that hosts the drives that had errors after the first stop of the array.

 

I take it nothing can be done to save the lost files now?

 

About split-level, I'm running: Automatically split any directory as required.

 

I tested to browse the share from webgui, how could I verify if they are anywhere else @itimpi ?

 

[JorgeB]

3 minutes ago, sorano said:

I take it nothing can be done to save the lost files now?

We'd need the diagnostics to see exactly what happened and what you did, without them not really much we can say.

[sorano]

Diagnostics are attached in first posts.

 

Give me a min and I'll locate the time when it happened.

 

In the syslog file:

May 16 12:29:52 Tower sshd[7773]: Accepted password for root from 10.0.1.11 port 51344 ssh2
May 16 12:30:12 Tower kernel: usb 4-1: USB disconnect, device number 2

 

So between 12:29:52 and 12:30:12 I ran hdparm -W1 /dev/sdb

 

 

Edited May 16, 2019 by sorano

[itimpi]

I cannot see how the sequence you describe could lead to files going missing unless it was a file being written at the time of the incident.

[JorgeB]

Just now, itimpi said:

I cannot see how the sequence you describe could lead to files going missing

Same, I was afraid you were rebuilding disk2 with errors on other disks, but it appears to all be good, emulated disk2 mounted correctly and it's full:

Filesystem      Size  Used Avail Use% Mounted on
/dev/md2        2.8T  2.6T  174G  94% /mnt/disk2

@Squidmight be a good idea to discourage users from running hdparm on USB disks, since USB command/SMART support is iffy.

 

[Squid]

46 minutes ago, johnnie.black said:

@Squidmight be a good idea to discourage users from running hdparm on USB disks, since USB command/SMART support is iffy.

 

But it's a long weekend...  I should be able to squeeze that text change in  sometime between breakfast and the first beer (pretty small window though)

 

I do know that under normal circumstances that running the hdparm causes no problems (I tested it without even bothering to stop my array)