I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs are larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format it, keeping it as FAT32. After this the pc won't even try to boot. Setup shows the correct HDD is still flagged for first boot attempt, but nothing. It does its hardware checks, reports the HDDs then hangs.

Remove the new 500G and everything works again.

Er, what's going on?


NT

How did you gpart it and format it if the PC hangs at boot with the 500gb drive attached?

Out of date bios or whatever its called these days?
I've even had this happen with a particular ram stick in a usb on one
machine. Reason? Not the foggiest, it is fine in a newer pc.
Brian

--
----- --
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...

Blind user, so no pictures please
Note this Signature is meaningless.!
wrote in message
...
I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs are
larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format it,
keeping it as FAT32. After this the pc won't even try to boot. Setup shows
the correct HDD is still flagged for first boot attempt, but nothing. It
does its hardware checks, reports the HDDs then hangs.

Remove the new 500G and everything works again.

Er, what's going on?


NT

On 15/06/19 00:47, wrote:
I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs are larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format it, keeping it as FAT32. After this the pc won't even try to boot. Setup shows the correct HDD is still flagged for first boot attempt, but nothing. It does its hardware checks, reports the HDDs then hangs.

Remove the new 500G and everything works again.

Er, what's going on?

No idea. Can you put the 500G disk in a USB caddy, plug that into an
already-working Mint computer, run"Disks", and look at what it sees when
it interrogates the 500GB disk?

I've read somewhere that PVR HDs have a setup of their own -
particularly one which used to avoid error checking as it took too long
when writing to the disk. Does gparted get round this, or is it possibly
integral to the disk controller?

Anything of interest here?
https://www.pcreview.co.uk/threads/wd-av-drives-not-for-desktop-use.4037903/

--

Jeff

On Fri, 14 Jun 2019 23:47:10 -0700 (PDT), wrote:

How did you gpart it and format it if the PC hangs at boot with the 500gb drive attached?

Possibly, because before it was initialised it wasn't 'seen' by the
system as a potential boot / required drive?

Cheers, T i m

On 15/06/2019 00:47, wrote:
I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs are larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format it, keeping it as FAT32. After this the pc won't even try to boot. Setup shows the correct HDD is still flagged for first boot attempt, but nothing. It does its hardware checks, reports the HDDs then hangs.

Remove the new 500G and everything works again.

Er, what's going on?


You probably need to update grub, the system has changed ordering on
devices mounting them under different mount points. i.e sda, sdb... er
whatever is next (or before) in the list.

Before you trip down that rabbit hole, do a check with and without the
hard drive attached - boot from a live CD and check out the output from
'lsblk'.

Google has lots of guides to updating grub, but if you want a hand there
are peeps on uk.comp.os.linux or maybe alt.os.unix.mint (not looked
there, I'm on debian)

--
Adrian C

wrote

How did you gpart it and format it if the PC hangs at boot with the 500gb
drive attached?

It only hangs after that has been done.

Jeff Layman wrote:
I've read somewhere that PVR HDs have a setup of their own -
particularly one which used to avoid error checking as it took too long
when writing to the disk. Does gparted get round this, or is it possibly
integral to the disk controller?

It's inside the disc. gparted doesn't touch that, but it's only likely to
come into play if you are doing large amounts of writing - in the way that
a security camera does. Most of the time an AV drive will be fine, although
I would be wary about storing valuable data on it.

My guess would be the OP has formatted the HDD as bootable in some way that's
confusing the boot process.

If in doubt, a complete wipe (with dd or a similar tool) should erase any
partition tables on it, and then just make a new partition table from
scratch.

Theo

wrote in message
...

I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs are
larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format it,
keeping it as FAT32. After this the pc won't even try to boot. Setup shows
the correct HDD is still flagged for first boot attempt, but nothing. It
does its hardware checks, reports the HDDs then hangs.

Remove the new 500G and everything works again.

Er, what's going on?

https://www.instructables.com/id/Unl...BT-Vision-box/

HTH

--

On Sat, 15 Jun 2019 18:49:23 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:



It only hangs after that has been done.

Are we talking about your senile mind, senile Rodent?

--
about senile Rot Speed:
"This is like having a conversation with someone with brain damage."
MID:

On 15/06/2019 10:33, Renegade wrote:


wrote in message
...

I hope someone has more clue than I on this one.

This PC has a mix of SATA & PATA HDDs:
2G for data
Something with a 64G partition for OS, linux mint
And an old 250G used now & then for a partial backup - other backup HDDs
are larger.

All working well. I fit a 500G HDD from a PVR on SATA, gparted format
it, keeping it as FAT32. After this the pc won't even try to boot. Setup
shows the correct HDD is still flagged for first boot attempt, but
nothing. It does its hardware checks, reports the HDDs then hangs.

It is probably trying to do something with that new disk that takes an
infinite time.

Have you tried a live DVD boot and an inspection of what it finds?



Remove the new 500G and everything works again.

Er, what's going on?

https://www.instructables.com/id/Unl...BT-Vision-box/


HTH



--
Climate Change: Socialism wearing a lab coat.

On 15/06/2019 10:22, Theo wrote:
Jeff Layman wrote:
I've read somewhere that PVR HDs have a setup of their own -
particularly one which used to avoid error checking as it took too long
when writing to the disk. Does gparted get round this, or is it possibly
integral to the disk controller?

It's inside the disc. gparted doesn't touch that, but it's only likely to
come into play if you are doing large amounts of writing - in the way that
a security camera does. Most of the time an AV drive will be fine, although
I would be wary about storing valuable data on it.

My guess would be the OP has formatted the HDD as bootable in some way that's
confusing the boot process.

If in doubt, a complete wipe (with dd or a similar tool) should erase any
partition tables on it, and then just make a new partition table from
scratch.

Theo

A bit of reaearch ssuggest bootiong te machine without the drive, then
plugging in the drive, then using hdparm to unlock it.

It seems the problem is the bios scan of the drive





--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.

On Saturday, 15 June 2019 07:47:12 UTC+1, wrote:
How did you gpart it and format it if the PC hangs at boot with the 500gb drive attached?

Formatted it using a live cd, different os


NT

On Saturday, 15 June 2019 10:22:59 UTC+1, Theo wrote:
Jeff Layman wrote:
I've read somewhere that PVR HDs have a setup of their own -
particularly one which used to avoid error checking as it took too long
when writing to the disk. Does gparted get round this, or is it possibly
integral to the disk controller?

It's inside the disc. gparted doesn't touch that, but it's only likely to
come into play if you are doing large amounts of writing - in the way that
a security camera does. Most of the time an AV drive will be fine, although
I would be wary about storing valuable data on it.

My guess would be the OP has formatted the HDD as bootable in some way that's
confusing the boot process.

If in doubt, a complete wipe (with dd or a similar tool) should erase any
partition tables on it, and then just make a new partition table from
scratch.

Theo

I'll bet that's it, I didn't touch the partition or flags. Will redo it.


NT

Pamela wrote:
Marking a partition as active only serves to tell the BIOS that if it passes
control to that drive then control should pass direct to the boot loader in
the active partition.

That shouldn't affect a drive not specified in the boot sequence. Most of my
hard drives have an OS and an active partition (for hot recovery) but it
doesn't affect normal booting from another drive.

Quite often what happens is a drive which used to have an OS is reformatted
in a way that doesn't touch the boot sector. In a BIOS boot (ie not UEFI),
the process is that the BIOS looks for the boot sector (which is 512 bytes
only). If it finds something that looks like a boot sector it loads it into
RAM and jumps to it. The tiny amount of code there is supposed to chain a
secondary bootloader (like GRUB).

The problem comes if it can't find the secondary bootloader, perhaps if that
partition has been deleted. There's not enough in 512 bytes to do anything
about that, which means it just hangs at a black screen/flashing cursor.

If the BIOS is set to boot USB drives first, it might pick this up if
booting with a USB drive plugged in.

This seems possible although the earlier FAT32 formatting should have set
up the partition table correctly.

The boot sector can survive reformatting of partitions which causes the
above problem.

Theo

On Sunday, 16 June 2019 01:35:21 UTC+1, Theo wrote:
Pamela wrote:

Marking a partition as active only serves to tell the BIOS that if it passes
control to that drive then control should pass direct to the boot loader in
the active partition.

That shouldn't affect a drive not specified in the boot sequence. Most of my
hard drives have an OS and an active partition (for hot recovery) but it
doesn't affect normal booting from another drive.

Quite often what happens is a drive which used to have an OS is reformatted
in a way that doesn't touch the boot sector. In a BIOS boot (ie not UEFI),
the process is that the BIOS looks for the boot sector (which is 512 bytes
only). If it finds something that looks like a boot sector it loads it into
RAM and jumps to it. The tiny amount of code there is supposed to chain a
secondary bootloader (like GRUB).

The problem comes if it can't find the secondary bootloader, perhaps if that
partition has been deleted. There's not enough in 512 bytes to do anything
about that, which means it just hangs at a black screen/flashing cursor.

If the BIOS is set to boot USB drives first, it might pick this up if
booting with a USB drive plugged in.

This seems possible although the earlier FAT32 formatting should have set
up the partition table correctly.

The boot sector can survive reformatting of partitions which causes the
above problem.

Theo

I didn't touch the partitions at all, just formatted. There were some other megabytes I forget the details of. I need to delete the partitions & start again.


NT

On Sunday, 16 June 2019 09:41:27 UTC+1, tabby wrote:
On Sunday, 16 June 2019 01:35:21 UTC+1, Theo wrote:
Pamela wrote:

Marking a partition as active only serves to tell the BIOS that if it passes
control to that drive then control should pass direct to the boot loader in
the active partition.

That shouldn't affect a drive not specified in the boot sequence. Most of my
hard drives have an OS and an active partition (for hot recovery) but it
doesn't affect normal booting from another drive.

Quite often what happens is a drive which used to have an OS is reformatted
in a way that doesn't touch the boot sector. In a BIOS boot (ie not UEFI),
the process is that the BIOS looks for the boot sector (which is 512 bytes
only). If it finds something that looks like a boot sector it loads it into
RAM and jumps to it. The tiny amount of code there is supposed to chain a
secondary bootloader (like GRUB).

The problem comes if it can't find the secondary bootloader, perhaps if that
partition has been deleted. There's not enough in 512 bytes to do anything
about that, which means it just hangs at a black screen/flashing cursor..

If the BIOS is set to boot USB drives first, it might pick this up if
booting with a USB drive plugged in.

This seems possible although the earlier FAT32 formatting should have set
up the partition table correctly.

The boot sector can survive reformatting of partitions which causes the
above problem.

Theo

I didn't touch the partitions at all, just formatted. There were some other megabytes I forget the details of. I need to delete the partitions & start again.


NT

I checked it for flags, boot not ticked. I removed partitions & set it up as 1 partition for the whole disc, formatted it. Same problem. Mint 7 will work with it, Mint 17 won't, just hangs at boot time. BIOS boot settings hand't changed, the same named HDD there. Dunno. So I took the easy solution & USBed it. It works ok like that.

What's the issue with using ex-PVR HDDs for data? I've not found any concensus from searching on that.


NT

On Tue, 18 Jun 2019 03:06:07 -0700, tabbypurr wrote:

I checked it for flags, boot not ticked. I removed partitions & set it
up as 1 partition for the whole disc, formatted it. Same problem. Mint 7
will work with it, Mint 17 won't, just hangs at boot time. BIOS boot
settings hand't changed, the same named HDD there. Dunno. So I took the
easy solution & USBed it. It works ok like that.

Boot a live (cd/USB/DVD) without the disk fitted. Use gpart or similar to
inspect the numbers assigned to existing disk(s).

Then shut down, add the new disk and do the same again. See if the disk
numbers have shifted.



--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Sun, 16 Jun 2019 01:41:25 -0700 (PDT), wrote:

snip

I didn't touch the partitions at all, just formatted. There were some other megabytes I forget the details of. I need to delete the partitions & start again.

What I normally do is use Gparted from a LiveUSB/DVD to create a new
MSDOS partition table (or whatever it calls it) and leave it at that.

Then I boot from the real OS (assuming you can etc) and then use that
to create the partitions and format them etc.

Cheers, T i m

On 18/06/2019 11:06, wrote:
8


What's the issue with using ex-PVR HDDs for data? I've not found any concensus from searching on that.



I could tell you but as you won't actually believe me you will have to
investigate what background process go on on HDDs yourself.

wrote in message
...
On Sunday, 16 June 2019 09:41:27 UTC+1, tabby wrote:
On Sunday, 16 June 2019 01:35:21 UTC+1, Theo wrote:
Pamela wrote:

Marking a partition as active only serves to tell the BIOS that if it
passes
control to that drive then control should pass direct to the boot
loader in
the active partition.

That shouldn't affect a drive not specified in the boot sequence.
Most of my
hard drives have an OS and an active partition (for hot recovery) but
it
doesn't affect normal booting from another drive.

Quite often what happens is a drive which used to have an OS is
reformatted
in a way that doesn't touch the boot sector. In a BIOS boot (ie not
UEFI),
the process is that the BIOS looks for the boot sector (which is 512
bytes
only). If it finds something that looks like a boot sector it loads it
into
RAM and jumps to it. The tiny amount of code there is supposed to
chain a
secondary bootloader (like GRUB).

The problem comes if it can't find the secondary bootloader, perhaps if
that
partition has been deleted. There's not enough in 512 bytes to do
anything
about that, which means it just hangs at a black screen/flashing
cursor.

If the BIOS is set to boot USB drives first, it might pick this up if
booting with a USB drive plugged in.

This seems possible although the earlier FAT32 formatting should have
set
up the partition table correctly.

The boot sector can survive reformatting of partitions which causes the
above problem.

Theo

I didn't touch the partitions at all, just formatted. There were some
other megabytes I forget the details of. I need to delete the partitions
& start again.


NT

I checked it for flags, boot not ticked. I removed partitions & set it up
as 1 partition for the whole disc, formatted it. Same problem. Mint 7 will
work with it, Mint 17 won't, just hangs at boot time. BIOS boot settings
hand't changed, the same named HDD there. Dunno. So I took the easy
solution & USBed it. It works ok like that.

What's the issue with using ex-PVR HDDs for data?
I've not found any concensus from searching on that.

Some dont bother with repeatedly retrying with errors
because the occasional bad sector with a PVR is just
a minor glitch when you replay the recording but
can be a major problem with other data.

On Wed, 19 Jun 2019 05:27:07 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:


Some don¢t bother with repeatedly retrying with errors
because the occasional bad sector with a PVR is just
a minor glitch when you replay the recording but
can be a major problem with other data.

You just HAVE to open your senile gob, regardless of what irrelevant
bull**** comes out of it, eh, senile Rodent?

--
about senile Rot Speed:
"This is like having a conversation with someone with brain damage."
MID:

On Tuesday, 18 June 2019 11:23:19 UTC+1, Bob Eager wrote:
On Tue, 18 Jun 2019 03:06:07 -0700, tabbypurr wrote:

I checked it for flags, boot not ticked. I removed partitions & set it
up as 1 partition for the whole disc, formatted it. Same problem. Mint 7
will work with it, Mint 17 won't, just hangs at boot time. BIOS boot
settings hand't changed, the same named HDD there. Dunno. So I took the
easy solution & USBed it. It works ok like that.

Boot a live (cd/USB/DVD) without the disk fitted. Use gpart or similar to
inspect the numbers assigned to existing disk(s).

Then shut down, add the new disk and do the same again. See if the disk
numbers have shifted.

What numbers are those?


NT

On Tuesday, 18 June 2019 21:36:26 UTC+1, Peeler wrote:
On Wed, 19 Jun 2019 05:27:07 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:

Some dont bother with repeatedly retrying with errors
because the occasional bad sector with a PVR is just
a minor glitch when you replay the recording but
can be a major problem with other data.

You just HAVE to open your senile gob, regardless of what irrelevant
bull**** comes out of it, eh, senile Rodent?

Aye. But I think he's right this time. It happens once a century.


NT

On Tue, 18 Jun 2019 15:28:47 -0700, tabbypurr wrote:

On Tuesday, 18 June 2019 11:23:19 UTC+1, Bob Eager wrote:
On Tue, 18 Jun 2019 03:06:07 -0700, tabbypurr wrote:

I checked it for flags, boot not ticked. I removed partitions & set
it up as 1 partition for the whole disc, formatted it. Same problem.
Mint 7 will work with it, Mint 17 won't, just hangs at boot time.
BIOS boot settings hand't changed, the same named HDD there. Dunno.
So I took the easy solution & USBed it. It works ok like that.

Boot a live (cd/USB/DVD) without the disk fitted. Use gpart or similar
to inspect the numbers assigned to existing disk(s).

Then shut down, add the new disk and do the same again. See if the disk
numbers have shifted.

What numbers are those?

The actual device numbers/names in /dev.



--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

"Pamela" wrote in message
...
On 20:27 18 Jun 2019, "Rod Speed" wrote:



wrote in message
...
On Sunday, 16 June 2019 09:41:27 UTC+1, tabby wrote:
On Sunday, 16 June 2019 01:35:21 UTC+1, Theo wrote:
Pamela wrote:

Marking a partition as active only serves to tell the BIOS that if
it passes
control to that drive then control should pass direct to the boot
loader in
the active partition.

That shouldn't affect a drive not specified in the boot sequence.
Most of my
hard drives have an OS and an active partition (for hot recovery)
but it
doesn't affect normal booting from another drive.

Quite often what happens is a drive which used to have an OS is
reformatted
in a way that doesn't touch the boot sector. In a BIOS boot (ie not
UEFI),
the process is that the BIOS looks for the boot sector (which is 512
bytes
only). If it finds something that looks like a boot sector it loads
it into
RAM and jumps to it. The tiny amount of code there is supposed to
chain a
secondary bootloader (like GRUB).

The problem comes if it can't find the secondary bootloader, perhaps
if that
partition has been deleted. There's not enough in 512 bytes to do
anything
about that, which means it just hangs at a black screen/flashing
cursor.

If the BIOS is set to boot USB drives first, it might pick this up
if booting with a USB drive plugged in.

This seems possible although the earlier FAT32 formatting should
have set
up the partition table correctly.

The boot sector can survive reformatting of partitions which causes
the above problem.

Theo

I didn't touch the partitions at all, just formatted. There were some
other megabytes I forget the details of. I need to delete the
partitions & start again.


NT

I checked it for flags, boot not ticked. I removed partitions & set it
up as 1 partition for the whole disc, formatted it. Same problem. Mint
7 will work with it, Mint 17 won't, just hangs at boot time. BIOS boot
settings hand't changed, the same named HDD there. Dunno. So I took the
easy solution & USBed it. It works ok like that.

What's the issue with using ex-PVR HDDs for data?
I've not found any concensus from searching on that.

Some don't bother with repeatedly retrying with errors
because the occasional bad sector with a PVR is just
a minor glitch when you replay the recording but
can be a major problem with other data.

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn’t initially succeed in writing a sector.
With a PVR drive it makes sense to just yawn and carry on
writing later sectors instead of taking the time to retry writing
the sector and eventually reallocate that bad sector as a normal
non RAID drive would do because with a PVR drive, you can't
just tell the source of the data being recorded to pause the
data flow. If it isnt saved, its gone forever with a PVR.

where some errors can slip past C1 and C2 correction
without substantially affecting replay.

And with a PVR, even when a whole sector of data is lost, the
result is just an audible or visible glitch which is no big deal.
Much better than losing much more data when writing if
the drive keeps retrying and eventually reallocating the
bad sector and losing lots of later data in the process.

On the other hand, hard drive sector data
errors get corrected by ECC and remapping.

But that takes time when the sector retried.

You should know this. You can't bull**** you way out of a .... etc. Yawn.

There you go, face down in the mud, as always.

On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn’t initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

And are you sure it's always done in the drive, not also by the OS?

Cheers, T i m

On Wed, 19 Jun 2019 13:15:40 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:


No I am not.

Yes, you ARE a senile bull**** artist!

FLUSH another load of your known bull**** artistry

--
"Anonymous" to trolling senile Rot Speed:
"You can **** off as you know less than pig **** you sad
little ignorant ****."
MID:

"T i m" wrote in message
...
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn't initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

And are you sure it's always done in the drive, not also by the OS?

Yep, with modern hard drives it is.

On Wed, 19 Jun 2019 19:35:52 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:


No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn't initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

And are you sure it's always done in the drive, not also by the OS?

Yep, with modern hard drives it is.

HOW "modern", senile bull**** artist?

--
"Anonymous" to trolling senile Rot Speed:
"You can **** off as you know less than pig **** you sad
little ignorant ****."
MID:

On 19/06/2019 09:04, T i m wrote:
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesnt initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

HDD don't do read after write verification.
Tape drives do by having two heads.



And are you sure it's always done in the drive, not also by the OS?


Bad block mapping can be done by the drive and/or the OS.

On Wed, 19 Jun 2019 11:15:30 +0100, "dennis@home"
wrote:

On 19/06/2019 09:04, T i m wrote:
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn’t initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

HDD don't do read after write verification.

Some HDD's can / do (SCSI etc).

Tape drives do by having two heads.

shrug



And are you sure it's always done in the drive, not also by the OS?


Bad block mapping can be done by the drive and/or the OS.

Once that block has been considered bad by RAW.

Cheers, T i m

On 19/06/2019 12:09, T i m wrote:
On Wed, 19 Jun 2019 11:15:30 +0100, "dennis@home"
wrote:

On 19/06/2019 09:04, T i m wrote:
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesnt initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

HDD don't do read after write verification.

Some HDD's can / do (SCSI etc).

Which models?


Tape drives do by having two heads.

shrug



And are you sure it's always done in the drive, not also by the OS?


Bad block mapping can be done by the drive and/or the OS.

Once that block has been considered bad by RAW.

Cheers, T i m

"T i m" wrote in message
news
On Wed, 19 Jun 2019 11:15:30 +0100, "dennis@home"
wrote:

On 19/06/2019 09:04, T i m wrote:
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn't initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

HDD don't do read after write verification.

Some HDD's can / do (SCSI etc).

You don't get those in PVRs.

Tape drives do by having two heads.

shrug



And are you sure it's always done in the drive, not also by the OS?


Bad block mapping can be done by the drive and/or the OS.

Once that block has been considered bad by RAW.

"Pamela" wrote in message
...
On 12:09 19 Jun 2019, T i m wrote:

On Wed, 19 Jun 2019 11:15:30 +0100, "dennis@home"
wrote:

On 19/06/2019 09:04, T i m wrote:
On Wed, 19 Jun 2019 13:15:40 +1000, "Rod Speed"
wrote:

snip

You're thinking of the Red Book specification for CDs and DVDs

No I am not. I am thinking about the hard drive retrying writing
a sector when it doesn’t initially succeed in writing a sector.

Let's see if we can think up a technical name for that so everyone
knows what we are talking about ... how about 'Read after write
verification and / or 'Bad block remapping'?

HDD don't do read after write verification.

Some HDD's can / do (SCSI etc).

Tape drives do by having two heads.

shrug



And are you sure it's always done in the drive, not also by the OS?


Bad block mapping can be done by the drive and/or the OS.

Once that block has been considered bad by RAW.

The question is whether a PVR uses blocks
of bad data at all, in the way audio CDs can.

Nope, what matters is what happens when a write fails.

Unless the microcode on the device had been re-written, I expect
corrupt data blocks either get parity corrected within the hard
drive or else get flagged to the PVR's OS as an unusable block.

That’s reading, not writing.

Much as a PVR might manage to replay a corrupt video stream, I'm not clear
if
it would be permitted.

Of course it is.

On Thu, 20 Jun 2019 06:00:39 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:

Nope

LOL

--
Kerr-Mudd,John addressing senile Rot:
"Auto-contradictor Rod is back! (in the KF)"
MID:

On Thu, 20 Jun 2019 05:56:43 +1000, cantankerous trolling geezer Rodent
Speed, the auto-contradicting senile sociopath, blabbered, again:

You don't

LOL

--
Kerr-Mudd,John addressing senile Rot:
"Auto-contradictor Rod is back! (in the KF)"
MID: