July 8, 200916 yr Hi, I have a Bubbaraid 4.4 unraid server, which now claims that my last disk (1TB) is not formatted. See below for an explanation of what happened before... This 1TB disk is attached to a SATA card, and mounted in a hotswap bay. This morning, I added a used 250GB drive (but new to unraid) by hotplugging it into the bay, without stopping the unraid array . To my horror, this action messed up the array layout completely! I had expected that the drive ID, being unknown, would prevent it from being mounted or otherwise affecting the array. I removed that 250GB, and restarted the array. Turns out that the parity needed to be recalculated, but I stopped that immediately. What can I do to preserve as much of my 1TB drive that is now "unformatted"? Thanks, Mark
July 8, 200916 yr there shouldn't be any data lost at all unless you have pressed format, if you havn't yet DON'T... probably the best thing to do would be to just try restarting the computer if it is still showing as unformated, try unassigning it from the devices page, restart, reassign, and see how you go then, once it's come back into the array all good and data is available, do a parity check asap
July 8, 200916 yr Author Hmm, a reboot did not do the trick. If I turn the "unformatted" drive off (take it out of the array), there are too much drives missing (parity + 1 data), and the array will not start: "Restore will initialize the stored array configuration; all drives will appear as New, but data disk contents are not affected." Still not sure what to do EDIT: just did another entire cycle of remove disk, reboot, add disk, start raid. Still unformatted. Can I use the parity drive to recover data on the "unformatted" disk? A parity sync was started twice, it ran about a minute, each.
July 8, 200916 yr Hmm, a reboot did not do the trick. If I turn the "unformatted" drive off (take it out of the array), there are too much drives missing (parity + 1 data), and the array will not start: "Restore will initialize the stored array configuration; all drives will appear as New, but data disk contents are not affected." Still not sure what to do EDIT: just did another entire cycle of remove disk, reboot, add disk, start raid. Still unformatted. Can I use the parity drive to recover data on the "unformatted" disk? A parity sync was started twice, it ran about a minute, each. First thing... Do not press the Format button... (needed to be repeated again, even though it was said already) Second... Do not press "Restore" unless explicitly asked to by an experienced user as part of a "trust my disk" process... If you were to press it and just start the array you will lose the data on the disk showing unformatted. Then, please post a copy of your syslog. We need to be absolutely certain the new disk you were attempting to add is not being mistaken for your parity disk, so remove it physically from the array until it is back up and running properly. A file-system check of the disk showing unformatted is probably a good first step. It can usually repair any file-system damage. We can give more detailed instructions once we know the specific disks and devices involved. (post the syslog copy) If you think you know enough to identify the disk and device, the general instructions are in the wiki here: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems Joe L.
July 8, 200916 yr Author Thanks Joe, Wouldn't I need to have parity synced when I take out the "unformatted" drive? So, do you mean that I should take it out, have parity recalculated, and then proceed? Just want to make sure I understand, before I go on with this... BTW, The drive should be md6. I get this: root@unraid:~# reiserfsck /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md6 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/md6. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. The syslog is attached.
July 8, 200916 yr Thanks Joe, Wouldn't I need to have parity synced when I take out the "unformatted" drive? So, do you mean that I should take it out, have parity recalculated, and then proceed? Just want to make sure I understand, before I go on with this... Please wait while I try to figure out what is happening by looking in your syslog. Do not attempt to fix the disk just yet... We want to know what has happened before we do something that cannot be un-done. Joe L.
July 8, 200916 yr Please post the output of the following 4 commands: First, to ensure we have the disks configured as expected: cat /boot/config/disk.cfg Then, to see what was actually mounted: mount Then, (I'm thinking that disk6 did not get mounted, but we'll see. I'm fairly sure you have disk6 assigned from device /dev/sda so I want to verify its partitioning) fdisk -l /dev/sda To see if the partition type is as expected vol_id /dev/sda1 None of these commands write to the disk, so all are safe to run. Note the argument to fdisk is /dev/sda, while the argument to vol_id is /dev/sda1 (with a trailing "1" to indicate the first partition)
July 8, 200916 yr That is a Promise card that the drive is attached to, on the PCI bus with 4 SATA300 ports and no support for NCQ, so is almost certainly a TX4 with a SiI3114 chipset. It is my understanding that hotplugging is part of the *potential* promise of SATA, but is not yet ready, except possibly on very recent and expensive disk controller cards, certainly not on older cards like this Promise. I would not even try to plug a drive in with the array stopped, only with the equipment powered off. Sorry. I'll be happy to be corrected by the more knowledgeable users here. For now, I would consider your 'hotplug' bays as 'coldplug' bays, and enjoy the installation convenience they give you, but not their hotplug potential. Having said that, I too would not have expected it to harm *other* attached drives, the way this one has apparently harmed your Samsung 1TB. It looks like you have some serious reiserfsck work to be done, hopefully just the rebuild of the superblock. Thankfully, the damage should only be at the very beginning of the drive, and your data should be safe.
July 8, 200916 yr This will sound weird, but if you go to the "Devices" page, what do you show for disk6? Also, could you run the following commands so we can see the output. ls -l /dev/disk/by-path ls -l /dev/disk/by-id ls -l /dev/sd* I can see the disk6 in the syslog, but I think it is in your config/diisk.cfg expected to be at the following PCI hardware controller: pci-0000:01:02.0-scsi-0:0:0:0 (sda) ata-SAMSUNG_HD103UJ_S13PJ1BQ611791 If you somehow moved it, to different a different hardware slot, it is still trying to mount the old slot, and finds it missing? I'm just guessing so far... still trying to get all the clues needed to figure out what happened... (RobJ... feel free to assist too...) Joe L.
July 8, 200916 yr I think you were right to ask for more info, especially the fdisk info, to confirm what we actually have. Information here is somewhat limited, to what is in the most recent syslog, the comments made, and the reiserfsck result, but I *believe* the drive is fine except for the first track or 2, which was probably altered/overwritten by the 'hotplug' failure. It has one partition, and unRAID was happy with it, until it tried to mount a Reiser file system on it, and could not identify one, because of the missing superblock. Disk 6 was apparently unassigned per an earlier instruction, so appears Missing initially, then was re-assigned and unRAID appeared completely happy with it. When the array was Started, a parity sync began immediately, but was aborted in 7 seconds (that was fast, Radiopaque!). He indicated that earlier it may have run for about a minute, but it still seems to me as if the damage from all causes only affects the earliest tracks. Since it could not 'find' a file system, this is one time that it is correct to identify the partition as 'Unformatted', which *we* know is wrong, but technically is correct here. Once we see the fdisk results to confirm correct partitioning, and nothing unusual occurs in the results of the other commands requested, then "reiserfsck --rebuild-sb /dev/md6" should be the next step. Then retest with "reiserfsck /dev/md6" and go from there. It may need more reiserfsck commands. And finally a full parity check should clean up any remaining corrupted parity info.
July 8, 200916 yr I think you were right to ask for more info, especially the fdisk info, to confirm what we actually have. Information here is somewhat limited, to what is in the most recent syslog, the comments made, and the reiserfsck result, but I *believe* the drive is fine except for the first track or 2, which was probably altered/overwritten by the 'hotplug' failure. It has one partition, and unRAID was happy with it, until it tried to mount a Reiser file system on it, and could not identify one, because of the missing superblock. Disk 6 was apparently unassigned per an earlier instruction, so appears Missing initially, then was re-assigned and unRAID appeared completely happy with it. When the array was Started, a parity sync began immediately, but was aborted in 7 seconds (that was fast, Radiopaque!). He indicated that earlier it may have run for about a minute, but it still seems to me as if the damage from all causes only affects the earliest tracks. Since it could not 'find' a file system, this is one time that it is correct to identify the partition as 'Unformatted', which *we* know is wrong, but technically is correct here. Once we see the fdisk results to confirm correct partitioning, and nothing unusual occurs in the results of the other commands requested, then "reiserfsck --rebuild-sb /dev/md6" should be the next step. Then retest with "reiserfsck /dev/md6" and go from there. It may need more reiserfsck commands. And finally a full parity check should clean up any remaining corrupted parity info. I'm not so sure... I don't think disk6 is in the MD array, and reiserfsck would have nothing to work on at all. Look at the modprobe line: Jul 8 10:25:17 unraid emhttp: shcmd (4): modprobe md-mod super=/boot/config/super.dat slots=8,80,8,16,8,64,8,48,33,64,33,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Only 6 disks were listed. Parity + 5 data disks. Disk6 was not added to the MD array when the array was started. It is showing it is un-formatted because there is no disk attached to the "md" device via the modprobe line that instantiated it. I see in the above line.. major/minor device IDs. 8,80 parity 8,16 disk1 8,64 disk2 8,48 disk3 33,64 disk4 33,0 disk5 This is then also shown in the list of disks that is "imported" Jul 8 10:25:17 unraid kernel: md: import disk0: [8,80] (sdf) SAMSUNG HD103SI S1VSJ90S510253 offset: 63 size: 976762552 Jul 8 10:25:17 unraid kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103SI S1VSJ90S510284 offset: 63 size: 976762552 Jul 8 10:25:17 unraid kernel: md: import disk2: [8,64] (sde) SAMSUNG HD103SI S1VSJ90S510282 offset: 63 size: 976762552 Jul 8 10:25:17 unraid kernel: md: import disk3: [8,48] (sdd) WDC WD2500JD-00FYB0 WD-WMAEH1989630 offset: 63 size: 244198552 Jul 8 10:25:17 unraid kernel: md: import disk4: [33,64] (hdf) ST3300631A 5NF16XBD offset: 63 size: 293036152 Jul 8 10:25:17 unraid kernel: md: import disk5: [33,0] (hde) HDS722525VLAT80 VN693ECFF69M8D offset: 63 size: 244198552 Jul 8 10:25:17 unraid kernel: md: disk6 missing Notice, disk6 is missing... Not because it has no file-system, but because it was not on the "modprobe" line. However, I think it still exists in the super.dat file superblock, and probably still in the config/disk.cfg, so unRAID is complaining when it can't access a file-system on it. I suspect the PCI device has changed, and it no longer matches that in config/disk.cfg. (But that is just a guess) I don't know if in the syslog we are shown the major/minor device number of the disks found as it initially scans the hardware and assigns controllers/disks. I need to see if I can figure that out. That is why I want to see the output of the three "ls" commands. They would show the actual major/minor device numbers vs. what he has in the disk.cfg file. I suspect something is out-of-sync between them. if he wished, he could try a reiserfsck of reiserfsck /dev/sda1 Now, it is currently outside of the array, so you would not want to do any repair on it using reiserfsck initially. I'd wait till we get it back as part of the array, and on the modprobe line, so we can do the reiserfsck on /dev/md6. Joe L.
July 8, 200916 yr Thinking about it, if it is a simple as the disk being on different PCI hardware, it might be possible to stop the array, go to the "devices" page, and then "assign" disk 6. If it has moved to a different PCI device (as I am guessing), then it might just be there in the dropdown waiting to be assigned. Then, you could go to the main page and start the array. It might even be possible to then use the "trust" process... but only if all the disks are present and none show "unformatted" Edit: Not the solution... later in the syslog, disk6 was assigned to the slot in the array. Joe L.
July 8, 200916 yr I'm an idiot... I did not look at the end of the syslog... I was looking earlier in the syslog where disk6 was missing. At the end of the syslog, disk6 is then properly added to the array. Jul 8 10:26:48 unraid emhttp: shcmd (15): modprobe md-mod super=/boot/config/super.dat slots=8,80,8,16,8,64,8,48,33,64,33,0,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Jul 8 10:27:03 unraid kernel: md: import disk0: [8,80] (sdf) SAMSUNG HD103SI S1VSJ90S510253 offset: 63 size: 976762552 Jul 8 10:27:03 unraid kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103SI S1VSJ90S510284 offset: 63 size: 976762552 Jul 8 10:27:03 unraid kernel: md: import disk2: [8,64] (sde) SAMSUNG HD103SI S1VSJ90S510282 offset: 63 size: 976762552 Jul 8 10:27:03 unraid kernel: md: import disk3: [8,48] (sdd) WDC WD2500JD-00FYB0 WD-WMAEH1989630 offset: 63 size: 244198552 Jul 8 10:27:03 unraid kernel: md: import disk4: [33,64] (hdf) ST3300631A 5NF16XBD offset: 63 size: 293036152 Jul 8 10:27:03 unraid kernel: md: import disk5: [33,0] (hde) HDS722525VLAT80 VN693ECFF69M8D offset: 63 size: 244198552 Jul 8 10:27:03 unraid kernel: md: import disk6: [8,0] (sda) SAMSUNG HD103UJ S13PJ1BQ611791 offset: 63 size: 976762552 Jul 8 10:27:03 unraid emhttp: shcmd (22): mount -t reiserfs -o noatime,nodiratime /dev/md6 /mnt/disk6 >/dev/null 2>&1 Jul 8 10:27:03 unraid kernel: ReiserFS: md6: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on md6 With this, I agree with RobJ, let's see what the partitioning looks like, then a file-system check rebuilding the superblock on /dev/md6 is in order. Joe L.
July 8, 200916 yr Author This will sound weird, but if you go to the "Devices" page, what do you show for disk6? It shows this: disk6 device: pci-0000:01:02.0-scsi-0:0:0:0 (sda) ata-SAMSUNG_HD103UJ_S13PJ1BQ611791 The output of the commands is below: Linux 2.6.27.7-unRAID-Bubba. root@unraid:~# cat /boot/config/disk.cfg # Disk configuration spindownDelay=8 parity=pci-0000:00:1f.2-scsi-1:0:1:0 disk1=pci-0000:00:1f.2-scsi-0:0:0:0 disk2=pci-0000:00:1f.2-scsi-1:0:0:0 disk3=pci-0000:00:1f.2-scsi-0:0:1:0 disk4=pci-0000:00:1f.1-ide-0:1 disk5=pci-0000:00:1f.1-ide-0:0 disk6=pci-0000:01:02.0-scsi-0:0:0:0 diskSpindownDelay.0=-1 diskSpindownDelay.1=-1 diskSpindownDelay.2=-1 diskSpindownDelay.3=-1 diskSpindownDelay.4=-1 diskSpindownDelay.5=-1 diskSpindownDelay.6=-1 root@unraid:~# mount fusectl on /sys/fs/fuse/connections type fusectl (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/sdc1 on /boot type vfat (rw,umask=000,shortname=mixed) /boot/bubba/portal/bubba_portal.fs on /var/www type ext3 (rw,loop=/dev/loop0) /dev/md3 on /mnt/disk3 type reiserfs (rw,noatime,nodiratime) /dev/md5 on /mnt/disk5 type reiserfs (rw,noatime,nodiratime) /dev/md4 on /mnt/disk4 type reiserfs (rw,noatime,nodiratime) /dev/md2 on /mnt/disk2 type reiserfs (rw,noatime,nodiratime) /dev/md1 on /mnt/disk1 type reiserfs (rw,noatime,nodiratime) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev) nfsd on /proc/fs/nfs type nfsd (rw) root@unraid:~# fdisk -l /dev/sda Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 2 31008336 976762552+ 83 Linux Partition 1 does not end on cylinder boundary. root@unraid:~# vol_id /dev/sda1 /dev/sda1: unknown volume type root@unraid:~# ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.1-ide-0:0 -> ../../hde lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.1-ide-0:0-part1 -> ../../hde1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.1-ide-0:1 -> ../../hdf lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.1-ide-0:1-part1 -> ../../hdf1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.2-scsi-0:0:1:0 -> ../../sdd lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.2-scsi-0:0:1:0-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sde lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.2-scsi-1:0:0:0-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:00:1f.2-scsi-1:0:1:0 -> ../../sdf lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:00:1f.2-scsi-1:0:1:0-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 pci-0000:01:02.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 8 10:25 pci-0000:01:02.0-scsi-0:0:0:0-part1 -> ../../sda1 root@unraid:~# ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-HDS722525VLAT80_VN693ECFF69M8D -> ../../hde lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-HDS722525VLAT80_VN693ECFF69M8D-part1 -> ../../hde1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510253 -> ../../sdf lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510253-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510282 -> ../../sde lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510282-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510284 -> ../../sdb lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-SAMSUNG_HD103SI_S1VSJ90S510284-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-SAMSUNG_HD103UJ_S13PJ1BQ611791 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-SAMSUNG_HD103UJ_S13PJ1BQ611791-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-ST3300631A_5NF16XBD -> ../../hdf lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-ST3300631A_5NF16XBD-part1 -> ../../hdf1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 ata-WDC_WD2500JD-00FYB0_WD-WMAEH1989630 -> ../../sdd lrwxrwxrwx 1 root root 10 Jul 8 10:25 ata-WDC_WD2500JD-00FYB0_WD-WMAEH1989630-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510253 -> ../../sdf lrwxrwxrwx 1 root root 10 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510253-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510282 -> ../../sde lrwxrwxrwx 1 root root 10 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510282-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510284 -> ../../sdb lrwxrwxrwx 1 root root 10 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103SIS1VSJ90S510284-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103UJS13PJ1BQ611791 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 8 10:25 scsi-SATA_SAMSUNG_HD103UJS13PJ1BQ611791-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 scsi-SATA_WDC_WD2500JD-00WD-WMAEH1989630 -> ../../sdd lrwxrwxrwx 1 root root 10 Jul 8 10:25 scsi-SATA_WDC_WD2500JD-00WD-WMAEH1989630-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Jul 8 10:25 usb-OCZ_ATV_AA04012700141765-0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Jul 8 10:25 usb-OCZ_ATV_AA04012700141765-0:0-part1 -> ../../sdc1 root@unraid:~# ls -l /dev/sd* brw-rw---- 1 root disk 8, 0 Jul 8 10:25 /dev/sda brw-rw---- 1 root disk 8, 1 Jul 8 10:25 /dev/sda1 brw-rw---- 1 root disk 8, 16 Jul 8 10:25 /dev/sdb brw-rw---- 1 root disk 8, 17 Jul 8 10:25 /dev/sdb1 brw-rw---- 1 root plugdev 8, 32 Jul 8 10:25 /dev/sdc brw-rw---- 1 root plugdev 8, 33 Jul 8 10:25 /dev/sdc1 brw-rw---- 1 root disk 8, 48 Jul 8 10:25 /dev/sdd brw-rw---- 1 root disk 8, 49 Jul 8 10:25 /dev/sdd1 brw-rw---- 1 root disk 8, 64 Jul 8 10:25 /dev/sde brw-rw---- 1 root disk 8, 65 Jul 8 10:25 /dev/sde1 brw-rw---- 1 root disk 8, 80 Jul 8 10:25 /dev/sdf brw-rw---- 1 root disk 8, 81 Jul 8 10:25 /dev/sdf1 root@unraid:~#
July 8, 200916 yr Once we see the fdisk results to confirm correct partitioning, and nothing unusual occurs in the results of the other commands requested, Everything looks as expected. then "reiserfsck --rebuild-sb /dev/md6" should be the next step. Then retest with "reiserfsck /dev/md6" and go from there. It may need more reiserfsck commands. And finally a full parity check should clean up any remaining corrupted parity info. Go for the reiserfsck --rebuild-sb /dev/md6 as RobJ indicated. It might take a while, so just let it run its course. Then, follow any other suggestions it makes. Joe L.
July 8, 200916 yr Author Hm, not sure what the correct answer should be, here: root@unraid:~# reiserfsck --rebuild-sb /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/md6. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified). Is journal default? (y/n)[y]: Did you use resizer(y/n)[n]: rebuild-sb: no uuid found, a new uuid was generated (1f188973-3014-4f3e-872e-a64637c83ba9) rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: root@unraid:~# I get my prompt back, here... EDIT: Something is running now: root@unraid:~# reiserfsck --rebuild-sb --no-journal-available /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/md6. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: Did you use resizer(y/n)[n]: rebuild-sb: no uuid found, a new uuid was generated (90b7f381-d31e-4a70-9d8b-c18b5d835863) Journal was specified as not available. reiserfstune is needed. Reiserfs super block in block 16 on 0x906 of format 3.6 with standard journal Count of blocks on the device: 244190624 Number of bitmaps: 7453 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0xffffffff] Size 1 blocks (including 1 for journal header) (first block 0) Max transaction length 0 blocks Max batch size 0 blocks Max commit age 0 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: 90b7f381-d31e-4a70-9d8b-c18b5d835863 LABEL: Set flags in SB: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. root@unraid:~# root@unraid:~# reiserfsck --check /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md6 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Journal of (1) block size found on specified journal device /dev/md6. Must be not less than (513). Failed to open the journal device ((null)). Run --rebuild-sb to rebuild journal parameters. root@unraid:~# reiserfsck --rebuild-sb /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes rebuild-sb: wrong journal first block occured (0), fixed (18) rebuild-sb: wrong journal size occured (1), fixed (8193) rebuild-sb: wrong journal max transaction length occured (0), fixed (1024) rebuild-sb: wrong journal max batch size occured (0), fixed (900) rebuild-sb: wrong journal max commit age occured (0), fixed (30) rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Reiserfs super block in block 16 on 0x906 of format 3.6 with standard journal Count of blocks on the device: 244190624 Number of bitmaps: 7453 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0xffffffff] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: 90b7f381-d31e-4a70-9d8b-c18b5d835863 LABEL: Set flags in SB: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. root@unraid:~# root@unraid:~# reiserfsck --check /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md6 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Wed Jul 8 22:45:05 2009 ########### Replaying journal.. No transactions found I do not get my prompt back -- it looks like the filesystem is being scanned, but I'm a bit worried about the "No transactions found"
July 8, 200916 yr Author Not a second after my last edit: "Bad root block 0. (--rebuild-tree did not complete)" See below: root@unraid:~# reiserfsck --check /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md6 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Wed Jul 8 22:45:05 2009 ########### Replaying journal.. No transactions found Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted root@unraid:~#
July 9, 200916 yr I do not get my prompt back -- it looks like the filesystem is being scanned, but I'm a bit worried about the "No transactions found" The indicates there were no outstanding partially written files in the journal. It is a good thing, not a bad thing. It is also just informative, nothing to worry about even if it did find some transactions to replay from the journal to the file-system.
July 9, 200916 yr Author Here is the output from the last reiserfsck. It seems that indeed the information at the start is lost: root@unraid:~# reiserfsck --rebuild-tree /dev/md6 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will rebuild the filesystem (/dev/md6) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. No transactions found ########### reiserfsck --rebuild-tree started at Thu Jul 9 12:36:01 2009 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 15663 blocks marked used Skipping 15663 blocks (super block, journal, bitmaps) 0 blocks will be read Could not find a hash in use. Using "r5" "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 0 Leaves among those 0 Objectids found 2 Pass 1 (will try to insert 0 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished Flushing..finished 0 leaves read 0 inserted ####### Pass 2 ####### Flushing..finished No reiserfs metadata found. If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you have used one. Then you probably rebuilt the superblock as there was no one. Zero the block at 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfs /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version. If this makes you nervous, try www.namesys.com/support.html, and for $25 the author of fsck, or a colleague if he is out, will step you through it all. Aborted root@unraid:~# Any suggestions on my next step?
July 9, 200916 yr This post may come in handy ... http://lime-technology.com/forum/index.php?topic=1483.msg9973#msg9973
July 9, 200916 yr Author Thanks. I am running reiserfsck --scan-whole-partition --rebuild-tree /dev/md6 now, it takes a while ... EDIT: Now done. Same result as before. It does not recognize a reiserfs. Does anyone know how I can force a reiserfs onto this drive? The directions at the end of the reiserfsck run are rather cryptic to my untrained eye ...
July 9, 200916 yr Thanks. I am running reiserfsck --scan-whole-partition --rebuild-tree /dev/md6 now, it takes a while ... EDIT: Now done. Same result as before. It does not recognize a reiserfs. Does anyone know how I can force a reiserfs onto this drive? The directions at the end of the reiserfsck run are rather cryptic to my untrained eye ... What exactly did it say this time? Joe L.
July 10, 200916 yr Author It spewed out many lines of corrections, and then at the end I got this: ####### Pass 2 ####### Flushing..finished No reiserfs metadata found. If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you have used one. Then you probably rebuilt the superblock as there was no one. Zero the block at 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfs /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version. If this makes you nervous, try www.namesys.com/support.html, and for $25 the author of fsck, or a colleague if he is out, will step you through it all. Aborted root@unraid:~#
July 11, 200916 yr Author Does anyone have other ideas on what to do? I guess I could pay a visit to www.namesys.com/support.html, but if someone in this forum has done this before, I would be much obliged...
July 11, 200916 yr Does anyone have other ideas on what to do? I guess I could pay a visit to www.namesys.com/support.html, but if someone in this forum has done this before, I would be much obliged... Here's a slightly different approach. Is the drive you were going to try to add originally the same size (or bigger) than the drive that has the bad file system? If so, and if it is not larger than the parity drive, we have the possibility of attempting to use parity and the other drives to rebuild it to have a copy of the old disk6. To do this, you would not be writing to parity, and not be writing to the existing disk6, so there is not too much risk of making anything worse. The basic process is a modification of the "Trust my Parity disk" process. You would stop the array, un-assign the existing disk6, assign the new drive to the disk6 slot. Then, (read all the next steps before doing any) 1. Go back to the main page and press "Restore" (you will probably need to check the checkbox under it to enable it) 2. Before you do anything else, we need to tell unRAID that disk 6 is invalid and needs to be rebuilt. To do that log onto the system console, or log in via telnet and type: cd mdcmd set invalidslot 6 It should respond that the command was accepted OK as follows: [pre] cmdOper=set cmdResult=ok [/pre] 3. Once you have set the invalid slot as disk6, you can then go back to the main page of the unRAID web-interface and press "Start" (you will probably need to check the checkbox under it) Once you start the array, it should start to write to disk6, and read from all the other disks. If you see anything else, press "Stop" as soon as you can. Once it starts, even while rebuilding disk6, you should be able to browse to disk6 to see its contents. As long as you did not initially overwrite parity with bad contents during your initial attempts at starting the array, it should just rebuild disk6, exactly the same as if it had failed and was being replaced. Once it finishes building disk6, you might still need to run reiserfsck on it, but in the interim, you still have your original disk with the mangled file-system, and you have the new disk with what might also be able to be used to recover your files. Remember... you must issue the "mdcmd set invalidslot 6" command between pressing restore and start. Failing to do so will cause it to write to the parity drive rather than disk6... (not at all what you want in your situation) If you have any questions at all, ask them before you perform these steps. Only do this if all your other drives are working, and you are only un-assigning the old disk6 and assigning the new disk to the disk6 slot. Do not attempt to un-assign any other drives, or assign any additional drives while doing this. We need exactly the same drives in palace as when we calculated parity (with the exception of the disk6 we are replacing). Joe L.
Archived
This topic is now archived and is closed to further replies.