I *had* a working NAS configured with one 1,5 TB drive. However, it does not recognize the /usr partition according to the RAID error code. It does recognize and boot off the drive, so I think that an OS reload would ultimately get me my free space -- but as I would be BOFH'ing myself, I'd rather not try that until all is clearly lost. The RAID manufacturer does not provide utilities for debugging/dumping data, so any tools/solutions I come up with would be external.
I was able to connect the drive via a USB adapter to my FreeBSD laptop for analysis. I think I still have data on it, but I cannot seem to mount the 3rd partition, which would be /usr:
This is my system -- 8.2-STABLE, rebuilt my kernel last week to get VirtualBox updated:
This is the same error I get for the first partition (/), and as it boots off that, I know that it may not be a bad partition, but most likely is something I am doing or not doing:
and it looks like a regular linux RAID.
and the partition 0xFD is a Linux software RAID, which makes sense.
If I run tune2fs against that device, I get:
Any idea why, with the Inode size being 128, I can't mount this? Is there any way that I can recover the files on the 3rd partition? If I can just get to them by inode, I can write a script or something to recover what I need and move on.
I do have ex2fs loaded:
and the dmesg where the drive is added:
I'm guessing the warning that appears in /var/log/messages has a lot to do with my problem.
Any suggestions as to what I should do?
I was able to connect the drive via a USB adapter to my FreeBSD laptop for analysis. I think I still have data on it, but I cannot seem to mount the 3rd partition, which would be /usr:
Code:
poot# mount -t ext2fs /dev/da1s3 /mnt
mount: /dev/da1s3 : Invalid argumentThis is my system -- 8.2-STABLE, rebuilt my kernel last week to get VirtualBox updated:
Code:
poot# uname -a
FreeBSD poot.rtfmcomputing.com 8.2-STABLE FreeBSD 8.2-STABLE #4: Sun Jan 22 10:12:14 CST 2012 root@poot.rtfmcomputing.com:/usr/obj/usr/src/sys/GENERIC amd64This is the same error I get for the first partition (/), and as it boots off that, I know that it may not be a bad partition, but most likely is something I am doing or not doing:
Code:
poot# mount -t ext2fs /dev/da1s1 /mnt/usb
mount: /dev/da1s1 : Invalid argument
Code:
poot# fdisk /dev/da1
******* Working on device /dev/da1 *******
parameters extracted from in-core disklabel are:
cylinders=182401 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=182401 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 253 (0xfd),(unknown)
start 63, size 3919797 (1913 Meg), flag 0
beg: cyl 0/ head 1/ sector 1;
end: cyl 243/ head 254/ sector 63
The data for partition 2 is:
sysid 253 (0xfd),(unknown)
start 3919860, size 514080 (251 Meg), flag 0
beg: cyl 244/ head 0/ sector 1;
end: cyl 275/ head 254/ sector 63
The data for partition 3 is:
sysid 253 (0xfd),(unknown)
start 4433940, size 2925838125 (1428631 Meg), flag 0
beg: cyl 276/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 4 is:
<UNUSED>and the partition 0xFD is a Linux software RAID, which makes sense.
If I run tune2fs against that device, I get:
Code:
tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: d55f70b0-7787-4323-b4ef-27ecb281d5b9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 182878208
Block count: 365729765
Reserved block count: 0
Free blocks: 3965090
Free inodes: 180201500
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 936
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Wed Feb 10 04:37:18 2010
Last mount time: Thu Sep 22 17:22:03 2011
Last write time: Thu Sep 22 17:22:03 2011
Mount count: 38
Maximum mount count: 31
Last checked: Wed Feb 10 04:37:18 2010
Check interval: 15552000 (6 months)
Next check after: Mon Aug 9 05:37:18 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group wheel)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 43c1c77a-757f-4335-89ed-591bf0f6f351
Journal backup: inode blocksAny idea why, with the Inode size being 128, I can't mount this? Is there any way that I can recover the files on the 3rd partition? If I can just get to them by inode, I can write a script or something to recover what I need and move on.
I do have ex2fs loaded:
Code:
poot# kldstat
Id Refs Address Size Name
1 20 0xffffffff80100000 de1c60 kernel
2 1 0xffffffff80ee2000 25268 snd_hda.ko
3 2 0xffffffff80f08000 75890 sound.ko
4 1 0xffffffff80f7e000 4c070 vboxdrv.ko
5 1 0xffffffff80fcb000 52d8 atapicam.ko
6 1 0xffffffff81012000 1dea8 linux.ko
7 1 0xffffffff81030000 b760 ext2fs.koand the dmesg where the drive is added:
Code:
ugen1.2: <JMicron> at usbus1
umass1: <MSC Bulk-Only Transfer> on usbus1
umass1: SCSI over Bulk-Only; quirks = 0x4000
umass1:3:1:-1: Attached to scbus3
da1 at umass-sim1 bus 1 scbus3 target 0 lun 0
da1: <ST315003 41AS > Fixed Direct Access SCSI-2 device
da1: 40.000MB/s transfers
WARNING: mount of da1s3 denied due to unsupported optional featuresI'm guessing the warning that appears in /var/log/messages has a lot to do with my problem.
Code:
Jan 31 00:08:28 poot kernel: WARNING: mount of da1s3 denied due to unsupported optional featuresAny suggestions as to what I should do?
