[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD on a database server - WAPBL, softdeps
On Fri, Sep 18, 2009 at 05:03:27AM +0100, Mindaugas Rasiukevicius wrote:
> Agree about fsck speed on very different contents, but database would still
> do some data segmentation, e.g. PostgreSQL default for data is 1GB and 16MB
> for transaction log (it's way smaller anyway), IIRC. However, recover time
> requirements are strict, hence - would "very quickly" be "quick enough" on
> multi-terabyte database?
> > Databases journal their data themselves. They don't need help from the
> > filesystem to do it, generally speaking.
> Sure, but that was not my point.
My point is that any journaling by the filesystem, with the consequent
duplication of I/O, is going to seriously degrade database runtime
performance in return for a very small boot-time benefit after a system
crash. Anyone who cares _that_ much about recovery time after a crash
should be duplicating the database -- you can't be sure the system will
recover *at all* after a crash.
Proper tablespace and log allocation -- which does not always mean the
database default, particularly not for large databases) can keep
boot time quite tightly constrained without resorting to (for databases)
performance-damaging hacks like journaling in the filesystem.
If it's that much of an issue, use raw partitions.
Main Index |
Thread Index |