by I used to have a directory named q on partition with ufs logging
turned on. Just a while ago, I typed ls -l in it's parent dir and got
something like this:
pc-alex$ ls -la
total 17953794
drwxr-xr-x 3 alex staff 512 Jun 1 11:18 .
drwxrwxrwt 8 root root 512 Apr 21 15:16 ..
?-wxrwxrw- 254 254 254 71495735022846206 Jul 12 1970 q
-rw-r--r-- 1 alex staff 669044736 May 14 15:09 redhat6.iso
"q" used to be a directory, and now it is "something"?!?!?
There was no disk crash, no system crash or anything else that could
explain this (well, ufs logging was supposed to protect me from system
crashes, right?). After I saw this, I unmounted partition, and did
manual "fsck -y". fsck reported a lot of "PARTIALLY ALLOCATED INODE
I=nnnn" (nnnn is some number) and copule of really wiered things like:
DIRECTORY CORRUPTED I=29440 OWNER=hniksic MODE=40755
SIZE=512 MTIME=Apr 2 11:54 1999
DIR=/hniksic
SALVAGE? yes
MISSING '.' I=29440 OWNER=hniksic MODE=40755
SIZE=512 MTIME=Apr 2 11:54 1999
DIR=/hniksic
FIX? yes
MISSING '..' I=29440 OWNER=hniksic MODE=40755
SIZE=512 MTIME=Apr 2 11:54 1999
DIR=/hniksic
FIX? yes
For my nice "q" directory, I got:
UNALLOCATED I=35328 OWNER=root MODE=0
SIZE=0 MTIME=Jan 1 01:00 1970
NAME=/alex/q
REMOVE? yes
This was all on Solaris 7 x86 system, patched to MU2. Did anybody
else noticed data corruption like this when using ufs logging on
Solaris 7?
Luckilly this disk is used only to temporarly store CD images. But
I'm now a bit considered how safe is my data on other partitions?
Ah, yes... on console, I also got message:
Jun 1 11:20:27 pc-alex.srce.hr Error setting up next portionof DMA transfer
????
--
Opinions expressed herein are my own.
================================ooooO=Ooooo==============================
Real Users never know what they want, but they always know when your
program doesn't deliver it.