Re: test_fsync label adjustments

On Jan 18, 2011, at 5:21 PM, Bruce Momjian wrote:

> A.M. wrote:
>>
>> On Jan 18, 2011, at 5:16 PM, Bruce Momjian wrote:
>>
>>> A.M. wrote:
>>>>
>>>> On Jan 18, 2011, at 3:55 PM, Bruce Momjian wrote:
>>>>
>>>>> I have modified test_fsync to use test labels that match wal_sync_method
>>>>> values, and and added more tests for open_sync with different sizes.
>>>>> This should make the program easier for novices to understand. Here is
>>>>> a test run for Ubuntu 11.04:
>>>>>
>>>>> $ ./test_fsync
>>>>> 2000 operations per test
>>>>>
>>>>> Compare file sync methods using one 8k write:
>>>>> (in wal_sync_method preference order, except fdatasync
>>>>> is Linux's default)
>>>>> open_datasync (non-direct I/O)* 85.127 ops/sec
>>>>> open_datasync (direct I/O) 87.119 ops/sec
>>>>> fdatasync 81.006 ops/sec
>>>>> fsync 82.621 ops/sec
>>>>> fsync_writethrough n/a
>>>>> open_sync (non-direct I/O)* 84.412 ops/sec
>>>>> open_sync (direct I/O) 91.006 ops/sec
>>>>> * This non-direct I/O mode is not used by Postgres.
>>>>
>>>> I am curious how this is targeted at novices. A naive user might enable
>>>> the "fastest" option which could be exactly wrong. For this to be useful
>>>> to novices, I suspect the tool will need to generate platform-specific
>>>> suggestions, no?
>>>
>>> Uh, why isn't the fastest option right for them? It is hardware/kernel
>>> specific when you run it --- how could it be better?
>>
>> Because the fastest option may not be syncing to disk. For example,
>> the only option that makes sense on OS X is fsync_writethrough- it
>> would be helpful if the tool pointed that out (on OS X only, obviously).
>
> Yes, that would be a serious problem. :-(
>
> I am not sure how we would address this --- your point is a good one.

One general idea I had would be to offer some heuristics such as "this sync rate is comparable to that of one SATA drive" or "comparable to RAID 10 with X drives" or "this rate is likely too fast to be actually be syncing". But then you are stuck with making sure that the heuristics are kept up-to-date, which would be annoying.

Otherwise, the only option I see is to detect the kernel and compare against a list of known problematic methods. Perhaps it would be easier to compare against a whitelist. Also, the tool would likely need to parse "mount" output to account for problems with specific filesystems.

I am just throwing around some ideas...

Cheers,
M