> > - Asynchronous File I/O
> 
>    It is not really asynchronous as it waits for the completion of every 
> single IO
> request.

True, but it allows the storage controller to decide the best order in which to 
perform the operations...


>  Also, note, it completely disables file system caching. It kills write
> performance

Really?

I could see a benefit for writing several pages, which are of the same 
'priority/level' in the "carefully order writes", through a single operation 
for any storage device.  Fewer calls would improve performance.

Separately, I seem to recall that the feature was completed and released in a 
IB 6.5+ release.


> There is no UNIX part of it, btw.

Unix/Linux... Smm-*nix!!

Don't you know, Windows is the only platform that matters!


> > - Defer Header Page Write (i.e. reduce the number of times that the
> > header page is written to disk)
> 
>    This is most mature piece of code and i'm going to use it as a base for the
> our implementation. It have no support for CS and, of course, it must be
> tested very carefully.

Interesting that you want to continue with it...

Although, I see the benefits of avoiding the "sun level hotspot" that is the DB 
Header page write operations.

I don't see how database integrity can be maintained if the header page changes 
are not persisted to disk immediately -- aside from an MPI based multi-node 
cluster where pages changes are sent to other nodes (as witnesses for 
safekeeping)*.


Sean

* This approach could actually provide several possible benefits... 

Even over 10GBs TCP connection (w/properly configured MTU) MPI latencies (for 
4KB messages) are < 250 micro-seconds (us) whereas SSD/PCIe SSDs latencies are 
10-5 (ms).

Using 10GBs RDMA, latencies are < 100 micro-seconds (us).

Using latest RDMA NICs, latencies are < 15 micro-seconds (us).

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to