Re: bcwipe won't wipe a block device...

From: Steve Kargl <sgk_at_troutmask.apl.washington.edu>
Date: Thu, 19 Feb 2004 13:11:25 -0800
> >
> > Use ktrace or truss to see if bcwipe is actually opening /dev/da0
> > or /dev/rda0 or /dev/da0c.
> >
> 
> The output was too long I though to post back to the list from
> ktrace/kdump...  you can read it here:
> 
> http://www.alpete.com/bcwipe.kdump.txt
> 
> I'm not so good at understanding it since it is the first time I've ever
> used ktrace :)  I think I understand some of it, but I still don't
> understand the problem, so perhaps you guys can shed some light on the
> subject for me...

I'm no expert either, but that never stopped me from commenting on a topic :-).

Here's the relevant part.  ktrace shows that bcwipe has opened /dev/da0.

 13661 bcwipe   CALL  access(0xbfbfee71,0x6)
 13661 bcwipe   NAMI  "/dev/da0"
 13661 bcwipe   RET   access 0
 13661 bcwipe   CALL  open(0xbfbfee71,0x82,0xbfbfee71)
 13661 bcwipe   NAMI  "/dev/da0"
 13661 bcwipe   RET   open 3

I haven't looked up what the lseek syscall does, but I suspect 
that you are seek to the start of the file here and you have
succeeded 

 13661 bcwipe   CALL  lseek(0x3,0,0,0,0x2)
 13661 bcwipe   RET   lseek 0

Here'w where the problems begin.  It looks like you are seeking
beyond the end of the device.  lseek fails and bcwipe isn't
handling the failure correctly.

 13661 bcwipe   CALL  lseek(0x3,0,0xffffffff,0x7fffffff,0)
 13661 bcwipe   RET   lseek -1/0xffffffff
 13661 bcwipe   CALL  read(0x3,0xbfbeeba0,0x1)
 13661 bcwipe   RET   read -1 errno 22 Invalid argument


-- 
Steve
Received on Thu Feb 19 2004 - 12:11:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC