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

>

....

> Writing pages to database file is not trivial process - in order to

be

> able to recover database after system failure we must ensure

correct

> order of pages written to the disk, this is known as 'safe write

order'.

> OS often does it's best to break safe write order - for example, it
> optimizes order of pages to be written to the disk to minimize

movement

> of HDD heads. We set special flags when opening databases file to

avoid

> such optimizations. Not necessary to mention, that safe write order
> should be kept for shadows too. And here is an answer why NFS is a
> special case - it can keep safe write order of pages in database

shadow.

>
> I'm not very familiar with windows file sharing. If one gives us a
> reference (to MSDN, for example), which describes how to guarantee

safe

> write order for windows-based network, I see no problems enabling
> shadowing across MS network. Without guarantees of keeping safe

write

> order, shadowing may become very dangerous feature - you can easily

get

> a heap of useless bytes instead of a normal database in your shadow.
>

IOW in Windows terms (please correct me if I'm wrong):
We have in winnt.cpp:

FIL PIO_create(DBB dbb, TEXT * string, SSHORT length, BOOLEAN
overwrite)
{
/**************************************
*
* P I O _ c r e a t e
*
**************************************
*
* Functional description
* Create a new database file.
*
**************************************/
HANDLE desc;
FIL file;
TEXT workspace[MAXPATHLEN];
TEXT *file_name;

file_name = string;

if (length)
{
MOVE_FAST(file_name, workspace, length);
workspace[length] = 0;
file_name = workspace;
}

desc = CreateFile(file_name,
GENERIC_READ | GENERIC_WRITE,
g_dwShareFlags,
NULL,
(overwrite ? CREATE_ALWAYS :
CREATE_NEW),
FILE_ATTRIBUTE_NORMAL |
g_dwExtraFlags,
0);


Where:

#ifdef SUPERSERVER_V2
static const DWORD g_dwShareFlags = FILE_SHARE_READ; // no write
sharing
static const DWORD g_dwExtraFlags = FILE_FLAG_OVERLAPPED |
FILE_FLAG_NO_BUFFERING |
FILE_FLAG_RANDOM_ACCESS;

So, if these are the 'special flags' then the (official)
documentation of Win32 SDK states that the CreateFile function works
with UNC path-names ie. \\<Server>\<Share> so it's transparent. (The
CreateFile documentation is available upon request). But I don't
believe until I see. (IMHO, I tend to trust them, though). So, if
you're so kind to build an experimental super-server to test it...

> What about performance problems on network shadows. They are not

too

> big. As soon as you take into account that all reads are done from
> primary database file, and only writes are repeated for shadows,

you

> will notice that there are no big problems here. Next, if you use
> dedicated 1GBit link for shadow, you have approx 100MBytes/sec
> throughput, which is exactly what good hard disk has (certainly I

don't

> speak about high-end devices - 10GBit network should be used in

high-end

> case).
>
> Concerning reliability - from my own experience NFS does it's work

very

> well. One of our customers had a 'wonderful' UPS which used to turn

off

> output voltage at random moments. But they never had broken mirror,
> though in some cases they had broken primary file!
>
> Summarizing - if we can guarantee safe write order for some network
> protocol, enabling shadows over it is very good feature. Though for

MS

> products some crash-tests should be also fine - I do not trust M$

products.

>
> Alex.
>

Guarantee = give me a small super-server kit and I'll tell you... :)

Of course, if we agree that this feature should be implemented. At
least for SS architecture which is straightforward.

Neither I don't trust (generally). But I must admit that the Win2003
and WinXP are pretty stable at least from the developer POV.

m.th.