06-09-2010 08:34 AM
I have a MaxAttach NAS-3000 which has been sat on a network for a few years. The unit has recently given out, and although it attempts to boot, the drives appear to not get any power to them.
I have tried powering the drives with another PC's PSU, but i end up getting a solid STATUS light. I have also tried connecting the pair of disks to an old PC with IDE connectors, but it seems the Windows certainly cannot read the drives. I tried using an Ubuntu Linux setup, and while it told me a little more, it was still unable to mount the partitions.
Both drives are identical (Maxtor 81.9GB 5.4K RPM disks, and are the originals that came with the device.
I have read somewhere (possibly unreliably) that the unit runs a copy of FreeBSD, however I haven't got a clue where to start, or even if it would be any use mounting the drives in FreeBSD.
So my question is, can the data on the disks be recovered? I would be amazed if i have to accept 160GB of lost data on disks that happily work, but are formatted strangely!
Any information that could point me in the right direction would be extremely welcome!
06-10-2010 07:23 AM
EasyUser: Thanks for your reply, i tried using the knoppix live disk to examine the array with:
mdadm --examine --scan
but got absolutely nothing returned!
using /sbin/sfdisk -l which showed me the disks, each containing three partitions.
On one disk, the first and last are marked as type 0xa5 with the middle being 0x5a. On the second disk all three partitions are 0xa5. The 0xa5 is listed as FreeBSD, and the 0x5a as unknown.
In PCman i can see 4 partitions (not the expected 6).
Each disk is set up similarly, the first two partitions (195.1MB and 43.9MB) appear empty, and the third is not visible.
At this point i am a little stuck!
I have read elsewhere that the MaxAttach NAS-3000 is the same (almost) as an Intel Storage Station, but again, i haven't found any information on this.
I have tried contacting Maxtor directly, but as it's an (very) old unit, and they've since been bought by Seagate, they don't even seem to recognise it as a Maxtor product!!!
Any ideas on which way to turn?
06-11-2010 12:42 AM
EasyUser: No problem, it was certainly worth a try!!!!
So does anyone know of a source of information regarding these devices?
The problem i am having is that i can't even find out for sure what OS is running! I'm guessing FreeBSD, so if that is the case, is there any assumtions i can make regarding the disk set up?
What i can't seem to work out is, are the disks (2 * 80GB) configured as some kind of raid array, or are they managed by the software to appear to the network as a single drive? A Raid array seems the simplest way of doing this, but I'm not sure...
It seems that 0xa5 partitions were used in 386BSD, but other BSD's use 0xa6.
If these are in some kind of raid array, is there any way of telling the type?
I'm kind of clutching at straws now, it just seems amazing that i will loose years of work because of a lack of information.....and my failure to back up of course ;(
06-11-2010 01:32 AM
06-11-2010 03:05 AM
fzabkar: Amazing! It's not yet a complete solution, but you've got me further than ever!!!
It seems that the first couple of partitions mount. From that i have found /etc/fstab and managed to get the following:
Device Mount Point FSType Options Dump Pass
/dev/wd0s1b none swap sw 0 0
/dev/wd0s2a / ufs rw 1 1
/dev/wd0s2e /jfs jfs rw 2 2
proc /proc procfs rw 0 0
/dev/wd0s3e /mnt/vol1 jfs rw 2 2
/dev/wd0s2e /mnt/vol2 jfs rw 2 2
So it would seem that the larger partitions are in fact JFS. The FFS driver BSOD when i try to mount them, but they're not supported by that driver, so thats pretty much normal....
Next i tried booting to Ubuntu (10.04). It won't let me mount /dev/sda3 or /dev/sdb3 as jfs, and gives me the message:
Mount: wrong fs type, bad option, bad superblock on /dev/sda3,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
So i dmesg | tail'ed and got...
JFS: nTxBlock = 8192, nTxLock = 65536
I also attempted an fsck.jfs just in case a filesystem check would help, and got.....
The Superblock does nto describe a correct jfs filesystem.
If device /dev/sda3 is valid and contains a jfs file system,
then both the primary and secondary blocks are corrupt
and cannot be repaired, and fsck cannot continue.
So i'm back to being stuck!!!!
Free BSD uses slices as opposed to partitions. i'm not sure how that works, or if it makes a great deal of difference (just terminology?)
The unit originally showed itself to be ~160GB, so the unit must be in it's default state of two individual disks in a spanning arrangement, not the active/backup that would have been available.
I also notice that in the link to partition types, 0x5a is not even listed! I guess thats not a good sign!
So, does anyone have any further suggestions?
06-11-2010 06:21 PM
06-14-2010 03:10 AM
I think you're right that the jfs is broken due to the spanning.
I have been wondering if it would be possible to follow the BSD config files, and try to duplicate what they did to create the span.
It seems to me that the mount point /mnt/vol1 and /mnt/vol1 must be the general mount points of each part of the span, which once joined (i assume) are mounted at /jfs
It seems to me that if i could remount the two halfs, then hopefully i should be able to reinitate the jfs mount. It seems this is a software span, but i'm not sure where to look in the config (/etc)
I think an image file of each disk may be in order, just to make sure i don't damage anything in the process of trying to repair the problem.
As far as repairing the hardware goes, we do some pretty low level electronics here. I got one of the engineers to take a look at the board, and he says he doubts he could get it up and runnig again, so i think thats out...
So, the new question is, does anyone know how JFS works? I am fairly sure i could get the partitions remounted in a BSD installation, but how to bring up the JFS mount is another matter....