Solved Why I can't write sectors on this external USB disk ?

[emmex]

I am trying to write disk sectors in FreeBSD 13.3-RELEASE.
The disk is an 8TB Seagate BarraCuda 3.5 (SMR) with pending sectors:

# smartctl -x -d sat /dev/da0 | grep -A 25 "Pending Defects log (GP Log 0x0c)"
Pending Defects log (GP Log 0x0c)
Index                LBA    Hours
    0        11475952568     7477
    1        11475952569     7477
    2        11475952570     7477
    3        11475952571     7477
    4        11475952572     7477
    5        11475952573     7477
    6        11475952574     7477
    7        11475952575     7477
    8        11475952624     7477
    9        11475952625     7477
   10        11475952626     7477
   11        11475952627     7477
   12        11475952628     7477
   13        11475952629     7477
   14        11475952630     7477
   15        11475952631     7477
   16        11475952640     7477
   17        11475952641     7477
   18        11475952642     7477
   19        11475952643     7477
   20        11475952644     7477
   21        11475952645     7477
   22        11475952646     7477
   23        11475952647     7477

I want to write the pending sectors:

# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16
# time dd of=/dev/da0 if=/dev/zero bs=512 count=8 skip=11475952568
8+0 records in
8+0 records out
4096 bytes transferred in 0.004727 secs (866431 bytes/sec)

_______________________________________________________
Executed in   54.48 mins    fish           external
   usr time   15.13 mins    1.65 millis   15.13 mins
   sys time   39.35 mins    0.00 millis   39.35 mins

But the sectors are non readable:

# dd if=/dev/da0 of=/tmp/8sects.bin bs=512 count=8 skip=11475952568
dd: /dev/da0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 0.053658 secs (0 bytes/sec)

What I am missing ?
Regards.
--
Maurizio

 

[SirDice]

What I am missing ?

If they are pending then they failed to write to disk.

197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       192
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       192

It simply means the disk ran out of spare space to map bad blocks, and it's time to replace it.

 

[emmex]

The disk has pending sectors:

# smartctl -x -d sat /dev/da0 | grep -A 1 "Current_Pending_Sector"
197 Current_Pending_Sector  -O--C-   100   100   000    -    24
198 Offline_Uncorrectable   ----C-   100   100   000    -    24

But a lot of space for them:

# smartctl -x -d sat /dev/da0 | grep "Reallocated_Sector_Ct"
  5 Reallocated_Sector_Ct   PO--CK   099   099   010    -    2512

I want only write to these pending sectors.

 

[SirDice]

Offline uncorrectable means your spare bit of space is already filled up.

But a lot of space for them:

That's the number of bad sectors it successfully remapped, not the amount you have left.

Self-Monitoring, Analysis and Reporting Technology - Wikipedia

en.wikipedia.org

Count of reallocated sectors. The raw value represents a count of the bad sectors that have been found and remapped.[32] Thus, the higher the attribute value, the more sectors the drive has had to reallocate. This value is primarily used as a metric of the life expectancy of the drive; a drive which has had any reallocations at all is significantly more likely to fail in the immediate months.[29][33] If Raw value of 0x05 attribute is higher than its Threshold value, that will reported as "drive warning".[34]

 

[emmex]

On this drive there is a lot of space for reallocated sectors count:

# smartctl -x -d sat /dev/da0 | grep -A 5 "SMART Attribute"
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
.
.
  5 Reallocated_Sector_Ct   PO--CK   099   099   010    -    2512

The value of Reallocated Sector Count is 99 and the trash is 10, there is a lot of space for the reallocated sectors.
The ZFS pool is reliable only in a redundancy configuration:

# zpool status -v zusb
  pool: zusb
 state: ONLINE
  scan: scrub repaired 1.99M in 12:22:36 with 0 errors on Sat Feb 24 19:33:31 2024
config:

        NAME               STATE     READ WRITE CKSUM
        zusb               ONLINE       0     0     0
          mirror-0         ONLINE       0     0     0
            gpt/zusb.eli   ONLINE       0     0     0
            gpt/zusb2.eli  ONLINE       0     0     0

errors: No known data errors

The Seagate disk with reallocated sectors is gpt/zusb.eli.

 

[SirDice]

The value of Reallocated Sector Count is 99 and the trash is 10, there is a lot of space for the reallocated sectors.

Look at the raw value. Besides that, 10 is the threshold, the value is 99. That's almost an order of magnitude over the warning threshold. You've had a total of 2512 remapped sectors. And because pending and offline uncorrectable are both >0 it means your spare bit of space is full.

The Seagate disk with reallocated sectors is gpt/zusb.eli.

geli(8) will be getting read and/or decoding errors, those are shielded from ZFS because ZFS doesn't "see" the drive, it sees the geli(8) layer.

Your drive needs replacing. And judging by the 7477 hours, it's less than a year old? If so it's probably still in warranty.

 

[emmex]

Your drive needs replacing. And judging by the 7477 hours, it's less than a year old? If so it's probably still in warranty.

Unfortunately the drive is used for a weekly backup and is not in warranty. The drive has a lot of space for the Reallocated Sectors.
After a scrub:

# zpool scrub zusb
# zpool status -v zusb
  pool: zusb
 state: ONLINE
  scan: scrub repaired 0B in 1 days 11:27:18 with 0 errors on Wed Mar 20 03:48:27 2024
config:

        NAME               STATE     READ WRITE CKSUM
        zusb               ONLINE       0     0     0
          mirror-0         ONLINE       0     0     0
            gpt/zusb.eli   ONLINE       0     0     0
            gpt/zusb2.eli  ONLINE       0     0     0

errors: No known data errors

the Pending Sectors and the Offline Uncorrectable sectors are gone away and the Offline Uncorrectable Sectors is increased form 2512 to 2552.

geli(8) will be getting read and/or decoding errors, those are shielded from ZFS because ZFS doesn't "see" the drive, it sees the geli(8) layer.

I am using geli(8)() with ZFS from years without problem.

I want only to know why the 'zpool scrub' command is able to write the Pending Sectors on this disk, but the 'dd' command not.

 

[sko]

Unfortunately the drive is used for a weekly backup and is not in warranty. The drive has a lot of space for the Reallocated Sectors.

With failing sector counts ramping up at that nubers, this drive should no longer be used for anything, especially not backups. This drive is dead, it's passed on, it's no more, bereft of life. it's an ex-drive...

 

[Andriy]

dd of=/dev/da0 if=/dev/zero bs=512 count=8 skip=11475952568

I think that this is not what you wanted to do. Seeking in /dev/zero doesn't give you much, you are still reading zeros.
It might help to re-read dd(1) and to use iseek / oseek instead of skip / seek to never get confused again.

 

[emmex]

I think that this is not what you wanted to do. Seeking in /dev/zero doesn't give you much, you are still reading zeros.
It might help to re-read dd(1) and to use iseek / oseek instead of skip / seek to never get confused again.

Thank you very much, this is the answer I want. The next time I will have some reallocated sectors, on this disk, I will try iseek/oseek.

 

[PMc]

Ah, Andriy got to the point! You hosed the dd command (and killed the partition label of the drive in the process).
It needs to be seek=11475952568, not skip=11475952568
From dd manpage:

seek=n Seek n blocks from the beginning of the output before copying.
skip=n Skip n blocks from the beginning of the input before copying.

So what you did is seek the input (which is pointless on /dev/zero) and write the output from sector 0 - which means your first sectors on the disk are now overwritten with zeros.

Otherwise, these disks have lots and lots of replacement sectors: the "Reallocated_Sector_Ct" went from 100 to 099, so there is just ~1% of them used.
If we would want to use a drive that creates lots of defective sectors, that is yet a different question - that depends on usecase and mentality...

 

[Kaleron]

This disk is SMR. You didn't even indicate its model, but with this capacity I see no reason to question your own words. In the case of SMR disks, you lose free access to sectors when writing. Therefore, sectors are written first to the Media Cache and only then to the appropriate SMR zones. The subsystem of LBA to physical addressing translation in the case of SMR disks is more complex than in the case of classic models. Therefore, a firmware problem cannot be ruled out. Additionally, the surface may be more degraded than SMART indicates. SMART is a very unreliable diagnostic instrument. In this case you should do a full surface scan at MHDD or Victoria. How does the disk behave with other write attempts? Are other sectors saved correctly?

 

[PMc]

In this case you should do a full surface scan at MHDD or Victoria.

These do not run on our computers. That's for stupid people using windows.
We do suface analysis with native commands; we were doing it long before windows even existed.

 

[emmex]

So what you did is seek the input (which is pointless on /dev/zero) and write the output from sector 0 - which means your first sectors on the disk are now overwritten with zeros.

With the command:

# dd of=/dev/da0 if=/dev/zero bs=512 count=8 skip=11475952568

I am trying to write 8 sectors form 11475952568, the command doesn't write sector 0.

Otherwise, these disks have lots and lots of replacement sectors: the "Reallocated_Sector_Ct" went from 100 to 099, so there is just ~1% of them used.
If we would want to use a drive that creates lots of defective sectors, that is yet a different question - that depends on usecase and mentality...

This is a my disk If it was a customer disc I would have replaced it.

 

[emmex]

This disk is SMR. You didn't even indicate its model,

Sorry, in the attachment of my message #7 you can read the model.

 

[PMc]

With the command:

# dd of=/dev/da0 if=/dev/zero bs=512 count=8 skip=11475952568

I am trying to write 8 sectors form 11475952568, the command doesn't write sector 0.

No, You skip 11475952568 sectors from the input, then read 8 and write them to the disk (from the beginning of the disk)
At least You should notice that your cpu is quite busy creating all these 11475952568 blocks.

 

[emmex]

In this case you should do a full surface scan at MHDD or Victoria.

In Windows I have used Victoria and it works very well. Thank you.

 

[emmex]

Solved using the -oseek parameter in the dd command.
The command:

# dd if=/dev/zero of=/dev/da0 bs=512 count=8 oseek=11501506360
8+0 records in 
8+0 records out
4096 bytes transferred in 0.243538 secs (16819 bytes/sec)

writes the pending sectors and works as expected.

 

[bgavin]

OP, you might consider obtaining the Seagate SEA tools as a bootable media, then testing your device.
You can also low level format your device just to be sure.

In my business practice, nearly all the disk failures I see are consumer-grade Seagate drives.
The data at backblaze.com indicates the Seagate premium drives have a lesser failure rate than Western Digital.
I place WD in customer environments because in my experience I get extremely low failure rates on drives with less than 27,000 hours.

I did take a risk and bought a pair of Seagate Ironwolf Pro 18tb drives, and a 3rd WD Red PRO 18tb for a RAIDZ-1 new project.
The Ironwolf come with a 5 year warranty, which tells me Seagate is serious about the reliability of these drives, vs the consumer grade junk.

 

[Alain De Vos]

I never had a spinning WD drive dying. I had an SSD drive dying the hard way. All data lost! Now I use the SSD drive only to boot & swap & ZFS special/log/cache device because of it's speed.

 

[homeadm]

These do not run on our computers. That's for stupid people using windows.
We do suface analysis with native commands

Stupid is the last word you should use. Although amateurs can also use these programs, there is no better way to check health of a HDD, than to verify access time to each sector. No Unix tool can do this, neither - afaik - BSD nor Linux.

I test each new drive with Victoria under Windows, before mounting it in Unix machine. Later, you only have smartctl, format/analyze and dd.

 

[PMc]

Stupid is the last word you should use. Although amateurs can also use these programs, there is no better way to check health of a HDD, than to verify access time to each sector. No Unix tool can do this, neither - afaik - BSD nor Linux.

They send me PICTURES of the smart data because they have no idea how to read anything as text - probably they not even know how to use a keyboard...

I test each new drive with Victoria under Windows, before mounting it in Unix machine. Later, you only have smartctl, format/analyze and dd.

Unbelievable... Sure, on Unix you "only" have the raw ATAcommand interface, i.e. absolutely everything that ever can be sent to the drive (including vendor specifics). And if you can't code, you could just run them from the commandline via camcontrol cmd
.

 

[homeadm]

Really? can you scan hard drive in FreeBSD, and create a log with access times (in milliseconds) to each sector on the drive, one by one? Impressive, it's impossible in my Solaris.

 

[PMc]

Really? can you scan hard drive in FreeBSD, and create a log with access times (in milliseconds) to each sector on the drive, one by one? Impressive, it's impossible in my Solaris.

I definitely could arrange for that if I had any use for such a log. I don't need such to understand my malfunctioning drives, and I'm not sure if Solaris would deliver with full sources.

 

[emmex]

With this drive I have learned two things:

• Never use a disk without redundancy
• I don't worry too much about pending sectors on a disk