[rrd-users] rrds on ext2 partition?

[Raimund Berger]

Scott Brumbaugh <scottb at prolexic.com> writes:

> Hi Bernard,
>
> On Mon, Jul 07, 2008 at 04:27:31PM -0700, Bernard Li wrote:
>> In conjunction with the ongoing discussions here and in rrd-developers
>> on "accelerating" rrdtool (either via using RAM/SSD as the underlying
>> storage component) or having an accelerator daemon, I'd like to hear
>> your thoughts on using ext2 as the underlying filesystem for storing
>> the rrds (or any other filesystems).
>> 
>> My current experience is with lots of rrd files on ext3 filesystem
>> which causes high load and high I/O resulting in unusable system.
>> When I put the rrds in an ext2 filesystem, load has dropped
>> dramatically and it still has fairly high I/O, but at least the system
>> is not locked up.
>> 
>> The downside is without the journal, you have the possibility of
>> having data corruption upon power loss, but much could be say about
>> storing data in tmpfs even with periodic syncing of data to persistent
>> store.
>> 
>> Thoughts on this?
>> 
>> P.S. In case you are wondering, rrdtool is used in conjunction with Ganglia.
>> 
>> Cheers,
>> 
>> Bernard
>> 
>
> I would suspect that the journal updates with ext3 would impact
> performance of rrd_update.  Not having experimented much with it,
> there are different ways to mount an ext3 filesystem that treat the
> journal differently.  I have read discussions where it was claimed
> mounting with data=writeback will give better performance with a
> heightened risk of corruption.  There are a lot of links on google
> about it.  Here is one:
>
>    http://www.ibm.com/developerworks/library/l-fs8.html

Yeah, I was about to say the same. The first thing one would want to do
with ext3 is disable atime, i.e. mount the logging partition with
noatime and nodiratime options. The benefit will likely be
proportional to the amount of files you update and (inverse
proportional) to the update interval.

The next thing to consider is writeback journalling. From what I
understand, that means that the filesystem's metadata will still be
journalled but not the file data itself. So on crash file data may get
lost, but the filesystem itself should still be intact and not
corrupted.

Cf. also Linus remarks in this lkml thread
http://kerneltrap.org/node/14148