[ZODB-Dev] Using zodb and blobs

[Nitro]

Am 14.04.2010, 09:24 Uhr, schrieb Christian Theune <ct at gocept.com>:

>> What I don't really get is why you should never use "None" on windows.  
>> As
>> far as I can judge from the various transaction rates in the thread Tim
>> mentioned, fsync is just a no-op on linux anyways (depending on the
>> specific file system of course).
>
> I'm pretty sure it's not. IIRC fsync is defined by POSIX and absolutely
> requires the implementor to flush data physically to disk ensuring its
> persistency. If that doesn't hold true then all transactions are borked.

They are. See  
https://mail.zope.org/pipermail/zodb-dev/2004-July/007683.html . Important  
quote "Linux will allow fsync() to return even if the data isn't actually  
on disk".

Also you can do the math yourself. If you have 10 ms average seek time,  
then you can only do 100 fsync/s. If you get more, there's buffering of  
some sort. Be it in hardware or file system. Since you cannot rely on  
fsync to work here I see the fsync as an hopeful wish, but nothing you can  
rely on. Things you cannot rely on give a false sense of security even if  
they might actually help in some cases.
That's why I trust Windows' _commit to do it's work much more I trust  
linux' fsync to do it's job. 50 transaction = 20ms per transaction which  
sounds reasonable.

> In the end it really depends on what you need your data for. If I'd
> store the information that a customer paid me 50 EUR for something and I
> presented a screen to him that told him he'll receive some good for that
> then I'd rather stick with compliant transactions.

Yes, in my case it's nothing critical or related to money. If there's a  
hardware outage a day of work is lost at worst. In case of corruption  
(which can happen also without fsync as data within the file can just be  
garbled) you need a backup anyways.

> j/k?

just kidding.

> I don't think the transfer rate is actually that interesting. For small 
> but many transactions the seek time/spinning speed should have the 
> limiting influence.

Yes, seek time is important here. I didn't recall the seek times of my  
hard disk, but wanted to mention it's not a slow hard disk.

-Matthias