Anonymous (no@spam.com) on 9/12/08 wrote:
---------------------------
>anon (anon@anon.com) on 9/12/08 wrote:
>---------------------------
>>>Sigh, it is trivial to store enough energy in the flash unit to commit the buffers
>>>to flash on loss of power, which is what many HDDs do right now anyway, problems with that?
>>Well that's not lying then, is it?
>
>True enough, perhaps bending the truth, the data is not committed to the primary store, but it is now guaranteed.
>
>>Do you have any documentation or evidence of this happening in SSDs anyway?
>
>There are indications that intel is doing it on the upcoming high performance SSD drives, but no proof as yet.

What are the indications? I would be surprised if they are actively adding to the cost like that (adding batteries and so on) for commodity devices.


>Others will be doing it 'soon'

According to what?

And what are some of the HDDs that do it now also?


>>>So, what exactly do you do with situations where the OS does NOT do that? (ie:
>>>anythgin useing direct disk access APIs?) fall over flat on your face?
>>
>>Why would you have multiple applications doing direct disk access (one or more
>>of which is writing) to a device? I have a hard time thinking anybody would ever care about that.
>
>Databases.

Databases to direct writes to disk from a big memory segment which is their disk cache. The writes will be initiated via a transaction manager or perhaps a page cleaner. I don't know why it would ever be a requirement to read from the same block as is being written, because the read should instead just be satisfied from the data being written (because it will be valid in the database's disk cache).


>>>>Are you just making up these requirements off the top of you head? Or do you
>>have some in depth knowledge of the area?
>>>
>>>Quite a bit more than you it seems.
>>
>>OK, so tell me why it is such a win to forward in-progress writes to reads? Give
>>a concrete example of an application or system that would require that to be fast.
>
>Transactional databases do it.

Example/proof? I have trouble seeing why this would be needed. If the database can't satisfy the read from memory where the write is coming from, then it seems like it would have serious coherency problems.


>Some filesystems do it for metadata.

Which ones?


>Basically it is moderately common in situations where data wants to be guaranteed
>(ie: refuse to allow a read until a write is marked as committed).

I don't know of anything that relies on the disk layer to do it. It is pretty trivial to manage that from the cache layer. And anyway, forwarding reads from uncompleted writes as you specified earlier would break the above guarantee anyway, so why would you want to do that?


>If the device is going to claim a write is committed, then it damn well better
>service any pending reads to that data from its write buffers, otherwise all hell will break loose.
>
>It is bordering on trivial to implement, and is required for consistency, why would it not be done?

I'm not saying it should or it should not be implemented, just that I don't see how it is remotely required of a high performing implementation, it just doesn't happen that much.