search for: findsup

Hi list this is actually a problem on a debian system but I thought you might be interested to hear of it and perhaps can offer some help. I have a woody box (dell pe750, dual cpu) running a kernel from backports.org (debian 'testing' packages built on a 'stable' box). The kernel version is 2.6.7-1.backports.org.1. This host is hooked up to an Apple Xserve RAID with a 2.3Tbyte

Hi all, Somehow I managed to mess with a RAID array containing an ext3 partition. Parenthesis, if it matters: I disconnected physically a drive while the array was online. Next thing, I lost the right order of the drives in the array. While trying to re-create it, I overwrote the raid superblocks. Luckily, the array was RAID5 degraded, so whenever I re-created it, it didn't go into sync;

Hi, One of my shared volumes crashed the other day on a RH-7.2, 2.4.9-31 system. These are the first errors in the log: kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in directory #2424833: rec_len is smaller than minimal - offset=0, inode=2553887680, rec_len=0, name_len=0 kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in directory #2424833: rec_len is

...was corrupted. I'm tempted to make it an "undocumented" feature, since I suspect it will do more harm than good in most cases. "-S" should at least call check_plausibility() and proceed_question() before clobbering the filesystem. Better would be something like the "findsuper" utility in the e2fsprogs sources (attached here for your conveniece). Usually in cases like this the problem is actually something with the partition table, and not that all of your backup superblocks have mysteriously been corrupted at the same time. Cheers, Andreas > The following i...

I am reporting this on the advice of the Fedora Users Mailing List Member. This the mailing list exchange outlining the problem with specifying -S to mkfs, and it's subsequent consequences when fsck is run. I am reporting this per suggestions made to me on the Fedora Users Mailing List. The following is the mailing list exchange: On 09/18/2014 07:01 PM, Robert Nichols wrote: > On

...tempted to make it an "undocumented" feature, > since I suspect it will do more harm than good in most cases. "-S" > should at least call check_plausibility() and proceed_question() before > clobbering the filesystem. > > Better would be something like the "findsuper" utility in the e2fsprogs > sources (attached here for your conveniece). Usually in cases like this > the problem is actually something with the partition table, and not that > all of your backup superblocks have mysteriously been corrupted at the > same time. > > Cheers,...

Hello, I had a scientific linux 3.0.4 system (rhel compatible), with 3 ide disks, one for / and two others in linear raid (250 gb and 300 gb each). This system was obsoleted so i move the raid disks to a new scientific linux 3.0.7 installation. However, the raid array was not detected ( I put the disks on the same channels and same master/lsave setup as in the previous setup). In fact