Date: Sun, 20 Apr 2003 02:27:43 +0200 From: Marko Zec <zec@tel.fer.hr> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <200304200227.44268.zec@tel.fer.hr> In-Reply-To: <3EA1DE82.68F32B77@mindspring.com> References: <3E976EBD.C3E66EF8@tel.fer.hr> <200304192350.48576.zec@tel.fer.hr> <3EA1DE82.68F32B77@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 20 April 2003 01:40, Terry Lambert wrote: > Marko Zec wrote: > > If you have tried the patch yourself, you would certainly observe > > that the freeze you are talking about is completely unnoticable. > > I run 13 jails for 12 virtual machines on my laptop. I noticed. :) If you are really serious about running 12 VMs on a laptop, then: a) you do not want to have this patch enabled in the first place, and b) what kind of delay exactly did you notice? > > Therefore the disk head seek latency you mentioned won't be > > noticeable in most cases. > > Define "most cases". Those where the onboard write-caching RAM on the ATA disk is large enough to compensate for disk head seek latency for the whole write burst. > > Again, in my understanding the (modified) fsync() handler is completely > > unrelated to the (unmodified) sync_fsync() function. > > You're wrong. You have to take into account both the vnodes on > the FS, and the vnodes that the FS is mounted on on devfs. Hmm, the original patch was against 4.8-R, and this whole discussion is flooding the -stable mailing list, in case you forgot. Where from did you now pull the devfs? And even with devfs, what if my patch (optionally) ignores fsync()? Does that mean that all the programs that close their files without caling fsync() are going to crash the system? Uhhh.... > > > The other FS corruption occurs because you don't specifically > > > disable the delaying code before a shutdown or umount or mount > > > -u -o ro, etc.. > > > > Such a problem simply does not exist. Please try out the patch, enable > > the delaying, fill in as much dirty buffers as possible, and unmount the > > FS. You will notice that a) all the dirty buffers will be automatically > > written to the disk; b) the unmount operation will succeed; c) the system > > will not crash and d) the FS will be perfectly consistent at the next > > mount. > > This is not true. I've proved it by corrupting an FS by holding > down the power button on my laptop to force an ATX power-off, with > no recourse. ??? You have proved what by pulling out the plug? That umount or shutdown do not work (pls. read your previous claim 10 lines above)? I do not believe to be reading this... > > No offence please, but your argumentation would look much more > > convincing if you could provoke a system crash with the patch > > enabled, and then provide a backtrace. If the patch is as bad > > as you are suggesting, that shouldn't be that hard to do, should it? > > I've done it. I guess you want me to do it again, citing that > absence of evidence is not evidence of absence? I'd simply prefer to receive a backtrace, rather than just tons of noise. An improved patch couldn't hurt either :) Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304200227.44268.zec>