I mean use badblocks either directly or through the -c option of mkfs
and similar commands.

My understanding is that , if a sector of a drive seems to go bad , the drive
software automatically "remaps" it (or whatever the appropriate verb is) to
a different sector so does running badblocks actually buy you anything ?

Is badblocks only intended for hard drives or is it also potentially useful
for solid state drives ?

If you use badblocks , do you do a read-write test or just read ? Some months
ago I did with a new 128 gigabytes SSD

mkfs.ext3 -c -c -j /dev/sdc1

and it was taking forever. After several days during which progress seemed to
be slowing down (based on the progress percentages printed by the programme)
I stopped it and did a read only test which worked fine.

--
Be bold , verb a noun today.

Spiros Bousbouras wrote:

> I mean use badblocks either directly or through the -c option of mkfs
> and similar commands.
>
> My understanding is that , if a sector of a drive seems to go bad , the drive
> software automatically "remaps" it (or whatever the appropriate verb is) to
> a different sector so does running badblocks actually buy you anything ?

I presume your disc isn't so old that it comes with a separate print-out
of the bad sector numbers?

> Is badblocks only intended for hard drives or is it also potentially useful
> for solid state drives ?

I would just leave the spare block management to the controller onboard
the SSD, it'll understand at a lower level what is going on

> If you use badblocks , do you do a read-write test or just read ? Some months
> ago I did with a new 128 gigabytes SSD
>
> mkfs.ext3 -c -c -j /dev/sdc1
>
> and it was taking forever. After several days during which progress seemed to
> be slowing down (based on the progress percentages printed by the programme)
> I stopped it and did a read only test which worked fine.

I should think that all that any write tests would achieve is using up
the write-cycles of the SSD :-(

On 02/12/2023 13:06, Andy Burns wrote:
>> Some months
>> ago I did with a new 128 gigabytes SSD
>>
>>      mkfs.ext3 -c -c -j /dev/sdc1
>>
>> and it was taking forever. After several days during which progress
>> seemed to
>> be slowing down (based on the progress percentages printed by the
>> programme)
>> I stopped it and did a read only test which worked fine.
>
> I should think that all that any write tests would achieve is using up
> the write-cycles of the SSD 🙁

Indeed.

--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:

> My understanding is that , if a sector of a drive seems to go bad ,
> the drive software automatically "remaps" it (or whatever the
> appropriate verb is) to a different sector so does running badblocks
> actually buy you anything ?

That applies to HDDs, but mostly not to floppies, USB thumb drives nor
tapes.

The amount of reserve sectors is also limited, so if too many are bad,
they can't be remapped and badblocks will find them.

On Sat, 2 Dec 2023 14:51:37 +0100
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>
> > My understanding is that , if a sector of a drive seems to go bad ,
> > the drive software automatically "remaps" it (or whatever the
> > appropriate verb is) to a different sector so does running badblocks
> > actually buy you anything ?
>
> That applies to HDDs, but mostly not to floppies, USB thumb drives nor
> tapes.
>
> The amount of reserve sectors is also limited, so if too many are bad,
> they can't be remapped and badblocks will find them.

And how is that useful ? badblocks itself simply prints the list of bad
blocks to stdout. Is this useful ? If you invoke badblocks indirectly
by using one of the mkfs* utilities then I assume what happens is that
the list of bad blocks will be written at an appropriate location on the
filesystem so that the operating system can avoid writing on those blocks.
Do I have this right ?

I was also wondering , would it be possible for the operating system to write
some data and then immediately read it back to make sure that it was written
correctly ? The advantage relative to using badblocks is that with
badblocks some blocks may become bad after you have run badblocks whereas
with the method I'm proposing the checks would be ongoing. Obviously what I'm
suggesting would negatively affect performance but it could be tunable ; like
you could have an option for mounting a filesystem with such a functionality
enabled or not. Does such a functionality exist all on Linux (with some types
of filesystems) ?

--
- Do you read Sutter Cane ?
- Wh... what ?
- Do they speak English in "what" ?

On Sat, 2 Dec 2023 13:06:03 +0000
Andy Burns <usenet@andyburns.uk> wrote:
> Spiros Bousbouras wrote:
>
> > I mean use badblocks either directly or through the -c option of mkfs
> > and similar commands.
> >
> > My understanding is that , if a sector of a drive seems to go bad , the drive
> > software automatically "remaps" it (or whatever the appropriate verb is) to
> > a different sector so does running badblocks actually buy you anything ?
>
>
> I presume your disc isn't so old that it comes with a separate print-out
> of the bad sector numbers?

No it isn't.

> > Is badblocks only intended for hard drives or is it also potentially useful
> > for solid state drives ?
>
> I would just leave the spare block management to the controller onboard
> the SSD, it'll understand at a lower level what is going on

And this isn't the case with other kinds of storage devices ?

> > If you use badblocks , do you do a read-write test or just read ? Some months
> > ago I did with a new 128 gigabytes SSD
> >
> > mkfs.ext3 -c -c -j /dev/sdc1
> >
> > and it was taking forever. After several days during which progress seemed to
> > be slowing down (based on the progress percentages printed by the programme)
> > I stopped it and did a read only test which worked fine.
>
> I should think that all that any write tests would achieve is using up
> the write-cycles of the SSD :-(

What is the difference with hard disks ? Is it for example that a new SSD is
guaranteed to initially write everything correctly so running badblocks is
a waste whereas even a new hard disk may have blocks where writing won't
work ?

Spiros Bousbouras wrote:

> What is the difference with hard disks ? Is it for example that a new SSD is
> guaranteed to initially write everything correctly so running badblocks is
> a waste whereas even a new hard disk may have blocks where writing won't
> work ?

I don't suppose any storage device guarantees all sectors are writeable
out of the box, they just hope to have enough spares to cope, but who
knows what damage it might take in transit if you're unlucky?

Probably hard discs and SSDs tell so many lies to the operating system,
that trying to outsmart the manufacturer isn't a game worth playing?

Spiros Bousbouras <spibou@gmail.com> wrote:
> I mean use badblocks either directly or through the -c option of
> mkfs and similar commands.

Yes to both (although not frequently).

> My understanding is that, if a sector of a drive seems to go bad, the
> drive software automatically "remaps" it (or whatever the appropriate
> verb is) to a different sector

That depends on the drive controller. Most do so (at least most more
modern disks do) but your mileage may vary if you have a large enough
set of different devices. Note here by "devices" I'm including USB
thumb drives (which vary wildly in quality and reliability).

> so does running badblocks actually buy you anything ?

That depends upon /why/ you want to run it, and what you are running it
upon.

> Is badblocks only intended for hard drives or is it also
> potentially useful for solid state drives ?

The 'badblocks' command is used to scan Linux block devices, so the
'intended' use is to scan "block devices". Whether it is useful
against whatever hardware is backing the Linux block device is a
different question.

> If you use badblocks , do you do a read-write test or just read ?

I've done both in the past. Although I've used read-only scans far
more often than read-write scans.

> Some months ago I did with a new 128 gigabytes SSD
>
> mkfs.ext3 -c -c -j /dev/sdc1
>
> and it was taking forever. After several days during which progress
> seemed to be slowing down (based on the progress percentages printed
> by the programme) I stopped it and did a read only test which worked
> fine.

Yes, 128G read/write will take some time, and when you cause the SSD to
run out of spare clean chunks of flash, you get to wait through while
it cleans up flash chunks before further writes occur.

And, you consume write cycles on the flash, which for an SSD is
directly correlated with eventual failure.

Here are the scenarios where I've used badblocks:

1) I have a stack of old drives pulled from various machines over time
(could be spinning rust, could be SSD) but I don't know which are good
vs. bad. So I hook each up (a USB to disk adapter works well here)
and run a badblocks read-only scan on the device. If badblocks throws
errors I know to "recycle" that piece of hardware. If it completes
without error then I know that "drive" at least worked to read the
whole disk.

2) I have a disk in a machine that starts to throw read errors in a few
spots in the kernel logs. And I don't have a spare to replace it with
just yet. Unmounnt, run badblocks (via a fsck.ext? scan, usually in
read-only mode) against the partition to let the filesystem map out the
bad sectors and hopefully "get by" on the remainder of the disk until a
replacement disk can be purchased. Doing this can also give a 'clue'
as to how close to failure a disk is. If the number of bad blocks
remains steady after mapping them away, one likely has more time than
if the number of bad blocks continues to grow over time.

Only a handful of times (i.e., five or fewer) have I done a read/write
badblocks scan in this scenario. I wanted to see if a write to the bad
sectors would cause the controller to remap the sector to a spare. If
I remember right, overwriting them didn't help any.

3) You have a brand new, fresh from the factory, just opened, disk, and
you want to give it a little bit of "burn-in testing" to see if it will
be one of the small percentage that fail soon after use. If the disk
is spinning rust, then a badblocks read-write scan will both burn-in
test the disk by stressing it, and let you verify there are no bad
sectors direct from the factory. If the disk is SSD, better to just do
a read-only test rather than starting out by write wearing every flash
block in the drive.

4) You want to periodically scan your active disks looking for bad
sectors to catch disk failures early, while there still may be time to
obtain, copy to, and install a replacement. So you setup a cron job to
every so often run a read-only badblocks against each disk and compare
the output to the previous run against that same disk. No new bad
sectors, nothing to worry about. A new bad sector appears, well, maybe
it is time to start planning for the eventual replacement of that disk
in the near future.

Note, in any case, having a proper system of backups is necessary, even
if you use badblocks to look for and catch possible failures early
before they become outright failures.

Spiros Bousbouras <spibou@gmail.com> wrote:
> On Sat, 2 Dec 2023 14:51:37 +0100
> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>>
>> > My understanding is that , if a sector of a drive seems to go bad ,
>> > the drive software automatically "remaps" it (or whatever the
>> > appropriate verb is) to a different sector so does running badblocks
>> > actually buy you anything ?
>>
>> That applies to HDDs, but mostly not to floppies, USB thumb drives nor
>> tapes.
>>
>> The amount of reserve sectors is also limited, so if too many are bad,
>> they can't be remapped and badblocks will find them.
>
> And how is that useful ? badblocks itself simply prints the list of bad
> blocks to stdout. Is this useful?

Yes. If you are running it from one of the fsck.ext? programs, then
that "print list to stdout" goes to fsck.ext? and is used to update the
filesystem badblock list. Which then means the filesystem will skip
using those blocks, because they are marked bad.

If you are running it yourself, then this gives you a count of the
number of bad blocks, which is information you might find useful in
evaluating how much life the disk may have left.

> If you invoke badblocks indirectly by using one of the mkfs*
> utilities then I assume what happens is that the list of bad blocks
> will be written at an appropriate location on the filesystem so that
> the operating system can avoid writing on those blocks. Do I have
> this right ?

Almost. So the *filesystem* can avoid writing to those blocks.

> I was also wondering , would it be possible for the operating system
> to write some data and then immediately read it back to make sure
> that it was written correctly?

Possible in general: yes. In fact, the ancient Atari DOS for the very
old Atari 810 5.25 floppy disk, if set to do so, would do exactly this.
Write a sector, then immediately read it back and compare. Of course
doing so slowed down disk writes by a considerable amount (and they
were not anywhere near fast by today's standards to begin with).

Can Linux be configured to do so, not unless one of the more esoteric
filesystems has a "read after write" configuration option.

> The advantage relative to using badblocks is that with badblocks some
> blocks may become bad after you have run badblocks whereas with the
> method I'm proposing the checks would be ongoing.

And your write speed would slow down to one disk block per disk platter
rotation (or set of blocks, depending upon how it was implemented).
For most users, the overall reliability is already sufficiently high
enough that slowing down writes by 50x or 100x is not worth the
fractional percentage gain in overall reliability.

> Obviously what I'm suggesting would negatively affect performance but
> it could be tunable ; like you could have an option for mounting a
> filesystem with such a functionality enabled or not. Does such a
> functionality exist all on Linux (with some types of filesystems) ?

It might. I do not know of any that have it, but I also do not know
the details of all the possible filesystems that are bundled with (or
can be added to) a Linux kernel.

On 2023-12-02 07:44, Spiros Bousbouras wrote:
> I mean use badblocks either directly or through the -c option of mkfs
> and similar commands.
>
> My understanding is that , if a sector of a drive seems to go bad , the drive
> software automatically "remaps" it (or whatever the appropriate verb is) to
> a different sector so does running badblocks actually buy you anything ?

Badblocks is a leftover from a bygone era.

For the last 30 years or so hard drives have had spare sectors and
remapped bad ones to good ones, transparently to the end-user. Just
like you said.

Before that time (1980s and earlier, really) that wasn't the case. As
another poster alluded to, hard drives of that era would come with a
piece of paper listing the known bad blocks from manufacturing defects,
with space for you to write in additional entries as you found them.
That list could then be used when creating a filesystem (e.g., see the
-l option to mke2fs) so that the filesystem would not use those known
bad blocks.

But none of that is necessary on modern hard drives or SSDs with
hardware-level sector remapping. If you see a bad block on one of
those, it's a sign you've already exhausted all of the spare sectors on
it. Most people would replace the drive long before that happened,
usually as soon as SMART starts showing any remapped sectors.

Plus, defect rates on today's equipment are several orders of magnitude
lower than they were when the badblocks utility was needed. Back then,
it was assumed that every disk would have a few defects.

Today's drives are also vastly cheaper, so it is viable to just replace
ones showing bad blocks rather than needing to extend their lives by
working around defects.

On 2023-12-02 21:32, Rich wrote:
> Spiros Bousbouras <spibou@gmail.com> wrote:
>> On Sat, 2 Dec 2023 14:51:37 +0100
>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:

....

>> I was also wondering , would it be possible for the operating system
>> to write some data and then immediately read it back to make sure
>> that it was written correctly?
>
> Possible in general: yes. In fact, the ancient Atari DOS for the very
> old Atari 810 5.25 floppy disk, if set to do so, would do exactly this.
> Write a sector, then immediately read it back and compare. Of course
> doing so slowed down disk writes by a considerable amount (and they
> were not anywhere near fast by today's standards to begin with).
>
> Can Linux be configured to do so, not unless one of the more esoteric
> filesystems has a "read after write" configuration option.

Better software verified a track after writing it, not a sector.
Minimize movements.

>
>> The advantage relative to using badblocks is that with badblocks some
>> blocks may become bad after you have run badblocks whereas with the
>> method I'm proposing the checks would be ongoing.
>
> And your write speed would slow down to one disk block per disk platter
> rotation (or set of blocks, depending upon how it was implemented).
> For most users, the overall reliability is already sufficiently high
> enough that slowing down writes by 50x or 100x is not worth the
> fractional percentage gain in overall reliability.

MsDOS could do exactly this. The setting was "VERIFY=ON".

>> Obviously what I'm suggesting would negatively affect performance but
>> it could be tunable ; like you could have an option for mounting a
>> filesystem with such a functionality enabled or not. Does such a
>> functionality exist all on Linux (with some types of filesystems) ?
>
> It might. I do not know of any that have it, but I also do not know
> the details of all the possible filesystems that are bundled with (or
> can be added to) a Linux kernel.

I don't remember seeing it.

--
Cheers,
Carlos E.R.

On 2023-12-02 13:44, Spiros Bousbouras wrote:
> I mean use badblocks either directly or through the -c option of mkfs
> and similar commands.

No.

> My understanding is that , if a sector of a drive seems to go bad , the drive
> software automatically "remaps" it (or whatever the appropriate verb is) to
> a different sector so does running badblocks actually buy you anything ?

Yes, but remapping only happens during write operations.

>
> Is badblocks only intended for hard drives or is it also potentially useful
> for solid state drives ?

It was intended for ancient drives, before drives had automatic remapping.

>
> If you use badblocks , do you do a read-write test or just read ? Some months
> ago I did with a new 128 gigabytes SSD
>
> mkfs.ext3 -c -c -j /dev/sdc1
>
> and it was taking forever. After several days during which progress seemed to
> be slowing down (based on the progress percentages printed by the programme)
> I stopped it and did a read only test which worked fine.

Notice that the real test is writing, your disk could be very faulty if
you only do a read test.

When a disk is suspect, first I do a SMART parameters read, then I do
the long test, and possibly, I then write zeroes to the entire disk, and
another long test. Then I check whether the remapped sector count has
increased. If it did, I discard the disk.

--
Cheers,
Carlos E.R.

On 2023-12-02, Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2023-12-02 21:32, Rich wrote:
>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>> On Sat, 2 Dec 2023 14:51:37 +0100
>>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>
> ...
>
>>> I was also wondering , would it be possible for the operating system
>>> to write some data and then immediately read it back to make sure
>>> that it was written correctly?
>>
>> Possible in general: yes. In fact, the ancient Atari DOS for the very
>> old Atari 810 5.25 floppy disk, if set to do so, would do exactly this.
>> Write a sector, then immediately read it back and compare. Of course
>> doing so slowed down disk writes by a considerable amount (and they
>> were not anywhere near fast by today's standards to begin with).
>>
>> Can Linux be configured to do so, not unless one of the more esoteric
>> filesystems has a "read after write" configuration option.
>
> Better software verified a track after writing it, not a sector.
> Minimize movements.
>
>
>>
>>> The advantage relative to using badblocks is that with badblocks some
>>> blocks may become bad after you have run badblocks whereas with the
>>> method I'm proposing the checks would be ongoing.
>>
>> And your write speed would slow down to one disk block per disk platter
>> rotation (or set of blocks, depending upon how it was implemented).
>> For most users, the overall reliability is already sufficiently high
>> enough that slowing down writes by 50x or 100x is not worth the
>> fractional percentage gain in overall reliability.
>
> MsDOS could do exactly this. The setting was "VERIFY=ON".

About 40 years ago, I saw that functionality described in some
VMS documentation. However, I don't remember now whether it was
on a per-file basis, per-open-for-write basis, or other.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2023-12-02 21:32, Rich wrote:
>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>> On Sat, 2 Dec 2023 14:51:37 +0100
>>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>
> ...
>
>>> I was also wondering , would it be possible for the operating system
>>> to write some data and then immediately read it back to make sure
>>> that it was written correctly?
>>
>> Possible in general: yes. In fact, the ancient Atari DOS for the
>> very old Atari 810 5.25 floppy disk, if set to do so, would do
>> exactly this. Write a sector, then immediately read it back and
>> compare. Of course doing so slowed down disk writes by a
>> considerable amount (and they were not anywhere near fast by today's
>> standards to begin with).
>>
>> Can Linux be configured to do so, not unless one of the more
>> esoteric filesystems has a "read after write" configuration option.
>
> Better software verified a track after writing it, not a sector.
> Minimize movements.

This was on an 8-bit, 6502 computer, with single density, single sided
5.25 floppy disks that held 90KB each. A computer that, in its
smallest configuration, came with either 8k or 16k of RAM (I forget
which was the minimal config now). I doubt the authors of Atari DOS
were thinking that buffering a track worth of data in that environment
was worthwhile.

As well, re-reading the same sector that was just written requires no
head movement. But it does force the disk to wait for the sector to
rotate around to the head again. So one gets to write at a maximum
speed of one disk sector every two disk rotations.

On 02/12/2023 17:24, David W. Hodgins wrote:
> Don't use badblocks on ssd drives.

Indeed. Moist of these low level storage control tools are now
replicated inside the SSD controller itself (e.g. badblocks), or are
rendered unnecessary by the actual storage architecture( defragmentation)

If there is a bad ram block, the SSD controller itself will have flagged
that already.
With read/write seek times being essentially zero, there is no point in
defragmenting at the computer level. The wear levelling will already be
rearranging where everything is stored anyway.

The only thing the SSD needs is a trim command now and then.

--
“Some people like to travel by train because it combines the slowness of
a car with the cramped public exposure of 
an airplane.”

Dennis Miller

Spiros Bousbouras <spibou@gmail.com> writes:
> I mean use badblocks either directly or through the -c option of mkfs
> and similar commands.
>
> My understanding is that , if a sector of a drive seems to go bad ,
> the drive software automatically "remaps" it (or whatever the
> appropriate verb is) to a different sector

Yes.

> so does running badblocks actually buy you anything ?

No. Waste of time.

> Is badblocks only intended for hard drives or is it also potentially useful
> for solid state drives ?

Neither. Medium error management moved inside the drives decades ago.

--
https://www.greenend.org.uk/rjk/

On 2023-12-02, Rich wrote:

[...]
> Here are the scenarios where I've used badblocks:
>
> 1) I have a stack of old drives pulled from various machines over time
> (could be spinning rust, could be SSD) but I don't know which are good
> vs. bad. So I hook each up (a USB to disk adapter works well here)
> and run a badblocks read-only scan on the device.
[...]

Does anyone have advice on choosing SATA* USB adapters for disk drives?
I've once tried one which I couldn't use as it would not give access to
all blocks (it subtracted two blocks or something like that?).

* Although in the future I should probably get a PATA one too, for
easier checking of older drives.

--
Nuno Silva

On 2023-12-03 05:16, Robert Riches wrote:
> On 2023-12-02, Carlos E. R. <robin_listas@es.invalid> wrote:
>> On 2023-12-02 21:32, Rich wrote:
>>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>>> On Sat, 2 Dec 2023 14:51:37 +0100
>>>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>>
>> ...
>>

>>>> The advantage relative to using badblocks is that with badblocks some
>>>> blocks may become bad after you have run badblocks whereas with the
>>>> method I'm proposing the checks would be ongoing.
>>>
>>> And your write speed would slow down to one disk block per disk platter
>>> rotation (or set of blocks, depending upon how it was implemented).
>>> For most users, the overall reliability is already sufficiently high
>>> enough that slowing down writes by 50x or 100x is not worth the
>>> fractional percentage gain in overall reliability.
>>
>> MsDOS could do exactly this. The setting was "VERIFY=ON".
>
> About 40 years ago, I saw that functionality described in some
> VMS documentation. However, I don't remember now whether it was
> on a per-file basis, per-open-for-write basis, or other.

It was a setting that applied to programs started after setting it,
AFAIR. It was usually done in autoexec.bat, IIRC.

--
Cheers,
Carlos E.R.

Nuno Silva wrote:

> Does anyone have advice on choosing SATA* USB adapters for disk drives?

The ones I've had which support UASP seem better in general ... maybe
every manufacturer supports it now and it's no longer an indication of a
"good" adapter?

On 2023-12-03 07:15, Rich wrote:
> Carlos E. R. <robin_listas@es.invalid> wrote:
>> On 2023-12-02 21:32, Rich wrote:
>>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>>> On Sat, 2 Dec 2023 14:51:37 +0100
>>>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>>> Am 02.12.2023 um 12:44:46 Uhr schrieb Spiros Bousbouras:
>>
>> ...
>>
>>>> I was also wondering , would it be possible for the operating system
>>>> to write some data and then immediately read it back to make sure
>>>> that it was written correctly?
>>>
>>> Possible in general: yes. In fact, the ancient Atari DOS for the
>>> very old Atari 810 5.25 floppy disk, if set to do so, would do
>>> exactly this. Write a sector, then immediately read it back and
>>> compare. Of course doing so slowed down disk writes by a
>>> considerable amount (and they were not anywhere near fast by today's
>>> standards to begin with).
>>>
>>> Can Linux be configured to do so, not unless one of the more
>>> esoteric filesystems has a "read after write" configuration option.
>>
>> Better software verified a track after writing it, not a sector.
>> Minimize movements.
>
> This was on an 8-bit, 6502 computer, with single density, single sided
> 5.25 floppy disks that held 90KB each. A computer that, in its
> smallest configuration, came with either 8k or 16k of RAM (I forget
> which was the minimal config now). I doubt the authors of Atari DOS
> were thinking that buffering a track worth of data in that environment
> was worthwhile.
>
> As well, re-reading the same sector that was just written requires no
> head movement. But it does force the disk to wait for the sector to
> rotate around to the head again. So one gets to write at a maximum
> speed of one disk sector every two disk rotations.

Aye. Movements ;-)

--
Cheers,
Carlos E.R.

On 03/12/2023 12:00, Nuno Silva wrote:
> On 2023-12-02, Rich wrote:
>
> [...]
>> Here are the scenarios where I've used badblocks:
>>
>> 1) I have a stack of old drives pulled from various machines over time
>> (could be spinning rust, could be SSD) but I don't know which are good
>> vs. bad. So I hook each up (a USB to disk adapter works well here)
>> and run a badblocks read-only scan on the device.
> [...]
>
> Does anyone have advice on choosing SATA* USB adapters for disk drives?
> I've once tried one which I couldn't use as it would not give access to
> all blocks (it subtracted two blocks or something like that?).
>
Some limited observations.

Power for full size disk drives cannot be reliably supplied by
USB<->SATA adapters alone. You need a powered hub of some sort. 2.5" and
SSDs however are possible.

I am using these, with no issues.

https://thepihut.com/products/ssd-to-usb-3-0-cable-for-raspberry-pi

In both cases 'df' reports somewhat less formatted capacity than the
drive says is available.

$df -h | grep sdb

/dev/sdb2 110G 3.0G 102G 3% /
/dev/sdb1 510M 61M 450M 12% /boot

That should be 120GB SSD

$ df -h | grep sda

/dev/sda1 219G 178G 30G 86% /home
/dev/sda2 1.6T 1.3T 302G 81% /home/Media
That should be 2TB

It may well be that a USB interface has a different granularity from
SATA and some space will not be available, but I doubt that is a
function of the interface cable.

> * Although in the future I should probably get a PATA one too, for
> easier checking of older drives.
>

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

The Natural Philosopher wrote:

> In both cases 'df' reports somewhat less formatted capacity than the
> drive says is available.
>
> $df -h | grep sdb
>
> /dev/sdb2       110G  3.0G  102G   3% /
> /dev/sdb1       510M   61M  450M  12% /boot
>
> That should be 120GB SSD
>
> $ df -h | grep sda
>
> /dev/sda1       219G  178G   30G  86% /home
> /dev/sda2       1.6T  1.3T  302G  81% /home/Media
> That should be 2TB

What about df -H instead of df -h ?

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 03/12/2023 12:00, Nuno Silva wrote:
>> On 2023-12-02, Rich wrote:
>>
>> [...]
>>> Here are the scenarios where I've used badblocks:
>>>
>>> 1) I have a stack of old drives pulled from various machines over time
>>> (could be spinning rust, could be SSD) but I don't know which are good
>>> vs. bad. So I hook each up (a USB to disk adapter works well here)
>>> and run a badblocks read-only scan on the device.
>> [...]
>>
>> Does anyone have advice on choosing SATA* USB adapters for disk drives?
>> I've once tried one which I couldn't use as it would not give access to
>> all blocks (it subtracted two blocks or something like that?).
>>
> Some limited observations.
>
> Power for full size disk drives cannot be reliably supplied by
> USB<->SATA adapters alone. You need a powered hub of some sort. 2.5" and
> SSDs however are possible.

True, which is why if one is obtaining such an interface for testing
various disks for "is it dead or not" that obtaining one similar to
this:
https://www.amazon.com/AGPtek-Drive-Adapter-Converter-External/dp/B00BIE996S

which includes an external power supply brick is a good idea.

> I am using these, with no issues.
>
> https://thepihut.com/products/ssd-to-usb-3-0-cable-for-raspberry-pi
>
> In both cases 'df' reports somewhat less formatted capacity than the
> drive says is available.
>
> $df -h | grep sdb
>
> /dev/sdb2 110G 3.0G 102G 3% /
> /dev/sdb1 510M 61M 450M 12% /boot
>
> That should be 120GB SSD

df reports "formatted" capacity (after partitioning and filesystem
creation). If you want to compare against what the drive reports, use
"blockdev --report". I.e. "blockdev --report /dev/sdb". Note that the
"size" is reported in bytes.

> $ df -h | grep sda
>
> It may well be that a USB interface has a different granularity from
> SATA and some space will not be available, but I doubt that is a
> function of the interface cable.

The total physically addressable sectors/blocks on the drive should be
identical regardless of the interface (for other that situations of
drives that are larger than the maximum a given interface can address).

The formatted capacity will always be smaller than the raw capacity due
to partition alignment offsets and filesystem metadata overhead.

On 2023-12-03 16:09, The Natural Philosopher wrote:
> On 03/12/2023 12:00, Nuno Silva wrote:
>> On 2023-12-02, Rich wrote:

....

> Some limited observations.
>
> Power for full size disk drives cannot be reliably supplied by
> USB<->SATA adapters alone. You need a powered hub of some sort. 2.5" and
> SSDs however are possible.
>
> I am using these, with no issues.
>
> https://thepihut.com/products/ssd-to-usb-3-0-cable-for-raspberry-pi

How about smartctl, does it fully work?

> In both cases 'df' reports somewhat less formatted capacity than the
> drive says is available.
>
> $df -h | grep sdb
>
> /dev/sdb2       110G  3.0G  102G   3% /
> /dev/sdb1       510M   61M  450M  12% /boot
>
> That should be 120GB SSD

df is reporting GiB, not GB.

110 GiB = 118 GB.

And then, there is the metadata. You have to use fdisk instead of df,
and pay attention to the different units.

>
> $ df -h | grep sda
>
> /dev/sda1       219G  178G   30G  86% /home
> /dev/sda2       1.6T  1.3T  302G  81% /home/Media
> That should be 2TB

2 TB = 1862 GiB, and then the metadata.

--
Cheers,
Carlos E.R.

On 03/12/2023 15:18, Andy Burns wrote:
> The Natural Philosopher wrote:
>
>> In both cases 'df' reports somewhat less formatted capacity than the
>> drive says is available.
>>
>> $df -h | grep sdb
>>
>> /dev/sdb2       110G  3.0G  102G   3% /
>> /dev/sdb1       510M   61M  450M  12% /boot
>>
>> That should be 120GB SSD
>>
>> $ df -h | grep sda
>>
>> /dev/sda1       219G  178G   30G  86% /home
>> /dev/sda2       1.6T  1.3T  302G  81% /home/Media
>> That should be 2TB
>
> What about df -H instead of df -h ?
>
>
>

/dev/sda1 236G 191G 33G 86% /home
/dev/sda2 1.8T 1.4T 324G 81% /home/Media

/dev/sdb2 118G 3.2G 110G 3% /
/dev/sdb1 535M 64M 472M 12% /boot

--
No Apple devices were knowingly used in the preparation of this post.