After certain amount of panics and hangs, I have -- for the second time -- a filesystem, which defeats fsck: ** /dev/ad4e ** Last Mounted on /misha ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot alloc 607016868 bytes for inoinfo Fix: The first time this happened, I just re-newfsed the partition. This time it is on a bigger one, with valuable data. The FS can be mounted read-only, I'm going to try to back up, what I can and recreate it. How-To-Repeat: Not sure.
As I the tar finished and I tried to unmount the troublesome filesystem (mounted readonly) to reformat it, the OS paniced with Consumer with zero access count in g_dev_strategy When I typed `call boot(0)' in the debugger, there were 3439 buffers remaining. The system gave on 85 buffers. -mi
Greeting- I just had the exact same problem in FreeBSD 5.3. In my case it is my var partition on a just installed system. It will not FSCK using any superblock and I can not even mount the FS read only. I had softupdates off for the file system. Before the failure happened I was getting DMA write failure errors on the console for the ad0. -Brett
> Greeting- > I just had the exact same problem in FreeBSD 5.3. In my case it is > my var partition on a just installed system. It will not FSCK using any > superblock and I can not even mount the FS read only. > I had softupdates off for the file system. Before the failure > happened > I was getting DMA write failure errors on the console for the ad0. Are you using Silicon Image's SATA controller by any chance? See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/72451 As for recovering your /var, there are, apparently, a lot more superblock copies, than fsck tries automatically. To get the actual number, try newfs-ing the partition with exactly the same parameters as before, but with ``-N'' flag. This will print out the addresses of the superblocks. See if giving one of them to fsck_ufs with ``-b'' will help you recover stuff. I have not tried this personally, but it seems like you've lost your /var anyway... -mi
> > > Greeting- > > I just had the exact same problem in FreeBSD 5.3. In my case it is > > my var partition on a just installed system. It will not FSCK using any > > superblock and I can not even mount the FS read only. > > I had softupdates off for the file system. Before the failure > > happened > > I was getting DMA write failure errors on the console for the ad0. > > Are you using Silicon Image's SATA controller by any chance? See > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/72451 > > As for recovering your /var, there are, apparently, a lot more superblock > copies, than fsck tries automatically. > > To get the actual number, try newfs-ing the partition with exactly the > same parameters as before, but with ``-N'' flag. This will print out the > addresses of the superblocks. See if giving one of them to fsck_ufs with > ``-b'' will help you recover stuff. I have not tried this personally, but > it seems like you've lost your /var anyway... > > -mi > Greeting- I tried about 15 alternate superblocks to no good end. Also there is a bug in fsck(8) where it claims that the first alternate superblock is at 32, and that is where it tells fsck_ufs(8) to look, but at least on my 5.3 system the first alternate superblock is at 160. There is also another bug in fsck(8) in that it will not pass the -b SUPERBLOCKNUM on to fsck_ufs, instead it returns an error stating that -b is an illegal option. Talk about a way to confuse someone that is new to BSD! Glad I have 20 years working on BSD systems! I have reinstalled from CD rom and am in the process of reinstalling the needed ports. No user data was lost as I preserved that partition, but this problem makes me a little shy to bring the 5.3 system on line. It was to replace a solaris 2.4 running on a 486dx66, but for now the solaris will have to stay. The raid controler is an IDE unit that requires no special software. To the system it looks just like an IDE disk, and you connect 2 same size IDE disks to the control unit. The one I am using in the 5.3 system is an older unit called the ARaid99-300. If you were to want to get one today I would instead suggest the units that are made by ARCO in florida. They can be found at http://www.arcoide.com/. I have several of those units doing a fine job at various sites. BTW the systems shows the raid controler as this: ad0: 38166MB <ASI ARAID99/Rev1.14> [77545/16/63] at ata0-master UDMA33 at boot time. -Brett -- DRM is theft! We are the stakeholders! http://www.nyfairuse.org/
State Changed From-To: open->feedback Is this still a problem in 6.0-RELEASE?
State Changed From-To: feedback->open Feedback received, although feedback from the submitter is still requested.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped