Hello,

At http://informix-myview.blogspot.com/...ed-filesystem-
rant.html the author argues that journaling file systems' use of block
relocations leads to poor data locality over time. And when you use a
journaling file system, you have two layers of journaling: in the
database and on the file system. - So that a non-journaling file system
should be used if raw devices aren't an option.

Even though the article is written from an Informix standpoint, the
potential problem should be rather universal for database systems, I
guess.

Do you agree with the points in the article? If choosing a journaling
file system after all (to prevent long outages after uncontrolled
restarts due to fsck), would it help to create the file system using a
very small journal?

--
Troels

Hi Troels,

On 04.08.10 16:23 , Troels Arvin wrote:
It is correct that DB2 makes use of logging (which could considered
journaling), but please tell me what will happen, if there is a power outage
during a log write and you are using a non-journaled filesystem and you are
not able to recover the data with fsck.

The journaling prevents data loss and filesystem corruption from an OS's point
of view. This is a different layer. Your database logging mechanism is useless
if it is corrupted and/or not accessible.

However there is the matter of filesystem caching, which is usually bad for
database filesystems (with some exceptions), because data is cached in 2
layers: fileystem and bufferpool. Therefore FSC is off by default on DB2 9.7.

Helmut


--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

On 4 aug, 23:26, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:
Hello Helmut,

How do you feel about EXT4 (and EXT3 with writeback)? His objections
seem more serious there.

Kind regards,

Frederik

Hi Frederik,

On 5.8.2010 16:36, Frederik Engelen wrote:
The author of the BLOG is correct when he says that only metadata is journaled
and not the data itself. But even corrupt metadata can cause the data to be
inaccessible.

Theoretically there are situations where you could end up with corrupted data
on ext4 and ext3 (with writeback), but I have never seen it happen and we did
a lot of testing.
This issue is often referred to as the new barrier code in ext4. In ext4, you
can bypass this problem by mounting the filesystem with the option barrier=0.
But this option is very bad for performance.

We are working with Redhat on a proper solution.

To put it in a nutshell, if there is a filesystem corruption at hand, you
always have the possibility to restore the database. Given that fact you can
as well use a non journaled filesystem.

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

EXT2 performs better with DB2 than ext3. If you dont use SMS managed
tablespaces then ext2 is safe to use.

hsn_ wrote:
Yes, but how do handle the following case which I fear:

1. The system goes down hard (hardware failure / software
failure / power outage).

2. During boot, the OS determines that the EXT2 filesystem
needs a check.

3. The check takes hours, if not days.

But maybe step 1 happens so seldomly that it can be disregarded? Or maybe
step 3 doesn't take very long if there are few files on the file system?

--
Troels

Op 11-08-10 20:23, Troels Arvin schreef:
system goes down 'hard' cause by a 'software failure'?....
never seen that...!

power outage: can be prevented with a UPS

other hardware failures: only a backup IS needed, its other hardware you
need to restore this backup unto because your original hardware has a
failure....


--
Luuk

be freespace map which can be ignored because it will be just some
wasted space.

time of fsck depends on number of inodes on filesystem (which depends
on inode density and filesystem size) and number of allocated files.
On database volumes number of files is really small and you can lower
inodes density during filesystem creation.