I’ve dinit’ed a new HDD and want to make sure it is OK to use.
I start “dcheck -lme /dev/hd0t7x”.
What I see is - sometimes it freezes for a few seconds and does not mark a
block as bad on this particular loop, on the next loop it may have it
marked…
How do I tell dcheck to not retry and mark a block at once?
Tony.
BTW, if I boot off the floppy and do:
Fsys.atapi
mount -p /dev/hd0
dinit -h /dev/hd0t77
dinit -h /dev/hd0t78
dcheck -mle /dev/hd0t77
dcheck -mle /dev/hd0t78
where will dcheck record the bad blocks?
If I mount both partitions - I can’t see .badblocks files there, why?
There were some found.
Are they marked in the .bitmap files only?
Tony.
Tony wrote:
BTW, if I boot off the floppy and do:
Fsys.atapi
mount -p /dev/hd0
dinit -h /dev/hd0t77
dinit -h /dev/hd0t78
dcheck -mle /dev/hd0t77
dcheck -mle /dev/hd0t78where will dcheck record the bad blocks?
If I mount both partitions - I can’t see .badblocks files there, why?
There were some found.
Are they marked in the .bitmap files only?
Note the name is “.bad_blks”. From looking at the code the filesystem
has to be mounted in order for dcheck to manipulate “.bad_blks”, so
after the “dinit” you’ll also need to do a “mount” prior to the
“dcheck -m”. The .bad_blks file in the root of each filesystem will be
created/updated (so each partition will have it’s own). Bad blocks will
be marked in the “.bitmap”, which is enough to stop them being
allocated, until you run a chkfsys which will try and give them back
(chkfsys is the only thing which uses .bad_blks, just for that reason;
Fsys does not take any notice of it and uses .bitmap settings only).
On Sat, 29 Oct 2005 07:11:15 +0400, John Garvey <jgarvey@qnx.com> wrote:
…From looking at the code the filesystem has to be mounted in order
for dcheck to manipulate “.bad_blks”, so after the “dinit” you’ll also
need to do a “mount” prior to the “dcheck -m”.
Do I have to “dcheck -mle /hd0” i.e. that particular partition for
“.bad_blocks” to appear there or is it enough to just mount it somehow
before doing “dcheck -mle /dev/hd0t77” ?
…Bad blocks will be marked in the “.bitmap”, which is enough to stop
them being allocated, until you run a chkfsys which will try and give
them back (chkfsys is the only thing which uses .bad_blks, just for that
reason; Fsys does not take any notice of it and uses .bitmap settings
only).
Thank you for this very important notice!
Tony.
Tony wrote:
On Sat, 29 Oct 2005 07:11:15 +0400, John Garvey <> jgarvey@qnx.com> > wrote:
…From looking at the code the filesystem has to be mounted in order
for dcheck to manipulate “.bad_blks”, so after the “dinit” you’ll
also need to do a “mount” prior to the “dcheck -m”.
Do I have to “dcheck -mle /hd0” i.e. that particular partition for
“.bad_blocks” to appear there or is it enough to just mount it somehow
before doing “dcheck -mle /dev/hd0t77” ?
Either, by the looks. You do “dcheck -m /dev/hd0t77”, and it uses
fsys_get_mount_pt() to find where it is mounted (eg “/hd0”) so it
can make the pathnames (eg “/hd0/.bitmap” and “/hd0/.bad_blks”).
Or specifying “/hd0” should allow it to go back the other way and
find “/dev/hd0t77”. It just must be mounted.
From that same code you should have been seeing a warning message
(using -m without it being mounted, although you don’t say you did):
“could not find mount point for ‘%s’: -m (mark) turned off\n”
This info also appears to be in the online docs:
Files:
If the -m (mark bad blocks) option is specified, the block special file
being checked must be a currently mounted QNX partition. The .badblocks
and .bitmap files on that filesystem are updated if dcheck discovers
any bad blocks.
[Yes, I see the incorrect filename used here]
On Sat, 29 Oct 2005 23:01:17 +0400, John Garvey <jgarvey@qnx.com> wrote:
From that same code you should have been seeing a warning message
(using -m without it being mounted, although you don’t say you did):
“could not find mount point for ‘%s’: -m (mark) turned off\n”
Yes, I did not see it indeed.
RE: documentation.
I’m using the paper edition that came with QNX v4.25C installation CDROM.
I’ve downloaded the PDF version recently to see if some my “discoveries”
regarding the “sticky bit and SGID on a directory” got mentioned there -
but could not find anything about it… Do you intend to keep the Fsys’s
behavior switch “BSD<->SysV” undocumented still?
Tony.
Tony wrote:
I’ve downloaded the PDF version recently to see if some my
“discoveries” regarding the “sticky bit and SGID on a directory” got
mentioned there - but could not find anything about it… Do you intend
to keep the Fsys’s behavior switch “BSD<->SysV” undocumented still?
If you refer to use of S_ISVTX on a directory to mean that deleting a
file you now must be the owner of that directory or have write
permission to the file itself (rather than just write permission to
its parent directory), then I put this extension into Fsys on Aug 2002,
but I am not sure if a newer version has shipped/released since then
(from ‘sin ver’ it would still be 4.24Y but a newer date). This was
PR/5136.
If by S_ISGID you mean the behaving of forcing the gid of a newly
created file to be that of the parent directory rather then the egid
of the caller (when the directory is marked S_ISGID), then I think
that has always been the behaviour of Fsys.
On Mon, 31 Oct 2005 00:34:32 +0300, John Garvey <jgarvey@qnx.com> wrote:
If you refer to use of S_ISVTX on a directory to mean that deleting a
file you now must be the owner of that directory or have write
permission to the file itself (rather than just write permission to its
parent directory), then I put this extension into Fsys on Aug 2002, but
I am not sure if a newer version has shipped/released since then (from
‘sin ver’ it would still be 4.24Y but a newer date).
This was PR/5136.
I’m on QNX v4.25G + all recent updates, my Fsys is:
Fsys v4.25Y 23Apr2002
and it behaves exactly like that. (And I’m loving it! >> )
I’m sure this version came with Patch G rather than with the later
updates…
Tony.