Date: Thu, 21 Sep 2000 21:35:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: archie@whistle.com (Archie Cobbs) Cc: sos@freebsd.dk (Soren Schmidt), mbendiks@eunet.no, terry@lambert.org, fs@freebsd.org Subject: Re: disable write caching with softupdates? Message-ID: <200009212135.OAA17807@usr08.primenet.com> In-Reply-To: <200009211900.MAA18117@bubba.whistle.com> from "Archie Cobbs" at Sep 21, 2000 12:00:32 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Thanks.. I was talking about a sysctl patch, where you could > > > turn write caching on or off at any time while the system is > > > running via sysctl. Is it even possible to do that? > > > > Why on earth would you want this as a sysctl knob ? > > Either you want to play it safe, or you dont care, this is not > > something you change your mind about now and then.... > > OK, here's an example. You have an /etc/rc script that checks > at startup what kind of disk you have (eg "dmesg | grep -q QUANTUM") > and for certain disk types that are known to lie about their write > guarantees enables or disables write caching as appropriate. > > FYI I can confirm what Terry said that few disks we've encountered > guarantee atomic sector writes in the face of power failure (i.e., > leading to a corrupted/lost sector), much less flushing the entire > write cache, so IMHO the answer to.. A better reason would be "the same reason I can arbitrarily mount an FS as either sync or async". 8-). > > The _right_ solution of cause is to have the FS code pass down > > a flag that says only write this when all preceeding bufs are > > on the media, now _that_ would be nice and work for both ATA > > and SCSI devices.... > > Agreed, this is the best solution. I think it is necessary > in order to make the promise of softupdates really rigorous. Actually, this is implicit in the design of soft updates; it's what soft updates is truing to buy you. Right now, soft updates will stall (not schedule) additional writes, until it knows that preceeding writes (in an ordered dependency list) have been completed. Passing down a flag would still be useful, I think, since it would erase latencies, and permit other non-soft updates type experimentation. But for soft updates, it wouldn't help, as as soon as the buffer is scheduled, it is owned by the system, and there is an implied stall on the write pipeline, since you can't modify a dependency in the "scheduled in the buffer cache, but not scheduled by the disk driver" state. To get around this, you would have to have the concept of multiple reader/single writer locks on stuff in the buffer cache queue. You should talk to Matt Dillon and Kirk McKusick about the stall problem which occurs after the stuff gets into this state, since it's what screwed up the SAMBA concurrency benchmarks at Ziff Davis (the ones which were published for Linux and NT, but not published for FreeBSD). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009212135.OAA17807>