Before comapring index-database against filesystem database, one had to tune
both to the optimum.
I'm no disk guru, but i was curious and made the little experiment to re-format
the cache partition (ext3), with block-size 1024 instead of 4096. I gained
roughly 30% disk space saving.
Here is the output of dh -h and dumpe2fs -h for both variants, blocksize 4096
(old) and 1024(new).
Unfortuneately it came only too late to my mind i should have made a 'time ls'
before it was done.
So i can tell you only the actual values.
My very fist impression is, dir listing is a little slower now.
================= Blocksize 4096:
(1) df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda12 1.9G 1005M 873M 54% /var/cache/wwwoffle (ext3)
(2) dumpe2fs -h /dev/hda12 (/var/cache/wwwoffle):
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 2aaa5036-6cc7-456f-91b8-77f6958b5e51
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal dir_index filetype needs_recovery
sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244320
Block count: 488242
Reserved block count: 0
Free blocks: 223341
Free inodes: 136120
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16288
Inode blocks per group: 509
Last mount time: Mon May 16 00:02:10 2005
Last write time: Mon May 16 00:02:10 2005
Mount count: 1
Maximum mount count: 30
Last checked: Mon May 16 00:02:09 2005
Check interval: 15552000 (6 months)
Next check after: Fri Nov 11 23:02:09 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Journal backup: inode blocks
================= Blocksize 1024:
(3) df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/hda12 1.9G 739M 1.2G 40% /var/cache/wwwoffle
(4) dumpe2fs -h /dev/hda12:
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 4613f27b-6b00-4907-b492-f9dc546480b1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal dir_index needs_recovery sparse_user
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244736
Block count: 1952968
Reserved block count: 0
Free blocks: 1911507
Free inodes: 244725
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1024
Inode blocks per group: 128
Filesystem created: Mon May 16 01:14:46 2005
Last mount time: Mon May 16 01:31:07 2005
Last write time: Mon May 16 01:31:07 2005
Mount count: 1
Maximum mount count: -1
Last checked: Mon May 16 01:14:46 2005
Check interval: 2592000 (1 month)
Next check after: Wed Jun 15 01:14:46 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 5a01d664-4f35-46fd-aab3-4fe695c13a2d
Journal backup: inode blocks
(5) 'time ls /var/cache/wwwoffle/http' after reboot
real 0m16.441s
user 0m0.089s
sys 0m3.898s
Interestingly the same command on the 'swapped' copy /usr/wwwoffle/http shows:
real 0m3.981s
user 0m0.068s
sys 0m3.819s
which is at least 4 times faster than the original wwwoffle cache (and i'd say
rather regardless of the difference in blocksize, because the 'old' cache setup
with 4096 was in any case much slower too).
/usr is a seperate partition with
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 6.7G 3.5G 2.9G 55% /usr (etx3)
and nearly the same settings as the 'old' wwwoffle cache. Here's the dumpe2fs
of /usr.
(Besides the blocksize, another difference to the actual /var/cache/wwwoffle
partition is the filetype_flag. I just don't know what it means, but it looks
like something 'extra' and i ditched it.)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: b4486ac4-174f-45bb-90ee-903584c13db4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 879552
Block count: 1757826
Reserved block count: 87891
Free blocks: 827834
Free inodes: 662548
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16288
Inode blocks per group: 509
Last mount time: Mon May 16 00:02:10 2005
Last write time: Mon May 16 00:02:10 2005
Mount count: 8
Maximum mount count: 30
Last checked: Fri May 13 12:23:57 2005
Check interval: 15552000 (6 months)
Next check after: Wed Nov 9 11:23:57 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Journal backup: inode blocks
I only can imagine the speedup is a benefit of the position on the 'outer rim'
of the harddisk, where the wwwoffle cache resides (because created much later
than the first install), approximately at GB 25 of 40 total, assumed the
partition order still reflects the initial allocation.
Here's the partition table of the first harddisk (via cfdisk):
Name Flags Part Type FS Type [Label]
Size (MB)
----------------------------------------------------------------------------------------------
hda1 Boot Primary Linux ext2
50.07
hda2 Primary Linux ext3
7200.06
hda3 Primary Linux ext2
5100.07
hda5 Logical Linux ext2
5100.07
hda6 Logical Linux ext2
3100.19
hda7 Logical Linux swap
200.25
hda8 Logical Linux swap
349.92
hda9 Logical Hidden FAT16
450.04
hda10 Logical Linux ext2
1000.20
hda11 Logical Linux ext2
1000.20
hda12 Logical Linux ext3
1999.88
hda13 Logical Linux ext2
3999.75
hda14 Logical W95 FAT32 (LBA)
1000.20
hda15 Logical W95 FAT32
1000.20
hda16 Logical Linux ext2
3000.07
hda17 Logical Linux ReiserFS
4999.94
Logical Free Space
469.65
�
/\/
