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

On Thu, Feb 19, 2004 at 03:50:09PM -0500, Aaron Peterson wrote:
>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

Summary: bcwipe is trying to read 1 byte from an offset of 2^N-1.
FreeBSD no longer has block devices (since 4.0) - /dev/da0 is a
character device.  Character devices can only be read in blocksize
units (typically 512 bytes for disks).  You need to fix bcwipe to
handle character devices.

In detail:

 13661 bcwipe   CALL  open(0xbfbfee71,0x82,0xbfbfee71)
 13661 bcwipe   NAMI  "/dev/da0"
 13661 bcwipe   RET   open 3
Successfully open "/dev/da0" using fd 3.

 13661 bcwipe   CALL  lseek(0x3,0,0,0,0x2)
 13661 bcwipe   RET   lseek 0
Seek to EOF.  This should return the new offset (ie the size of the
device) but I suspect ktrace is truncating the off_t result to 32
bits.

 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
...
 13661 bcwipe   CALL  lseek(0x3,0,0x1,0,0)
 13661 bcwipe   RET   lseek 1
 13661 bcwipe   CALL  read(0x3,0xbfbeeba0,0x1)
 13661 bcwipe   RET   read -1 errno 22 Invalid argument
bcwipe then appears to perform a binary search to locate EOF - seeking
to 2^N-1 and reading 1 byte for N=63..1.  These reads all fail because
they aren't blocksize reads on a block boundary.

 13661 bcwipe   CALL  lseek(0x3,0,0,0,0x1)
 13661 bcwipe   RET   lseek 1
 13661 bcwipe   CALL  gettimeofday(0xbfbeebe8,0)
 13661 bcwipe   RET   gettimeofday 0
These operations are not relevant to the problem.

 13661 bcwipe   CALL  lseek(0x3,0,0,0,0)
 13661 bcwipe   RET   lseek 0
Seek to beginning of file.

 13661 bcwipe   CALL  write(0x3,0xbfbeecc0,0x1)
 13661 bcwipe   RET   write -1 errno 22 Invalid argument
Attempt to write 1 byte.  This again fails because it's not a multiple
of the blocksize.

Peter