Date: Thu, 17 Apr 2003 18:07:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3E9F4FE4.9B8567DC@mindspring.com> References: <200304162310.aa96829@salmon.maths.tcd.ie> <200304172143.26387.zec@tel.fer.hr> <3E9F4413.D294E69E@mindspring.com> <200304180245.53107.zec@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > On Friday 18 April 2003 02:17, Terry Lambert wrote: > > I think people would be happier if you just stopped the soft > > updates sync clock, and then if someone actually fsync()'ed, or > > the dependency list got too big, it spun up the disk, completed > > all the I/O quickly, and then spun it down again. > > The updated patch does precisely what you just described above. It already > includes a tunable vfs.ena_lazy_fsync (off by default) which allows choosing > whether blocking (standard) or null- fsync() semantics apply. Check out > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15720+0+current/freebsd-fs > :) No, you are missing my previous point: the check for free space should include a check for number of elements *TOTAL* in all slots on the soft updates timer wheel. Otherwise it can eat all of memory. The free space check only works in the case that you've done a delete and are allocating new space: the case where you are doing more and more allocations/opverwrites of data is not handled, and can grow to eat all available kernel memory. There was in fact a bug, early on, that Matt Dillon worked around that caused it under load, and it was in exactly the code you are touching. Also, the "ena_lazy_fsync" needs to be overridable, based on barriers in the dependency list: it's not acceptable to violate the POSIX semantics over trying to delay fsync(). You insert a dependency that is blocked by some other dependency already there, and you're in semantic trouble. Normally, this would be prevented by a write lock on the buffer in question, but it's not queued for write, because the wheels not moving. The "ena_lazy_fsync" is really a problem, if it permits an operation, such as the update of a database index file to point to a new record that has been written to the database data file. At this point, fsync() is used for implied contracts. The only way you can legitimately delay it is if there isn't an implied contract, which you should be able to see as a barrier in the soft update dependency list. Under what circumstances you you find that delaying fsync() helps you? What program are you running that calls fsync()? I think that maybe you are running a program (like qmail) that doesn't trust the FS to comply with POSIX, so it inserts some extra fsync()'s "just in case we are running on ext2fs" or whatever. And it still needs a sysctl that counts the number of them that actually get delayed. Even if you don't use it for a statistical check, it will check you on the number of times fsync() (and sync()) get called by someone. If it's a small number, you need to fix the bogus program, rather than hack the kernel. 8-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9F4FE4.9B8567DC>