| I agree on what you are saying but something additional has surfaced in
the meantime:
%% This dd only fails on the node carrying the service.
I have tried relocating from one to the other and my %% statement stays
exactly the same.
In the office I tried something else, I created me an LSM volume,
tried to dd to /dev/rvol/testdg/testvol and the dd fails in exactly the
same manner.
Strange isn't it .. ?!
Geert\\\
|
| Your test is actually flawed. When using a raw disk interface, you should
access whole blocks. In this case this means that you can't write half a
diskblock. Since /vmunix isn't a multiple of 512 (check this on your system),
the last write will fail with EINVAL. LSM checks in its driver write routines
that you are trying to write multiples of whole blocks. In short, you are
not adhering to the rules for LSM raw devices. If you want to dd /vmunix into
the volume you can do it via the LSM block device. In that case /vmunix will
be copied into the kernel and the kernel will handle the padding of block
parts.
However, that is probably not something you are really interested in.
Also, why does it work when drd is used remotely? This is because of drd:s
design: When drd is accessing the underlying disk driver (here LSM) on the
remote host, it bypasses the read and write routines and accesses the driver
strategy routine directly. Since LSM does thebyte count checks in the read and
write routines, the check isn't made. But the last block in the last write is
going to be padded with something probably zeroes. That may not have been what
you intended.
It is a quirk of drd that it doesn't behave in the same way remotely
and locally when on top of LSM. I wouldn't call it a bug though. If you are
using the raw driver
interface, better know what you are doing. If you use a raw disk partition
directly (not LSM), you wouldn't get an error locally or remotely. This is
because our scsi disk driver doesn't check for block multiples. However,
the scsi disk driver would write a whole block to the disk when you are asking
for a fraction. The padded part is garbage data probably zeroes.
Finally, the diskx utility doesn't work with drd. Check man page for -f option
[Posted by WWW Notes gateway]
|
| After thinkning a little more about this, I have entered a QAR on LSM. When
looking at Digital's documentation and the upcoming Unix98 standard, this
error
is not documented anywhere for write(2). LSM should write the data (as the
disk driver does) without giving an error.
[Posted by WWW Notes gateway]
|