> track-to-track seek: 0  # microseconds
> drivedata: 0 
> 
> 8 partitions:
> #        size   offset     fstype   [fsize bsize   cpg]
>   d: 120103200        0     unused        0     0         # (Cyl.    0 -
> 119149)
>   e: 120101877       63       RAID                        # (Cyl.    0*-
> 119148*)
> 
> 
> 5 partitions:
> #        size   offset     fstype   [fsize bsize   cpg]
>   d: 120103200        0     unused        0     0         # (Cyl.    0 -
> 119149)
>   e: 120103200        0     4.2BSD     1024  8192    16   # (Cyl.    0 -
> 119149)
> 
> 
> 
> I notice an inconsistency here, is this the cause of the problem? What
> needs to be done to correct it? Will we lose raid?
> 
>
no but it's big inconsistency and problem to start raid partition from
offset 0 as raid disklabels could overwrite disk's disklabels.



 
> Also found that I can create a file, like:
> 
> sycamore# dd if=/dev/zero of=testing bs=1024
> 
> /incoming: write failed, file system is full
> dd: testing: No space left on device
> 42825+0 records in
> 42824+0 records out
> 43851776 bytes transferred in 45 secs (974483 bytes/sec)
> 
> -rw-r--r--   1 root  wheel  43851776 Feb  6 11:54 testing
> 
> 
> Leaving the file there, I can then go create a second file:
> 
> sycamore# dd if=/dev/zero of=testing2 bs=1024
> 
> /incoming: write failed, file system is full
> dd: testing2: No space left on device
> 42769+0 records in
> 42768+0 records out
> 43794432 bytes transferred in 38 secs (1152485 bytes/sec)
> 
> -rw-r--r--   1 root  wheel  43851776 Feb  6 11:54 testing
> -rw-r--r--   1 root  wheel  43794432 Feb  6 11:55 testing2
> 
> and slowly fill up the system?
try fsck :)