Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UFS bad block list

20 views
Skip to first unread message

Marat Shafigulin

unread,
Dec 15, 1997, 3:00:00 AM12/15/97
to


Hi, all,

From documentation I saw, that some i-nodes in UFS file system
has special meaning and have fixed numbers ( like root i-node,
which has number 2 ).

The inode number 1 is not usually used and from some docs,
it looks like it was assigned historically for bad blocks list,
so that ufsdump for example doesn't attempt to dump it's contents.

So, the question is - is this true. And if so, does there exist
any tools/libraries that could be used to construct such bad blocks
list.

Thank you in advance,
Marat.
ma...@cda.ipmce.su

Boyd Roberts

unread,
Dec 16, 1997, 3:00:00 AM12/16/97
to

In article <673kkr$928$1@jumbo>, ma...@cda.ipmce.su (Marat Shafigulin) writes:
>From documentation I saw, that some i-nodes in UFS file system
>has special meaning and have fixed numbers ( like root i-node,
>which has number 2 ).
>

Yes, inode 1 was reserved for mapping bad blocks with adb or fsdb.

I think originially ROOTINO was 1 and it was changed to 2 just to
see if the file-system code would hack it. Then it was used for
bad block mapping.

--
Boyd Roberts <bo...@france3.fr> UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: jmo...@silcoinc.com

Jim Reid

unread,
Dec 16, 1997, 3:00:00 AM12/16/97
to

ma...@cda.ipmce.su (Marat Shafigulin) writes:

> From documentation I saw, that some i-nodes in UFS file system
> has special meaning and have fixed numbers ( like root i-node,
> which has number 2 ).
>

> The inode number 1 is not usually used and from some docs,
> it looks like it was assigned historically for bad blocks list,

Correct.

> So, the question is - is this true. And if so, does there exist
> any tools/libraries that could be used to construct such bad blocks
> list.

There are, but they are no subsititute for getting the disk driver
(and SCSI firmware?) do handle the bad blocks. On some systems, you
can use badsect to put some bad disk blocks in a "special" directory -
usually /BAD at the top of each filesystem. This won't work for bad
blocks that hold filesystem metadata like a superblock or part of the
inode list or a bitmap of used/free inodes diskblocks. ISTR there was
a (now obsolete?) bad144 utility which wrote a DEC 144 format bad
block list to disk. This had the same limitations as badsect and I
suspect it isn't supported by today's disk subsystems. IIRC, there was
a program called bad that came with early UNIX systems that linked all
the non-metadata bad blocks into inode 1. It's long gone.

Depending on your vendor, you may have a utility which can reformat
disks, repair or slip out bad sectors, fix boot blocks and disk labels
and so on. It might be able to rewrite a bad block list on disk for
the (SCSI?) disk firmware and device driver. Consult your local
documentation and bear in mind what you can do might depend on what
the model of disk controller is capable of doing. Examples of such
utilities are format on Suns and diskdefect on BSD/OS.

0 new messages