Date: Sat, 19 Oct 2002 23:48:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Schultz <dschultz@uclink.Berkeley.EDU>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Maxim Sobolev <sobomax@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: Patch to allow a driver to report unrecoverable write errors to the buf layer Message-ID: <3DB251D0.495C6A44@mindspring.com> References: <3DB048B5.21097613@FreeBSD.org> <28472.1035014051@critter.freebsd.dk> <20021020043706.GA23972@HAL9000.homeunix.com> <200210200457.g9K4vbAE030661@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :filesystem corruption because the vnode layer would be unaware > :that some buffers had been dropped. How hard would it be to fix this? > > Extremely difficult, which is why this is all fantasy and no action. > By the time the filesystem layer gets the notification there is > insufficient information to unwind the original operation(s) without > a huge amount of work. A bitmap write failed? Great! Find the > file that the related bitmap blocks are related to. Good luck! And > that is just one case out of dozens that would require a sophisticated > solution. It might be possible via softupdates, but I shudder at the > level of complexity of code required to support such a beast. Not to > mention the fact that pulling a floppy out a bad time could destroy > far more data then whatever pending write operations might have failed. > It's a waste of time. This really depends. Operations which are queued without the results being reaped before returning to user space doesn't necessarily mean that the results shouldn't end up going to the layer that originated the request. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB251D0.495C6A44>