8
0
mirror of https://github.com/FirebirdSQL/firebird.git synced 2025-02-02 09:20:39 +01:00
This commit is contained in:
asfernandes 2007-12-28 00:14:00 +00:00
parent ebc1ac8e64
commit 0ee85c7525
5 changed files with 11 additions and 11 deletions

View File

@ -15,7 +15,6 @@
# All Rights Reserved.
# Contributor(s): ______________________________________.
# Start of file prefix.darwin: $(VERSION) @PLATFORM@
#$Id: prefix.darwin_i386,v 1.3 2007-12-27 12:19:52 paulbeach Exp $
# 2 Oct 2002, Nickolay Samofatov - Major Cleanup
DYLD_LIBRARY_PATH=$(FIREBIRD)/lib

View File

@ -15,7 +15,6 @@
# All Rights Reserved.
# Contributor(s): ______________________________________.
# Start of file prefix.darwin: $(VERSION) @PLATFORM@
#$Id: prefix.darwin_powerpc,v 1.3 2007-12-27 12:19:52 paulbeach Exp $
# 2 Oct 2002, Nickolay Samofatov - Major Cleanup
DYLD_LIBRARY_PATH=$(FIREBIRD)/lib

View File

@ -1,11 +1,11 @@
Since the beginning Firebird have no rules of how to allocate disk space
Since the beginning, Firebird have no rules of how to allocate disk space
for database file(s). It just writes new allocated pages in not determined
order (because of dependencies between pages to serve "careful write" strategy).
This approach is very simple but have some drawbacks :
- because of not determined order of writes there may be such situation when
- because of not determined order of writes, there may be such situation when
page cache contain many dirty pages at time when new allocated page must be
written but can't because of out of disk space. In such cases often all other
dirty pages are lost because of administrators prefer to shutdown database
@ -16,12 +16,12 @@ order (because of dependencies between pages to serve "careful write" strategy).
example during backup).
Using new ODS 11.1 Firebird changes its disk space allocation algorithm to
Using new ODS 11.1, Firebird changes its disk space allocation algorithm to
avoid corruptions in out of disk space conditions and to get file system a
chance to avoid fragmentation. This changes described below.
chance to avoid fragmentation. These changes are described below.
a) Every newly allocated page writes on disk immediately before returning to
the engine. If page can't be written then allocation is not happens, PIP bit
the engine. If page can't be written then allocation not happens, PIP bit
is not cleared and appropriate IO error is raised. This error can't lead to
corruptions as we have a guarantee that all dirty pages in cache have disk
space allocated and can be written safely.
@ -35,18 +35,18 @@ a) Every newly allocated page writes on disk immediately before returning to
allocated first time. I.e. if page was allocated, freed and allocated again
it will not be written twice on second allocation.
b) To avoid file fragmentation Firebird used appropriate file system's API to
b) To avoid file fragmentation, Firebird used appropriate file system's API to
preallocate disk space by relatively large chunks. Currently such API have
only Windows but it was recently added into Linux API and may be implemented
in such popular file system's as ext2, etc in the future. So this feature
currently implemented only in Windows builds of Firebird and may be implemented
in Linux builds in the future.
For better control of disk space preallocation new setting in Firebird.conf
For better control of disk space preallocation, new setting in Firebird.conf
was introduced : DatabaseGrowthIncrement. This is upper bound of preallocation
chunk size in bytes. Default value is 128MB. When engine needs more disk space
it allocates 1/16th of already allocated space but no less than 128KB and no more
than DatabaseGrowthIncrement value. If DatabaseGrowthIncrement set to zero then
than DatabaseGrowthIncrement value. If DatabaseGrowthIncrement is set to zero then
preallocation is disabled. Space for database shadow files are not preallocated.
Also preallocation is disabled if "No reserve" option is set for database.

View File

@ -171,10 +171,12 @@ public:
{
fb_assert(init == true);
for (int i = 0; i < count; i++)
{
if (sem_post(sem) == -1)
{
system_call_failed::raise("semaphore.h: release: sem_post()");
}
}
}
#ifdef HAVE_SEM_TIMEDWAIT

View File

@ -25,7 +25,7 @@ set bulk_insert INSERT INTO FACILITIES (LAST_CHANGE, FACILITY, FAC_CODE, MAX_NUM
--('1996-11-07 13:38:43', 'GJRN', 16, 241)
--
('2007-10-02 05:56:56', 'ISQL', 17, 160)
('2007-05-22 13:11:00', 'GSEC', 18, 94)
('2007-12-27 13:11:00', 'GSEC', 18, 94)
('2002-03-05 02:30:12', 'LICENSE', 19, 60)
('2002-03-05 02:31:54', 'DOS', 20, 74)
('2007-04-07 13:11:00', 'GSTAT', 21, 37)