← Back to branch summary

~ubuntu-branches/ubuntu/karmic/firebird2.1/karmic

« back to all changes in this revision

Viewing changes to doc/README.DiskSpaceAllocation

  • Committer: Bazaar Package Importer
  • Author(s): Damyan Ivanov
  • Date: 2008-05-26 23:59:25 UTC
  • Revision ID: james.westby@ubuntu.com-20080526235925-2pnqj6nxpppoeaer
Tags: upstream-2.1.0.17798-0.ds2
Import upstream version 2.1.0.17798-0.ds2

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/README.DiskSpaceAllocation
 
1
 
 
2
        Since the beginning, Firebird had no rules of how to allocate disk space
 
3
for database file(s). It just writes new allocated pages in not determined 
 
4
order (because of dependencies between pages to serve "careful write" strategy).
 
5
 
 
6
        This approach is very simple but has some drawbacks :
 
7
  
 
8
- because of not determined order of writes, there may be such situation when 
 
9
  page cache contains many dirty pages at time when new allocated page must be
 
10
  written but can't because out of disk space. In such cases often all other
 
11
  dirty pages are lost because administrators prefer to shutdown database
 
12
  before making some space on disk available. This leads to serious corruptions.
 
13
 
 
14
- allocating disk space by relatively small chunks may lead to significant file 
 
15
  fragmentation at file system level and reduce performance of large scans (for
 
16
  example during backup).
 
17
 
 
18
 
 
19
        Using new ODS 11.1, Firebird changes its disk space allocation algorithm to 
 
20
avoid corruptions in out of disk space conditions and to give the file system a 
 
21
chance to avoid fragmentation. These changes are described below.
 
22
 
 
23
a)  Every newly allocated page is written on disk immediately before returning to
 
24
  the engine. If page can't be written then allocation doesn't happen, PIP bit
 
25
  is not cleared and appropriate IO error is raised. This error can't lead to 
 
26
  corruptions as we have a guarantee that all dirty pages in cache have disk 
 
27
  space allocated and can be written safely.
 
28
 
 
29
        This change makes one additional write of every newly allocated page compared
 
30
  with old behavior. So performance penalty is expected during the database file
 
31
  growth. To reduce this penalty Firebird groups writes of newly allocated pages
 
32
  up to 128KB at a time and tracks number of "initialized" pages at PIP header.
 
33
   
 
34
        Note : newly allocated page will be written to disk twice only if this page
 
35
  is allocated first time. I.e. if page was allocated, freed and allocated again
 
36
  it will not be written twice on second allocation.
 
37
   
 
38
b) To avoid file fragmentation, Firebird used appropriate file system's API to
 
39
  preallocate disk space by relatively large chunks. Currently such API exists
 
40
  only in Windows but it was recently added into Linux API and may be implemented 
 
41
  in such popular file system's as ext2, etc in the future. So this feature is
 
42
  currently implemented only in Windows builds of Firebird and may be implemented 
 
43
  in Linux builds in the future.
 
44
  
 
45
        For better control of disk space preallocation, new setting in Firebird.conf
 
46
  was introduced : DatabaseGrowthIncrement. This is upper bound of preallocation 
 
47
  chunk size in bytes. Default value is 128MB. When engine needs more disk space 
 
48
  it allocates 1/16th of already allocated space but no less than 128KB and no more 
 
49
  than DatabaseGrowthIncrement value. If DatabaseGrowthIncrement is set to zero then
 
50
  preallocation is disabled. Space for database shadow files is not preallocated.
 
51
  Also preallocation is disabled if "No reserve" option is set for database.
 
52
 
 
53
        Note : preallocation also allows to avoid corruptions in out of disk space 
 
54
  condition - in such case there is a big chance that database has enough space
 
55
  preallocated to operate until administrator makes some disk space available.
 
56
 
 
57
 
 
58
        Author: Vlad Khorsun, <hvlad at users sourceforge net>
 
59