The following sysctl's define the delay before things are written to disk with softupdates. I think they work in realtime and setting them to 3,2,1 for a little time wil sync the disk faster. But wil make the caching less efficient. So play with it for a while.
kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 Greetings, Ronald. Brian T.Schellenberger wrote: > I have been running into some issues with the time it takes softupdates to > fully finish updating. Recently I deleted a lot of files (about 3G worth of > files, actually), and it took over five minutes to really get the disk space > back. Since I wanted to start up a process to re-fill the disk space, this > was a pain: the other process kept dying because it ran out of disk space. > > Others have posted about similar difficulties with backups. Of course > backing up a live filesystem can never be 100%, but it was in practical terms > closer before softupdates came along. > > And yet, most of the time I *love* softupdates. It makes the system > tolerable to use while turning write caching off, which makes me feel a whole > lot safer. I've not had any (non-hardware-related) problems with disk > corruption since I started running softupdates and I had had corrupt > filesystems mulitiple times before. > > So . . . > > What I'd like is a command like "syncupdates" or something that would > synchronosly force all the pending softupdates updates to update and return > only when that was complete. Then when I had the (rare) occaisons where I > really wanted them synced up, they could be synched up but the rest of the > time I could still let it update when it pleased. > > Questions: > > - Is there any functionality already in the system that I don't know about? > - Are there any plans to add it? > - If not, I might have a go at it myself. Other than your code and the > original paper are there any references or information that I should have in > hand? > - And would you, Julian, be willing to review whatever I might come up with > and possibly commit it if it looks plausible? (I don't run current so > whatever patches I'd come up with would be against -stable, but I presume > that doing a sort of "reverse MFC" to translate them to -current patches > wouldn't be terribly difficult.) > > Please understand that though I've programming for many, many years I've only > done the very most trivial of things in the kernel before so I'd bring more > enthusiasm than expertise to such an undertaking. I'd actually prefer if > this feature just sort of dropped into my lap, but I'm interested enough in > the feature to have a go at doing it myself. > > Thanks for any insight you can offer. > > -- Ronald Klop, Amsterdam, The Netherlands --> Remove the 'not4mail.' from the e-mail address before replying. <-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
