Date: Sat, 12 Apr 2003 18:37:12 +0200 From: Marko Zec <zec@tel.fer.hr> To: freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3E9840B8.F00E018F@tel.fer.hr> References: <200304121438.h3CEct41030991@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: > Marko Zec <zec@tel.fer.hr> wrote: > > Here's a patch against 4.8-RELEASE kernel that allows disk writes on > > softupdates-enabled filesystems to be delayed for (theoretically) > > arbitrarily long periods of time. The motivation for such updating > > policy is surprisingly not purely suicidal - it can allow disks on > > laptops to spin down immediately after I/O operations and stay idle for > > longer periods of time, thus saving considerable amount of battery > > power. > > It would be very cool if you could have different delay > settings per filesystem. That would enable you to have > a large delay on /tmp, a medium delay on /var, and the > standard delay (i.e. more safety) on everything else. That would certainly be cool, however I have no clue if and how such model could be implemented. But what I can safely assume is that it wouldn't be nearly as simple as the original patch. > > - fsync() no longer flushes the buffers to disk, but returns immediately > > instead; > > I see some issues with that. Better make that tunable > separately (and probably default to off). I agree that additional tunable for controlling fsync() behavior couldn't hurt, however as explained in previous note I see the fsync() as the most common initiator of disk spinnups, so a method for suppressing it must be made available, otherwise the whole patch wouldn't make much sense... > > - if one of the mounted filesystems becomes low on free space, which can > > happen if lot of data is written to the FS but FS metadata buffers are > > not updated to disk, flushing of all softupdates buffers is scheduled > > automatically; > > That's cool, too. I've been bitten several times by the > bogus "no space left on device", due to soft-updates > delaying the freeing of file data. > > I assume that buffered data is also flushed to disk when > the system runs low on RAM, right? (I'm not a VFS/VM > expert, so that might be a stupid question.) As far as I understand how softupdates work, the algorithm ensures the data is _always_ written to disk before the metadata, so that shouldn't be a problem. Cheers, Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9840B8.F00E018F>