Re: ReiserFS vs XFS or JFS?

["markw-4" <user=5@nabble.blu.org>]

 In general, I'm not too fond of "journaling" as a data integrity tool. 
Unless you do sophisticated things like block archive on write and full 
versioning of files, journaling is *only* for file system stability, it 
will not protect any data. 

Upon a power failure, application data in the system file cache is no 
better protected with a journaling system than without. The only advantage 
is file system reconstruction time but the data will still be lost. There 
is no absolute guarantee that a file existing with bogus data (journaling 
file system) is any better than a bogus file being deleted by fsck. The 
advantage of file system journaling is system restart time and 
recoverability. 


> Interesting.  I hadn't thought of it that way. 
> 
> I understand the concept of journaling a filesystem or database, but I 
> haven't looked at the source code to any of the implementations.  This 
> conversation has got me wondering - where is the journaled data 
> typically stored?  It's clear that the more separate you can keep the 
> journal from the thing being journaled, the safer you are in the case of 
> catastrophic failure.  Do any of these journaled filesystems or 
> journaled databases allow you to write the journal to a separate disk 
> from the one that contains the filesystem or database, on the theory 
> that both disks aren't likely to die simultaneously? 
> 
>     Mark 
> 
> [hidden email] wrote: 
>>> If the raw file containing your database is represented inside the 
>>> structures used by a filesystem and something in the filesystem gets 
>>> trashed, having a journaled database isn't going to help at all because 
>>> the journaling information will be inaccessible, since it's also stored 
>>> in the trashed filesystem. 
>>> 
>> 
>> Depending on the database that may be true, but a block level journaling 
>> database like Oracle or PostgreSQL that is likely not true. I know 
>> PostgreSQL better, so I explain using it as an example. 
>> 
>> Assuming an active database, one is which there may  be re-usable space 
>> in 
>> existing blocks and PostgreSQL WAL files are fairly constant in size. 
>> 
>> Assume that the file system will not be obliterated on a power failure. 
>> That it is robust enough (or simple enough) to merely have lost chains. 
>> I 
>> would use something like DOS FAT as a model. Simple to the point of 
>> being 
>> stupid. 
>> 
>> When a database table grows, it grows in fixed sized blocks (like FAT). 
>> After each database write, fsync is called. Far more often than not, 
>> only 
>> the data within a file changes while the disk allocation and file system 
>> information remain constant. 
>> 
>> The meta information and file system never needs to be journaled because 
>> the file's "file system" characteristics change relatively infrequently 
>> and when they do, fsync will be called immediately. There will never be 
>> any real benefit from the file system journal and you'll end up doing 
>> the 
>> same work twice. 
>> 
>> 
>> 
>>> So, if you store your database inside a filesystem, double journaling 
>>> is 
>>> unavoidable if you want your data safe.  The preferable alternative is 
>>> to avoid the structures involved in a filesystem, and allocate an 
>>> entire 
>>> partition to your database.  Then all you have to worry about is if the 
>>> partition table were to get trashed, so make a backup of block 0 of the 
>>> disk. 
>>> 
>>>     Mark R. 
>>> 
>>> [hidden email] wrote: 
>>> 
>>>> IMHO: 
>>>> EXT2 is great for a database journal in that you won't be double 
>>>> journalling. (I often speculate that a very minimal UNIX file system 
>>>> designed for purely for speed and regularly sized blocks, something 
>>>> like 
>>>> a 
>>>> streamlined FAT system, would be awesome for databases.) 
>>>> 
>> 
>> 
>> 
>