Why Did SpinRite 5 Care About Filesystem Type?

[Jon Forrest]

I completely understand why SpinRite only runs under
DOS. What I don't understand is why SpinRite is even
aware of filesystem types.

For the longest time SpinRite 5 didn't work on NTFS-format
disks. But, since SpinRite deals with disks on a track
level, why should it care what's written on the tracks?

Now SpinRite 6 claims that "can be used on any operating
system and any file system" so maybe whatever was limiting
SpinRite 5 has been changed.

Jon Forrest

 

[Folkert Rienstra]

I completely understand why SpinRite only runs under DOS.

Well, enlighten us.

What I don't understand is why SpinRite is even aware of filesystem types.

So it can copy data from 'bad' sectors to other free sectors and for that
it needs to know which sectors(clusters) are available and needs to update
the file allocation tables and so on.

For the longest time SpinRite 5 didn't work on NTFS-format disks.

But, since SpinRite deals with disks on a track level,

Only as long as it doesn't find anything wrong.
And it is on a sector level, btw. And on a partition level.

why should it care what's written on the tracks?

It doesn't.
It's a remnant from the days that drives didn't/couldn't replace sectors
on their own so Spinrite did it for them but using normal user space.

SpinRite 5 also disabled the auto reassigment setting on SCSI drives
and used this old scheme instead. That made me feel all warm and fuzzy
so I took the opportunity to ask my money back.

Now SpinRite 6 claims that "can be used on any operating
system and any file system" so maybe whatever was limiting
SpinRite 5 has been changed.

They just junked the filesystem code and let the drive do all the work,
just like before but, -presumably- SpinRite 6 will now not work on very
old drives anymore.

 

[Arno Wagner]

I completely understand why SpinRite only runs under
DOS. What I don't understand is why SpinRite is even
aware of filesystem types.

For the longest time SpinRite 5 didn't work on NTFS-format
disks. But, since SpinRite deals with disks on a track
level, why should it care what's written on the tracks?

Now SpinRite 6 claims that "can be used on any operating
system and any file system" so maybe whatever was limiting
SpinRite 5 has been changed.

I would say nothing has changed, except the marketing blurb.
SpinRite does not look at the filesystem and hence is compatible
with all.

Arno

 

[Folkert Rienstra]

I would say nothing has changed, except the marketing blurb. Spin
Rite does not look at the filesystem and hence is compatible with all.

Babblebot, utterly clueless, as always.

 

[Jim]

Well, to be honest, I'm not 100% sure myself. But I can speculate why for
at least one reason.

First, I'm not sure Spinrite does work at the track level, but instead at
the sector level. At least according to the displays, it certainly
*appears* to be working at the sector level. Or perhaps it *can* work at
the track level when necessary. But I find it hard to believe that it at
least doesn't have the capability to work at the sector level. In fact,
unless a specific track-level problem is detected, why wouldn't it work at
the sector level, if only to make things easier and more efficient?! Even
if it did work at the track level, the only thing it could do is rewrite
that track. It can't relocate a track, only a sector. If a track is bad,
the entire sector must be marked BAD.

Spinrite tries to repair drives in various ways. For example, if a sector
has failed or is detecting to be failing, Spinrite can relocate that
sector's contents. What makes Spinrite so valuable is that it tries harder
than most any other utility to recover that data. But even so, doesn't
Spinrite need to KNOW the filetype and thus the filesystem so it can fix up
the directory too?! IOW, Spinrite can't just start moving data around
without consequences. The native filesystem's directory may have to be
updated too (e.g., to point to the new starting sector, if applicable).

I'm not claiming some special knowledge, or that this is even the ONLY
reason, but given my own experiences w/ the product and understanding of its
capabilities, I simply don't understand how it could do as much as it does
WITHOUT knowing the filesystem, in some cases. If all Spinrite did was
repair sectors IN-PLACE (which isn't always possible, sometimes you HAVE to
move the data and mark the current sector as BAD), then perhaps the knowing
the specific filesystem would be irrelevant.

Jim

 

[Arno Wagner]

Well, to be honest, I'm not 100% sure myself. But I can speculate why for
at least one reason.

First, I'm not sure Spinrite does work at the track level, but instead at
the sector level. At least according to the displays, it certainly
*appears* to be working at the sector level. Or perhaps it *can* work at
the track level when necessary. But I find it hard to believe that it at
least doesn't have the capability to work at the sector level. In fact,
unless a specific track-level problem is detected, why wouldn't it work at
the sector level, if only to make things easier and more efficient?! Even
if it did work at the track level, the only thing it could do is rewrite
that track. It can't relocate a track, only a sector. If a track is bad,
the entire sector must be marked BAD.

There is no meaningful "track" level, except on floppies. You cannot
even reliably find out how many tracks a modern HDD has, unless you look
into the datasheet.

Spinrite tries to repair drives in various ways. For example, if a sector
has failed or is detecting to be failing, Spinrite can relocate that
sector's contents.

Yea, but modern disks do that by themselves anyways.

What makes Spinrite so valuable is that it tries harder
than most any other utility to recover that data.

Actually it cannot try harder than modern disks do themselves,
since it cannot do anything beyond what the disk already does.
It used to be different. Not anymore.

But even so, doesn't
Spinrite need to KNOW the filetype and thus the filesystem so it can fix up
the directory too?!

And why would it do that? And how would it do that?

IOW, Spinrite can't just start moving data around
without consequences. The native filesystem's directory may have to be
updated too (e.g., to point to the new starting sector, if applicable).

To reitreate, SpinRite does not move data, the drive does that
transparently.

I'm not claiming some special knowledge, or that this is even the
ONLY reason, but given my own experiences w/ the product and
understanding of its capabilities, I simply don't understand how it
could do as much as it does WITHOUT knowing the filesystem, in some
cases.

It does not do anything besides reading secotrs.

If all Spinrite did was repair sectors IN-PLACE (which isn't
always possible, sometimes you HAVE to move the data and mark the
current sector as BAD),

Current disks do that. There is no in-place today. But the remapped
sector gets the same number as the old one.

then perhaps the knowing the specific
filesystem would be irrelevant.

Oh, it is. And SpinRite is also pretty irrelevant today.
Just run a long SMART selftest, it does the same and for free.

Arno

 

[Folkert Rienstra]

Well, to be honest, I'm not 100% sure myself. But I can speculate why for
at least one reason.

[snip]

If all Spinrite did was repair sectors IN-PLACE (which isn't always
possible, sometimes you HAVE to move the data and mark the current
sector as BAD), then perhaps the knowing the specific filesystem would
be irrelevant.

That is what it boils down to, pure and simple.

 

[Fred]

There is no meaningful "track" level, except on floppies. You cannot
even reliably find out how many tracks a modern HDD has, unless you
look into the datasheet.


Yea, but modern disks do that by themselves anyways.

Actually it cannot try harder than modern disks do themselves,
since it cannot do anything beyond what the disk already does.

Corse it can, by trying to read that sector a lot more
than would normally happen with normal ops and moving
the heads away and back to that spot just by the sequence
in which requests are made for specific sectors etc.

It used to be different. Not anymore.

Fraid so.

And why would it do that?

The drive wont necessarily reallocate sectors that can be read
successfully after a number of retrys, UNTIL that sector is WRITTEN to.

And how would it do that?

Just move the data it gets from that sector to a free sector, then write
to the marginal sector to get the drive to reallocate that marginal sector.

To reitreate, SpinRite does not move data, the drive does that transparently.

Not when the sector isnt written to the drive doesnt.

It does not do anything besides reading secotrs.
Wrong.

Current disks do that.

Nope, not with sectors that arent written to.

There is no in-place today. But the remapped
sector gets the same number as the old one.

Oh, it is. And SpinRite is also pretty irrelevant today.
Just run a long SMART selftest, it does the same and for free.

Thats wrong too.

 

[Folkert Rienstra]

There is no meaningful "track" level, except on floppies.

You cannot even reliably find out

There is no "find out" at all, reliably or not, for drives over 8GB.

how many tracks a modern HDD has, unless you look into the datasheet.

Yea, but modern disks do that by themselves anyways.

*Can* do that by themselves. Doesn't mean they do it nesessarily.

Actually it cannot try harder than modern disks do themselves,

Obviously it can by repetition. Bad ECC ofcourse will make those futile

since it cannot do anything beyond what the disk already does.

Maybe, maybe not.

It used to be different. Not anymore.

That remains to be seen.
The drive only goes into some of it's ERP routines after the initial failure.
The program can (re)start from a different angle.

And why would it do that?

For the same reason diskdefragmenters do it? So that no data is lost if someone
pulls the plug during reallocation

And how would it do that?

By knowing the filesystem, obviously.

as an example:

Quite possibly, when it's the first sector of a file.

To reitreate,

You can 'reitreate' all you want, Babblebot.
If SpinRite decides to test out a sector that it doesn't like it will copy the
data in it to a safe place so that it won't go missing if something is inter-
rupted and then run it's destructive diagnostic on that sector and possibly
copy the data back afterwards. The procedure is similar to with a defrag.

SpinRite does not move data, the drive does that transparently.

You don't get to decide what SpinRite does, Babblebot.

It does not do anything besides reading secotrs.

Babblebot, utterly clueless, as always.

Current disks do that.

*Can* do that.

There is no in-place today.

There is nothing that says so explicitly.
If the drive checks the candidate bad sector sector and finds it OK,
it may well use it again. The behaviour may differ for reads vs writes.

But the remapped sector gets the same number as the old one.

*If* it gets reassigned.

Oh, it is.

Depends on what the program does, which you have no say in whatsoever, Babblebot.

And SpinRite is also pretty irrelevant today.

Not if you need the drive to be pushed hard to clean itself up.

Just run a long SMART selftest, it does the same

It doesn't.