--- In Firebird-Architect@yahoogroups.com, Alex Peshkov <pes@...>
wrote:

>
> Vlad Horsun:
> >> Not sure. Have a look at CreateFile documentation - discussing
> >> FILE_FLAG_NO_BUFFERING they always refer to disk, not network
> >> connection. For example - "Buffer addresses for read and write
> >> operations should be sector aligned, which means aligned on

addresses in

> >> memory that are integer multiples of the volume sector size".

Please

> >> agree, that this makes no sense for data, read from network.
> >>
> >> What about building experimental SS for you - sorry, I don't

have now

> >> working win32build environment.
> >
> > And we have no guarantie that all buffers passed to the PIO

properly

> > aligned. I.e. it is not a question of activate file flag only
> >
>
> This becomes interesting - I was sure they are. I suppose that in

case

> of correct alignment windows may start DMA using allocated buffer
> directly. Without correct alignment performance degradation is

possible

> - OS has to copy data to/from correctly aligned buffer, and use it

for

> physical IO. Taking into account, that we have never seen errors

with

> bad alignment code, this is what probably happening.
>

They are, AFAIK. Read MSDN at http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/fileio/fs/createfile.asp

...especially the chapter of FILE_FLAG_NO_BUFFERING. Please note,
also, that the documentation states that the 'lpFileName' can be
\\<Server>\<share> and the doc states also which flags doesn't work
on what systems and in which conditions. Also, I saw some working
examples of file management over the network (modify the contents of
the file, copying) using Delphi and these flags. But I thnik that our
discussion doesn't have much sense since we all agree less or more on
the following points (please confirm):

1. The remote shadows on WinNT are an important feature, if they are
working. This needs _real_ testing. So, if someone is so kind to
build a experimental SS for Win32 to test it or to give me to do some
crash tests... ...*IF*, of course, the foundation (Dmitry?) states
that if everything is ok the feature will be implemented (this is in
order to not waste my time testing in vain something which will be
never implemented...).

2. A two-way communication layer between servers will solve many
problems, and, perhaps, is a better approach, but not so trivial to
implement for:
- replication\database mirroring
- clustering
- cross-database queries
aso.

3. The crash-recovery features are very important today. For example,
in newly released Interbase 2007 as you know (you know?) from 7 new
features, 4 are regarding the failure tolerance problem. The other 3
are, at least for me, not so crucial, and thus is good to have them,
we can live without.

Waiting for response,

m.th.