SUMMARY: strange UFS-behaviour

Hi.

It seems we lost our filesystem, probably by a bug in the ufs-code,
maybe it's a hardwareproblem (scsi-connectors?), I didn't found out. At
the moment I'm rolling back our backup, which is better than nothing.

Anyway thanks for all of your responses:
- Some of you supposed a rootkit. I didn't think that was the problem.
First the developer of a rootkit won't make the complete content of a
directory vanishing (except it's a special dir with his stuff, but then
he will hide the directory itself!), second we did not observe any
unsusual network traffic or open ports, third we are behind a strong
company-firewall.

- there were no "overlay" mounts either. I unmounted the filesystem and
was not able to mount it again (whatever mountpoint I choosed):
IO-Error ...

so I definitely had a corrupt filesystem. Logging and Raid5 didn't save
my data :-(
fsck was NOT able to repair the filesystem either but was quitting with
error number 39:
-- snipp --
# fsck /dev/md/dsk/d55
** /dev/md/rdsk/d55
** Last Mounted on /var/something
** Phase 1 - Check Blocks and Sizes
newshadowclient: cannot malloc client array
# echo $?
39
-- snapp --

I equipped an old D1000 with some 146G drives and made a zpool (which I
should have done much earlier). Now the restore goes to this pool.

Greetings
Jan Dreyer


Jan Dreyer wrote:
> Hi @ll,
> 
> I watched a strange behaviour on one of our production servers (Solaris 
> 10u4).
> I have a DiskSuite-RAID5 mounted on, say, /var/something.
> After moving /var/something/subdir1 into /var/something/subdir2 our 
> /var/something vanished. Sort of ...
> 
> --snipp--
> # cd /var/something
> # pwd
> /var/something
> # ls -al
> total 0
> # # strange: . and .. are missing
> # cd subdir2
> # ls -al
> total 1358
> drwxrwxr-x   5 root     root         512 Feb 13 11:43 .
> drwxrwxrwx   0 user     group        512 Feb 13 11:43 ..
> drwxrwxr-x   3 user     group        512 Feb 13 11:43 subdir1
> [...]
> # mount|grep /var/something
> /var/something on /dev/md/dsk/d55 
> read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1540037 
> on Thu Jan 24 10:32:03 2008
> # metastat d55
> d55: RAID
>      State: Okay
>      Interlace: 32 blocks
>      Size: 860019840 blocks (410 GB)
> Original device:
>      Size: 860024544 blocks (410 GB)
>          Device     Start Block  Dbase        State Reloc  Hot Spare
>          c0t2d0s0       6090        No         Okay   Yes
>          c0t3d0s0       6090        No         Okay   Yes
>          c1t6d0s0       6090        No         Okay   Yes
>          c1t7d0s0       6090        No         Okay   Yes
> 
> Device Relocation Information:
> Device   Reloc  Device ID
> c0t2d0   Yes    id1,ssd@w2000000c5028c25f
> c0t3d0   Yes    id1,ssd@w2000000c5028c3aa
> c1t6d0   Yes    id1,ssd@w2000000c5028bfbe
> c1t7d0   Yes    id1,ssd@w2000000c5028c067
> -- snapp --
> 
> So everything seems ok, except that I can't see the directory-listing.
> fsdb gives me this:
> -- snipp --
> /dev/md/dsk/d55 > :ls
> /:
> ./              subdir2/
> ../             lost+found/
> -- snapp --
> 
> Anybody here who can advice me what to do? I fear to execute fsck 
> because the data on the disk is extremly valuable and tough there exists 
> a backup it's > 24h old and thats too much ...
> 
> As we watched this not the first time (the other were on the system disk 
> with Sol9 and we re-installed ...), I assume it may be a ufs-bug?
> 
> Thanks in advance ...
> Jan Dreyer
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers