a small cgd(4) hiccup?

[Nino Dehne <ndehne%gmail.com@localhost>]

Hi,

in relation to my raid-on-cgd tests[1] which are going forward quite well,
I'm testing random parts of the picture to see if they behave as I would
expect them to.

After patching a very recent netbsd-5 tree with revision 1.54 of
src/sys/dev/cgd.c to get cgd-on-dk capability, I noticed that suddenly
I can leave dk(4) out of the picture completely, as far as individual
components are concerned. cdg(4) now works directly on /dev/wd[0-4]d.
Great!

Anyway, since the cgd devices and their respective counterparts are of
exactly the same size, I decided to do the following out of curiosity:

wd0: 1397 GB, 2907021 cyl, 16 head, 63 sec, 512 bytes/sect x 2930277168\
        sectors

# dd if=/dev/zero of=/dev/rwd0d bs=512 seek=2930270000
dd: /dev/rwd0d: end of device
7169+0 records in
7168+0 records out
3670016 bytes transferred in 0.468 secs (7841914 bytes/sec)
# dd if=/dev/rwd0d bs=512 skip=2930270000 | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00380000
7168+0 records in
7168+0 records out
3670016 bytes transferred in 0.844 secs (4348360 bytes/sec)

This looks right. Let's go on. Do the same with cgd0.

# dd if=/dev/zero of=/dev/rcg0d bs=512 seek=2930270000
cgd0: error 22   <- this is a kernel message (green text)
dd: /dev/rcgd0d: Invalid argument
7170+0 records in
7169+0 records out  <- one more record than wd0?
3670528 bytes transferred in 0.603 secs (6087111 bytes/sec)
# dd if=/dev/rcgd0d bs=512 skip=2930270000 | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00380000  d1 c8 a8 56 ee 51 b5 f6  e2 42 2e 1b 4c b6 23 ec  |...V.Q...B..L.#.|
00380010  ca 5e 5c d6 51 f8 90 45  ed 56 13 4d 91 64 6f 88  |.^\.Q..E.V.M.do.|
*
00380200
cgd0: error 22
dd: /dev/rcgd0d: Invalid argument
7169+0 records in
7169+0 records out
3670528 bytes transferred in 0.882 secs (4161596 bytes/sec)
#

The "real" data up to 0x380000 looks OK, but somehow cgd fabricates an
additional sector, possibly leaking some data it shouldn't?

Since I'm lacking the clue to look into this, maybe someone else will
find this useful.

Best regards.


[1] http://mail-index.netbsd.org/tech-kern/2008/11/21/msg003581.html
Switching to a Uniprocessor kernel with boot -1 helps against the
lockups. The next problem are filesystems of a certain size leading
to kernel panics. A detailed mail will follow.

-- 
Of course it runs NetBSD.