Bug#602536: useless /dev/cciss/ device

[dann frazier <dannf@debian.org>]

On Fri, Nov 05, 2010 at 05:40:29PM +0000, Ian Jackson wrote:
> Package: linux-image-2.6.26-2-686-bigmem
> Version: 2.6.26-25lenny1
> 
> On an HP DL165 with nothing connected to the CCISS controller (the
> disks are connected only to the ordinary SATA controller), this kernel
> produces a device node /dev/cciss/c0d0, without a corresponding entry
> in /proc/partitions, but with an entry in /sys/block.
> 
> (parted sees this and complains about it, and it makes automated
> installs awkward.)
> 
> The device can be opened but looks empty:
> 
>   woodlouse:~# dd if=/dev/cciss/c0d0 of=t
>   0+0 records in
>   0+0 records out
>   0 bytes (0 B) copied, 0.000570254 s, 0.0 kB/s
>   woodlouse:~#

hey Ian,
 I belive this is intentional. This device file persists so that mgmt
software can still talk to the controller:

  commit 8ce51966d3b809d6c1ae4f3902058558589480b8
  Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
  Date:   Thu Sep 17 13:47:34 2009 -0500

      cciss: Handle special case for sysfs attributes of the first logical drive.
    
      For c0dx where x is not 0, we handle deletion and addition simply,
      but for c0d0, there is the special case that even when there's no
      disk, the device node exists so that the controller may be accessed.
      So, for c0d0, we only create the sysfs entries once, when a controller
      is added, and only remove them once, when a controller is being
      taken down.
    
      Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Though it could be argued that there are more modern interfaces for
configuring devices (raid_class ?), I highly suspect it would break
compatibility with a lot of existing userspace software. Though you
could certainly ask :)

My suggestion would be to blacklist the cciss driver on your system.