[TUHS] mkfs somewhere else?

[TUHS] mkfs somewhere else?

[Norman Wilson]

  what about using another minor device?  Is xp0d mapped elsewhere?

Since it's a BSD, won't it try by default to read a partition
table from the first few sectors of the disk?

Norman Wilson
Toronto ON

[TUHS] mkfs somewhere else?

[random832]

On Thu, Feb 12, 2015, at 10:50, cowan at ccil.org wrote:
> Dave Horsfall:
> 
> > Not just that, but the aerodynamics have been screwed up.  The heads will
> > no longer "float" on an air-cushion; I believe the gap is the traditional
> > human hair width, if that.
> 
> Much larger.  I remember seeing a scale drawing that showed the gap
> as half an inch or so, with a dust particle the size of a freaking
> mountain and a human hair that looked like a Tipler cylinder.

I think that's based on a modern hard drive, though. There's a reason
modern hard drives are sealed with air filters on the pressure
equalizing ports.

[TUHS] mkfs somewhere else?

[cowan]

Dave Horsfall:

> Not just that, but the aerodynamics have been screwed up.  The heads will
> no longer "float" on an air-cushion; I believe the gap is the traditional
> human hair width, if that.

Much larger.  I remember seeing a scale drawing that showed the gap
as half an inch or so, with a dust particle the size of a freaking
mountain and a human hair that looked like a Tipler cylinder.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson

[TUHS] mkfs somewhere else?

[Dave Horsfall]

On Sun, 8 Feb 2015, Norman Wilson wrote:

> Cleaning the heads probably isn't an option; when they crash, they don't 
> just pick up material from the disk platter, they may themselves be 
> damaged enough that sharp bits of the heads themselves are sticking out.

Not just that, but the aerodynamics have been screwed up.  The heads will 
no longer "float" on an air-cushion; I believe the gap is the traditional 
human hair width, if that.

Trivia: there is a small NiCd battery in the RK-05 drive which has to be 
replaced every so often; its sole job is to drag those heads back in the 
event of a power failure, whether it was writing at the time or not.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] mkfs somewhere else?

[Norman Wilson]

Dave Horsfall:

  I also wrote a paper on a "bad block" system, where something like inum
  "-1" contained the list of bad sectors, but never saw it through.

====

During the file system change from V6 to V7, the i-number of
the root changed from 1 to 2, and i-node 1 became unused.
At least some versions of the documentation (I am too harried
to look it up at the moment) claimed i-node 1 was reserved
for holding bad blocks, to keep them out of the free list,
but that the whole thing was unimplemented.

I vaguely remember implementing that at some point: writing
a tool to add named sectors to i-node 1.  Other tools needed
fixing too, though: dump, I think, still treated i-node 1
as an ordinary file, and tried to dump the contents of
all the bad blocks, more or less defeating the purpose.

I left all that behind when I moved to systems with MSCP disks,
having written my own driver code that implemented DEC's
intended port/class driver split, en passant learning how
to inform the disk itself of a bad block so it would hide it
from the host.

I'd write more but I need to go down to the basement and look
at one of my modern* 3TB SATA disks, which is misbehaving
even though modern disks are supposed to be so much better ...

Norman Wilson
Toronto ON

* Not packaged in brass-bound leather like we had in the old days.
You can't get the wood, you know.

[TUHS] mkfs somewhere else?

[Norman Wilson]

  Would anyone know if it's still possible to just replace the platters and
  clean the heads?

If the heads are really crashed, the only safe course is
to replace both the damaged heads and the damaged disk pack.
Anything else admits a substantial risk of carrying the
crash forward.

Cleaning the heads probably isn't an option; when they
crash, they don't just pick up material from the disk
platter, they may themselves be damaged enough that sharp
bits of the heads themselves are sticking out.

Norman Wilson
Toronto ON

[TUHS] mkfs somewhere else?

[Jacob Ritorto]

So I managed to find the man page (thanks to the FreeBSD people!) for
2.9BSD's xp driver.  It clued me in that xp0e is further up the disk.
Tried to mkfs that and am getting intermittent chunks of good and bad.  So
I guess life's over for this guy.  So sad because other than the headcrash,
the thing is in immaculate, perfect working condition!  Maybe it could
become a spinning (and mildly horrifying) display inside a coffee table or
something.

On Sun, Feb 8, 2015 at 12:34 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > what about using another minor device?  Is xp0d mapped elsewhere?
>
> Dunno.
>
>
> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > Would anyone know if it's still possible to just replace the platters
> > and clean the heads? This drive is really nice, but the headcrash really
> > needs to be dealt with.  Are there any more fuji160-compatible platters
> > on earth?  If so, is there a way to install them to the existing hubs
> > straight enough that there's acceptable runout?
>
> Keep in mind that crashed disk => damaged head => more crashed disks =>
> more crashed heads...
>
> It's amazing, in a weird sort of way, just how rapidly a disk-crash
> infection can spread :-(
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/b983734f/attachment.html>

[TUHS] mkfs somewhere else?

[Dave Horsfall]

On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> what about using another minor device?  Is xp0d mapped elsewhere?

Dunno.


On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> Would anyone know if it's still possible to just replace the platters 
> and clean the heads? This drive is really nice, but the headcrash really 
> needs to be dealt with.  Are there any more fuji160-compatible platters 
> on earth?  If so, is there a way to install them to the existing hubs 
> straight enough that there's acceptable runout?

Keep in mind that crashed disk => damaged head => more crashed disks => 
more crashed heads...

It's amazing, in a weird sort of way, just how rapidly a disk-crash 
infection can spread :-(

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] mkfs somewhere else?

[Jacob Ritorto]

Would anyone know if it's still possible to just replace the platters and
clean the heads? This drive is really nice, but the headcrash really needs
to be dealt with.  Are there any more fuji160-compatible platters on
earth?  If so, is there a way to install them to the existing hubs straight
enough that there's acceptable runout?

-j

On Sun, Feb 8, 2015 at 2:03 AM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> what about using another minor device?  Is xp0d mapped elsewhere?
>
> On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>>
>> > However, when I try to mkfs, I can see the heads trying to write on the
>> > headcrashed part of the disk.  (Nice having those plexiglass covers!)
>> >
>> > Is there a way to tell mkfs (or perhaps some other program) to not try
>> > to write on the damaged cylinders?
>>
>> Modify the driver itself?
>>
>> I also wrote a paper on a "bad block" system, where something like inum
>> "-1" contained the list of bad sectors, but never saw it through.
>>
>> --
>> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
>> http://www.horsfall.org/spam.html (and check the home page whilst you're
>> there)
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/523818ca/attachment.html>

[TUHS] mkfs somewhere else?

[Jacob Ritorto]

what about using another minor device?  Is xp0d mapped elsewhere?

On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > However, when I try to mkfs, I can see the heads trying to write on the
> > headcrashed part of the disk.  (Nice having those plexiglass covers!)
> >
> > Is there a way to tell mkfs (or perhaps some other program) to not try
> > to write on the damaged cylinders?
>
> Modify the driver itself?
>
> I also wrote a paper on a "bad block" system, where something like inum
> "-1" contained the list of bad sectors, but never saw it through.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/e1507360/attachment.html>

[TUHS] mkfs somewhere else?

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> However, when I try to mkfs, I can see the heads trying to write on the 
> headcrashed part of the disk.  (Nice having those plexiglass covers!)
> 
> Is there a way to tell mkfs (or perhaps some other program) to not try 
> to write on the damaged cylinders?

Modify the driver itself?

I also wrote a paper on a "bad block" system, where something like inum 
"-1" contained the list of bad sectors, but never saw it through.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] mkfs somewhere else?

[Jacob Ritorto]

Hi,
  I'm running 2.9BSD on a pdp11/34 with an Emulex sc21 controller to some
Fuji160 disks.  Booting with root on RL02 for now, but want to eventually
have the whole system on the Fujis and disconnect the rl02s.

  While the previous owner of the disks appears to have suffered a
headcrash near cylinder 0, I'm having an impressive degree of success
writing to other parts of the disk.

  However, when I try to mkfs, I can see the heads trying to write on the
headcrashed part of the disk.  (Nice having those plexiglass covers!)

  Is there a way to tell mkfs (or perhaps some other program) to not try to
write on the damaged cylinders?

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/a14bfdd3/attachment.html>