Date: Thu, 17 Apr 2003 09:54:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Marko Zec <zec@tel.fer.hr> Cc: Kirk McKusick <mckusick@beastie.mckusick.com> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3E9EDC38.1CE381C6@mindspring.com> References: <200304162310.aa96829@salmon.maths.tcd.ie> <3E9E9827.4BB19197@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > Ian Dowse wrote: > > Note that the ATA "delayed write" mechanism only delays writes while > > the disk is spun down; at other times there is no change in behaviour. > > Since the disk only spins down after it has been idle for a time, > > it is very unlikely that the disk is left in an inconsistent state > > while it is stopped. I'm wondering if the ATA "delayed write" actually does this, or if it merely relaxes the cache restrictions, without retaining the ordering enforcement. I suspect that it does not retain the ordering enforcement, as there is no way to disconnect on a tagged queue write, because you must issue a request for status, and it can't be done as a seperate ATA operation (see the posts by the Maxtor employee, on and around January 20th of this year to the -FS list for details). You are much better off accumulating requests in the kernel in buffers, and then using the normal write mechanism to push them out to the drive ordered (IMO). This implies a barrier and new code above the bwrite interface, to keep the buffers from getting locked, and stalling you applications in user space. A problem I see here is that swap is on a totally different path, and in a different area of the disk (practically guaranteeing a seek, and a track buffer invalidation on the disk), even if you could cause swapping to be delayed (I don't think you can; FreeBSD aggressively uses memory, and so when you need to swap, you *need* to swap). > The OS _does_ know (approximately) when the disk is spinning and when not. > For example, if the disk is configured to stop spinning immediately after > the last I/O operation, the OS can safely assume 10 or more seconds > afterwards the spinning will be stopped. The OS only has to keep record (in > form of timestamp or something similar) when it has issued the last I/O > request to the disk. In my patch this is accomplished using the stratcalls > marker, which is increased every time the strategy routine of the ATA disk > driver is invoked. Therefore the OS can also successfully coalesce the > pending disk updates with other outstanding I/O disk operations, which are > typically reads of uncached sectors or VM swapping. This is useful, but not enough. You need to actually communicate the information above the block I/O layer, to the soft updates. I think, effectively, what you actually want to do is to stop the soft updates clock, rather than trying to play stupid disk tricks with timers, etc., above and beyond what you have to do. I can see it being useful on SCSI disks, as well, particularly where there are temperature issues. Though in that case, you probably are more memory starved than anything, and it will end up doing you no good. > I agree the ATA delayed writes is a great functionality that can help save > battery power. I don't; only if the write order is maintained is it "great". > I just want to point out that it can suffer from the same > consistency problems as the model of OS controlled delayed synching combined > with null fsync() processing. However, if the OS controls the delaying of > updates, you can turn on or off normal fsync() semantics as desired. With > delaying writes in ATA firmware, you simply do not have the choice :) I think people are confusing fsync() with syncd at this point. 8-(. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9EDC38.1CE381C6>