From: Helmut Tessarek on
Hi Frederik,

On 5.8.2010 16:36, Frederik Engelen wrote:
> How do you feel about EXT4 (and EXT3 with writeback)? His objections
> seem more serious there.

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.
*/
From: hsn_ on
EXT2 performs better with DB2 than ext3. If you dont use SMS managed
tablespaces then ext2 is safe to use.
From: Troels Arvin on
hsn_ wrote:
> EXT2 performs better with DB2 than ext3. If you dont use SMS managed
> tablespaces then ext2 is safe to use.

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
From: Luuk on
Op 11-08-10 20:23, Troels Arvin schreef:
> hsn_ wrote:
>> EXT2 performs better with DB2 than ext3. If you dont use SMS managed
>> tablespaces then ext2 is safe to use.
>
> Yes, but how do handle the following case which I fear:
>
> 1. The system goes down hard (hardware failure / software
> failure / power outage).

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....

>
> 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?
>


--
Luuk
From: hsn_ on
> hsn_ wrote:
> > EXT2 performs better with DB2 than ext3. If you dont use SMS managed
> > tablespaces then ext2 is safe to use.
>
> Yes, but how do handle the following case which I fear:
> 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?
You dont need to run fsck because only filesystem inconsistency will
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.