Dear Muras,

I do not want to give the impression to brutally dismiss this idea and start
a crusade against it..., so I'll first say "Why not after all...".

Though let me add severe arguments against it...

IMHO, the single or multi-file approach of Interbase today is excellent and
offers great convenience, without requiring very specific system-level code
for each platform supported. Also, today there is no need to partition
specifically a system. A file is a file. And relying on a simple normal file
makes it work on any variant of filesystem you have. Also it gives you
goodies. Most high-end systems offer very flexible file-systems and volumes
abstractions. Allowing you to grow, resize a file system on the fly. You can
also sometimes move a filesystem from one physical disk to another.
Sometimes even online (see Aix). Most of those systems (and this includes
Windows 2000) also allow to grow a volume by adding new supplemental
physical disks to it. You can mount some logical or physical volumes on a
branch of your file-system too. Let's not even talk about mirroring or RAID.
I would not setup my most valuable database files on anything else than a
RAID 0+1 or a least RAID 5.

Let's speak performance too. Here I can only talk Windows NT/2000.
Set your Interbase database page size at 4K.
Format your partition as NTFS, with 4K clusters and not the 512 bytes
default.
Now see how fast you can go reading and writing in the GDB file.
Try to beat it with a custom file system, you'll have a hard time trying and
the net gain will be most probably too small to notice. Now, try the same on
a RAID 0+1 or RAID 5 configuration (I'm speaking of software RAID provided
by default by NT/2000, not even dedicated hardware). Format your RAID file
system with 4K clusters, IB database also set to 4K (I'm assuming you put
ONE or some dabase files on these "partitions", not a bunch of trillions of
other files -- to be comparable to a dedicated file system solution). Watch
the solution fly, let's try to compete with a dedicated file-system (of
course on a hardware-based RAID, that possible).

I sincerely doubt we can get *valuable* performance improvements with a
dedicated file system.
Though, I am totally convinced we would loose in ease of configuration, ease
of maintenance.
Let's always remember the old marketing phrase of IB "Embed. Deploy. Relax."
I heartfully hope IB will never loose that advantage.
It is a killing advantage of IB against MS and Oracle and was never marketed
correctly/enough.

Now I'd like to answer your points.

> 1. Better guard condition against incompetent access to the *.gdb.,
> in file system isn´t file *.gdb any more, on some disk is partition

which

> will be
> (I think fully) dedicated for IB DB.

Matter of correct setup and access rights. If you have a loose security
system that allow any user to delete or write to any file on all file
systems, sure someone already has your root password. Say bye bye anyway to
your /dev/devices if it is a malicious user.

> 2. Quicker access to the DB :
>
> - whole capacity of partition is prepared for IB initially
> and at once.
>
> - direct access across blok device /dev/hd....

I gave my vision longly at the beginning of this (too) long email.

> 3. The prices of disk capacity is falling down and is not great
> problem reserve enough capacity for DB.

Sure. This is not a specific argument for the dedicated file-system solution
though.
Today's solution benefit from this too, of course.

> 4. Requirements on security system are growing.

True. Obfuscating the database in a dedicated file-system do not bring in
much more security. It may, at most, give a feeling of added security (not
the same thing). It is again a matter of security policy design and
enforcement. Not a OS file-system or dedicated file-system issue.

-------------------------- www.tipgroup.com -------------------------
Olivier Mascia T.I.P. Group S.A.
om@... Company Phone +32 65401111
Director, Senior Software Engineer Private Mailbox/FAX +32 27065653