Date: Tue, 26 Oct 2004 21:34:09 +0400 From: Pavel Merdine <freebsd-fs@merdin.com> To: Xin LI <freebsd-fs@freebsd.org> Subject: Re[2]: panic again Message-ID: <1357841854.20041026213409@merdin.com> In-Reply-To: <20041026163601.GA2172@frontfree.net> References: <1038372273.20041026140339@merdin.com> <20041026163601.GA2172@frontfree.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello , Tuesday, October 26, 2004, 8:36:01 PM, you wrote: > Hello, Pavel, > First off, I'm sorry to hear your terrible story. Really? I thought I'm not the only one. ... >> Oct 26 05:11:54 images8 /kernel: panic: ffs_valloc: dup alloc >> Oct 26 05:11:54 images8 /kernel: >> Oct 26 05:11:54 images8 /kernel: syncing disks... 49 12 >> Oct 26 05:11:54 images8 /kernel: done > It's wrong to use dd'ed disk IMHO. A better solution for your situation > might be: I think it's ok in my case, because the drive has no read errors. I dont know why, but it works slowly and causes NFS slowness in it's turn. Maybe it has not a full failure, just a cable, we didn't investigate the problem yet. I now realised that I should have checked the copy first. It looks like working now. ... >> My question is: Is there any future in FFS, it's panics and >> non-working softupdates? > Frankly, the ONLY way to guarantee data integrity is more backups. > How can you expect your operating system to run correctly when it is > running on defective hardware? Sorry, I didn't explain my point thoroughly. I meant non-working softupdates on non-faulty hardware. Press "Reset" on busy server with many drives, mount -f (softupdates mount?) and you will surely get a panic in an hour. >> I dont see any reliability in such system. >> But what I remember is high reliability of MS NTFS. I didn't see any >> disk checks after any failure and I didn't experience a file loss. >> And I didn't see it's popular "blue screen" with an error caused by >> filesystem code. > Accusing other systems is not what we feel beneficial because we don't > sell FreeBSD, and our interest is to improve *our* system and make it > even better. Nothing but backup can guarantee that you survive from a > hardware failure. I wrote that to prove the fact that it's possible to have a reliable filesystem. > The intention of panic() in our code is to stop the operating system > before it can make more damage. We feel that your data is more important > than "pretending to work" but silently damage your data. I know that. But my opinion after looking at the code is that panic()'s are used even in cases when error can be fixed or reported to higher level. Maybe I'm wrong, but NTFS case confirms that it's possible to have no panics in reality. Again, somehow after a panic on ONE file system, other filesystems are not fully synced. The system conplaints that they are dirty after restart. So it seems like one panic lead to corruption of another systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing each time. Background fsck does not work in reality as well, because the system can panic thousand times before errors are fixed. >> I think that FreeBSD has no future without a reliable FS and clean >> code for it. > There are many efforts focusing the storage system and file system, while > we still need more manpower to work on it. What kind of manpower? ... >> Sorry if I wrote too long letter. Our company is just tired of the >> problems related to all of this. > User experience is important, but again, we need more details, manpower. I'm not sure if it is possible to do anything with FFS at all. >> And, by the way, FFS code still have a divide by integer error in >> dirpref(). I tried to report it two times, I saw it reported in >> lists, but nobody cares :( . No future. > In order to get your problem tracked down, you need to provide more > information. A good start is to set a dump area (e.g. if your swap There is no need to track it down. I already described the problem in freebsd-stable. If you look at dirpref(), it becomes clear that 32 bit numbers cannot be used for calculation. I saw a discussion about that in some list on google. ... > Cheers, Thanks. -- / Pavel Merdine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1357841854.20041026213409>