Date: Tue, 29 Nov 2011 13:58:16 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? Message-ID: <1401883450.20111129135816@serebryakov.spb.ru> In-Reply-To: <201111290639.pAT6dWbq073934@chez.mckusick.com> References: <469709203.20111127152739@serebryakov.spb.ru> <201111290639.pAT6dWbq073934@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Kirk. You wrote 29 =ED=EE=FF=E1=F0=FF 2011 =E3., 10:39:32: > The FSYNC flag is useful. Most write requests are being done in > background, so the delay is not an issue. But there are some write > requests where the application is waiting and in those cases > minimizing the delay is necessary and important. Yep. So, maybe we record this as conclusion from discussion and FS guys (you? Kostik?) add this (FSYNC flag fro "struct buf" in case of true FSYNC request) to TODO list? It doesn't look as much work for person, who understand FFS codebase well. > That said, delaying for 5 minutes would be unacceptable. Users do > expect their data to be stable within a "reasonable" amount of time. > Historically "reasonable" has been defined as within 30 seconds of > having been written. Thus delaying a write acknowledgement for more > than about 30 seconds would not be considered acceptable (though SU > would be able to handle such a delay). Ok, I got it. 30 seconds is much better than nothing :) And, I think, it is possible to allow user to set this timeout higher, with BIG WARNING in manual page, as SU code will not break immediately. It is sad, that it is impossible to do true write cache, which will report requests as complete after copying it into cache, even with help of UPS, but it seems to be sad true :( I've understood, that it is impossible to have robust software cache data-wise (crash could kill data in cache, for sure), but it is something new for me, that it is impossible to guarantee easy-recoverable FS structures in such case even in cooperation with FS itself :( --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1401883450.20111129135816>