All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: clear smart error log on wd red 8tb
PostPosted: September 20th, 2017, 12:43 
Offline

Joined: August 24th, 2017, 1:56
Posts: 12
Location: United States
just an update for completeness: the hitachi format unit does work on the wd red 8tb (and 10tb most likely). the drive was completely wiped, so apparently the operation continued after windows 10 bluescreened. i'd imagine the outcome would have been different had the drive not been powered by an external psu. as suspected, nothing changed in the smart counters nor were the smart logs cleared.


Top
 Profile  
 
 Post subject: Re: clear smart error log on wd red 8tb
PostPosted: September 20th, 2017, 14:25 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 8121
Location: Portugal
The idea of the format unit command is to move the g-list to the p-list and clear all sectors like on the security erase ....

That is why only re-located sector count / pending sectors / etc will change.

http://www.hddoracle.com/viewtopic.php? ... =40#p14538

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: clear smart error log on wd red 8tb
PostPosted: September 30th, 2017, 7:23 
Offline

Joined: August 24th, 2017, 1:56
Posts: 12
Location: United States
so i've noticed some strange behaviour in the drive i ran format unit on (and ran the clear smart vsc). when running "hdparm -t", which does a 3 second read from the start of the disk, it is consistently scoring at least 20MB/s lower than the other 5 drives. also, when running "dd" for 3s to simulate what "hdparm -t" does, there is also a marked reduction in performance. over the course of a longer sequential read, the difference seems to disappear. this was also confirmed on a long sequence of random reads using the "fio" benchmark utility. the iops are the same between the "good" and "bad" drive which are attached to the same pci-e controller.

i'm wondering if i've inadvertently initialized the g-list on the drive, causing it to seek to a special area of the disk before initiating the benchmarks e.g. hdparm/dd? it'd explain why the difference is only in the first seconds of the benchmarks, but after longer sequential reads the instanenous MB/s are the same.

here is what i'm seeing. sdg is the "bad" drive, sdg is the "good" drive on the same controller. the 4 other drives on the internal sata controller seem to do slightly better in max throughput but i'll chalk that up to differences between the intel/asmedia controllers. notice on sdf, the speed is 201MB/s during the first 3s - the first 3s on sdg are only 150MB/s.

would somehow uninitializing the g-list, or something else, possibly restore the performance?

Code:
root@gauss:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@gauss:~# hdparm -t /dev/sdf; hdparm -t /dev/sdg

/dev/sdf:
Timing buffered disk reads: 568 MB in  3.01 seconds = 188.99 MB/sec

/dev/sdg:
Timing buffered disk reads: 508 MB in  3.00 seconds = 169.32 MB/sec

root@gauss:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@gauss:~# timeout -s SIGUSR1 3 dd if=/dev/sdf of=/dev/null bs=1M count=2048
576+0 records in
575+0 records out
602931200 bytes (603 MB, 575 MiB) copied, 3.00073 s, 201 MB/s
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 10.6981 s, 201 MB/s
root@gauss:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@gauss:~# timeout -s SIGUSR1 3 dd if=/dev/sdg of=/dev/null bs=1M count=2048
430+0 records in
429+0 records out
449839104 bytes (450 MB, 429 MiB) copied, 2.99329 s, 150 MB/s
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 12.1081 s, 177 MB/s


Top
 Profile  
 
 Post subject: Re: clear smart error log on wd red 8tb
PostPosted: September 30th, 2017, 7:35 
Offline

Joined: August 24th, 2017, 1:56
Posts: 12
Location: United States
oh, also. the "bad" drive refuses to sleep now, without having been manually coerced e.g. "hdparm -y /dev/sdg". the other drive in it's raid0 pair sleeps without an issue. thinking i'd made a *visible* change to the config, i made a freedos usb and ran hdat2 v60b5 to dump all possible drive/dco/controller/etc. settings into a file to compare. the only differences were in the io addresses and serial/world wide name. fun factoid: hdat2 shows the IEEE OUI as hitachi. but alas, all settings are otherwise identical between the good and bad drive :(

Code:
IEEE OUI                                            000CCAh
   -> Hitachi


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group