All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
To Journal or not to Journal?
Some Background
So I have a XEN-HVM and a KVM server. Six+ months ago the XEN server was having IO issues (raid resync) so I disabled journaling on the Ext4 filesystem. I saw a huge improvement in IO write speed and significantly less IOwait time. Since then IO speed is back to normal and I'm happy.
Recent Situation
This last week I purchased a KVM container from a provider here and saw a generally high amount of IOwait from the journaling process with a max write speed of around 50-60M/s (killing mysql). Just for kicks I disabled journaling again and saw a relative huge improvement on writes (100-110M/s), almost double in write speed improvements.
I almost feel that I shouldn't need to disable journaling to make a container work, but I'm not complaining.
The Muse
I understand why journaling is needed (saved me a couple of times), but it almost seems like a larger benefit to disable it (since we have raid, hopefully).
Any opinions or comments on journaling?
Comments
Journaling != RAID
A raid card w/ BBU might help with some of the issues journaling addresses but fundamentally they are different problems.
They are completely different, yes. But in my mind the journal's main goal is to make sure data is committed, and committed correctly to the disk in case of fault. If a system is to fault, allow it to fail gracefully.
One of the first uses of RAID was for error correction (to make sure committed data was and is committed correctly). While not fully guaranteeing the safety of the data in case of fault, RAID reduces the chance of faults in general.
So I would say same ideal, different methodologies.
Journaling == RAID
Journaling !== RAID
(Javascript)
RAID has nothing to do with error correction.
And you would still be wrong.
RAID is there solely to protect you from hardware failures - i.e., a disk drive dies. That's it. If you write garbage on top of RAID, you're just protecting the garbage from hardware failure.
Abstractly, both are used to protect data. Both protect data in different ways using different philosophies.
Moving away from the RAID vs journaling, should we journal in general when the penalty is half of IO write speed? Or is there a way to use journaling using one disk while increasing io speed?
@Silvenga the whole thread's question is cringeworthy to be entirely honest. You demonstrate fundamental lack of understanding of both RAID and FS technologies.
Journalling... without it, if your system gets a power cut (or in VM's case the container is stopped without proper shutdown), your FS may be broken, irrepairably. As in, it just doesn't mount anymore, or the OS no longer boots (especially fun on a production server, right?), since half of its files are missing and the other half is partially filled with random funny garbage. While fsck may be able to salvage some pieces of data, it's likely to just place them into numbered files in /lost+found (have parts your FS randomly turned into thousands of files with names like 10002031 10002308 10009020 10005001 etc), but hey at least you get to keep all the pieces. And of course RAID is always there to ensure that you get access to the described horrid state of affairs even if one of your hard disks fails.
Easiest scenario to understand: OS hasn't sent all writes to RAID cache before power is lost. RAID controller BBU ensures that partial writes hit the disk, guaranteeing your volumes are corrupted.
What you are doing is send and forget. This is much like udp connections. In the advent something doesn't align up properly or is lost that chunk of data may become corrupt. In other words. Please no.
Maybe, I'm a software engineer that deals in the abstraction of hardware. I don't normally deal with the FS or hardware level. I just don't like seeing threads locked - waiting for writes to be synchronized if they don't have to be.
Wouldn't a power failure only take out any active writes? If the server isn't writing FS metadata I wouldn't see why the FS would lose the location or structure of files. For example, a database server should only be flushing data into pre-existing files, not modifying the FS file table. That server would only lose active recent commits.
Excuse my ignorance. I guess I'm asking a politically incorrect question - I should use journaling in general except when I have other safeguards. I wonder if compression before writing would be better...
It's not politically incorrect...it's just foolish. There are no stupid questions, and it's better to understand than to assume. It's just that you are comparing two "safeguards" that address different issues. There is no such thing as a free lunch. Disabling journaling will yield performance increases, at the expense of durability.
Oh exactly. Why have a fire extinguisher in the house, when we got a perfectly good first aid kit.
There was I thinking you actually were talking about a journal when I read the title.
*makes an expressivity joke*Dear Diary,
Today I bought another LEB. I promised you I would quit but it was only $15/year. But this time, this one really is my last...
*makes an expropriation joke*