On Thu, 15 May 2008, david@xxxxxxx wrote:
On Thu, 15 May 2008, Matthew Wakeling wrote:
On Thu, 15 May 2008, Philippe Amelant wrote:
using mkfs.ext3 I can use "-T" to tune the filesytem
mkfs.ext3 -T fs_type ...
fs_type are in /etc/mke2fs.conf (on debian)
If you look at that file, you'd see that tuning really doesn't change that
much. In fact, the only thing it does change (if you avoid "small" and
"floppy") is the number of inodes available in the filesystem. Since
Postgres tends to produce few large files, you don't need that many inodes,
so the "largefile" option may be best. However, note that the number of
inodes is a hard limit of the filesystem - if you try to create more files
on the filesystem than there are available inodes, then you will get an out
of space error even if the filesystem has space left.
The only real benefit of having not many inodes is that you waste a little
less space, so many admins are pretty generous with this setting.
IIRC postgres likes to do 1M/file, which isn't very largeas far as the -T
setting goes.
Probably of more use are some of the other settings:
-m reserved-blocks-percentage - this reserves a portion of the filesystem
that only root can write to. If root has no need for it, you can kill
this by setting it to zero. The default is for 5% of the disc to be
wasted.
think twice about this. ext2/3 get slow when they fill up (they have
fragmentation problems when free space gets too small), this 5% that only
root can use also serves as a buffer against that as well.
-j turns the filesystem into ext3 instead of ext2 - many people say that
for Postgres you shouldn't do this, as ext2 is faster.
for the partition with the WAL on it you may as well do ext2 (the WAL is
written synchronously and sequentially so the journal doesn't help you), but
for the data partition you may benifit from the journal.
a fairly recent article on the subject
http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/
David Lang
