LV randomly disappearing after a 'dd'

[PatRoy]

G'day.

Running HPUX 11.31 on rx6600.

Our Sybase DBAs keep having a raw LV disappearing on them. I'm new in this job and all I know is that this is their setup:

- 1 VG of 760 Gig was created using, I believe 2 luns (/dev/sybase).

- This VG has a total of 43 LVs (PE size being 16Megs)

From what I've been told, once in a while, they need to wipe the first few blocks on the character devices... (don't know why). In order to do so, here's the snippet of code they use:

for R_FILE in $R_FILES
do
if [ ! -c $R_FILE ]
then
echo "$R_FILE is not a character special device"
continue
fi

echo "dd $R_FILE"
dd if=/dev/zero of=$R_FILE bs=1000k count=10

done

Seems like they're just writing 10 megs of blocks to the r* devices...

It all works good for all r* devices. However, 1 times out of maybe 30, there's only one particular device that will disappear. Both, the character and the block device of /dev/sybase/sybsystemdb will just disappear after the dd and it will have created a simple 10M file...

Thing is... it's random! They can't reproduce the problem. I simply do not know what to look for! Not at this point at least... Thought it could be something with the fact that the LV is only 64 megs, but then again, there's other 64 megs LV in the same VG, which don't cause the problem...

Here's some info

=========================
VOLUME GROUP INFO
=========================

--- Volume groups ---
VG Name /dev/sybase
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 43
Open LV 43
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 48639
VGDA 2
PE Size (Mbytes) 16
Total PE 48639
Alloc PE 46629
Free PE 2010
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 12451584m
VG Max Extents 778224

--- Logical volumes ---
LV Name /dev/sybase/auditdat1
LV Status available/syncd
LV Size (Mbytes) 2048
Current LE 128
Allocated PE 128
Used PV 1

LV Name /dev/sybase/sybsystemdb
LV Status available/syncd
LV Size (Mbytes) 64
Current LE 4
Allocated PE 4
Used PV 1

...etc.

--- Physical volumes ---
PV Name /dev/disk/disk118
PV Status available
Total PE 48639
Free PE 2010
Autoswitch On
Proactive Polling On


=========================
LOGICAL VOLUME INFO
=========================

--- Logical volumes ---
LV Name /dev/sybase/sybsystemdb
VG Name /dev/sybase
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 64
Current LE 4
Allocated PE 4
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/disk/disk118 4 4

--- Logical extents ---
LE PV1 PE1 Status 1
00000 /dev/disk/disk118 30808 current
00001 /dev/disk/disk118 30809 current
00002 /dev/disk/disk118 30810 current
00003 /dev/disk/disk118 30811 current

Any clues, suggestions has to where / what to look for??? Also, to "wipe" a raw device like this... is dd really "the way to go" ?

Anything will help... really!

[TTr · Accepted solution]

Yes, dd and /dev/zero are very commonly used to wipe out disk headers.
One way I can see this happening is if the /dev/zero somehow is NOT a special file but a regular file. Try adding code before the "dd" command to check if /dev/zero is indeed a special file as expected. Another way is if somehow when the system cal is made to open the /dev/vgsybase/sybsystemdb somehow (a bug) it also comes back as a regular file (your code actually does check for it). Check if there are any LVM patches or special file patches.

[PatRoy]

Closed