Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been thinking about ways of speeding up disk I/O, and one of the bottlenecks I keep coming back to is the journal. There's an obvious benefit to using an SSD for the journal - over and above just write caching unless of course I just disable the journal with the write cache (after all devicemapper doesn't seem to support barriers). In order to get the benefits from using a BB write cache on the controller, then I'd need to disable journalling - but then the OS should try to fsck the system after an outage. Of course if the OS knows what's in the batter-backed memory then it could use it as the journal - but that means it must be exposed as a block device and only be under the control of the operating system.

However I've not been able to find a suitable low-cost device (no, write-levelling for Flash is not adequate for a journal, at least one which uses Smartmedia).

While there's no end of flash devices, disk/array controllers with BB write caches, so far I've not found anything which just gives me non-volatile memory addressable as a block storage device.

share|improve this question
This is exactly what the FusionIO devices do, correct? – EEAA Feb 6 '12 at 22:47
@ErikA: Still uses flash - might be using a more effective wear-levelling algorithm however cost is still exorbitant - was thinking more of something like DDRdrive - but even this is 5 x price of a laptop with the same DRAM capacity. – symcbean Feb 7 '12 at 9:12
(or 10X the price of BBRAM write cache) – symcbean Feb 7 '12 at 9:14
It seems Gigbyte used to make exactly what I've described here - marketed as an iRAM drive - – symcbean Feb 8 '12 at 13:31
And there's something called a hyperdrive 5 - – symcbean Feb 8 '12 at 13:40

Could you explain why there's an obvious advantage using SSDs for journals? All FS implement journals as some kind of ring buffer where the access is sequential anyway. Just disable barriers on BBWCs and it's as good as it gets.

EXT3 and EXT4 filesystem used to mount with a journal in 'ordered' mode. In newer Kernels the default is 'write-back' mode. In the'ordered' mode journal updates were committed to disk before any data was written. In 'write-back' mode journal updates are written to the disk according to the normal IO scheduler policies and data writes to disk are not blocked on journal updates. You basically don't see that there's a journal involved at all from the performance POV.

What you want is to disable barriers (and probably mask the FUA and SCSI_CACHE_SYNCHRONIZE SCSI CDBs) on anything that can protect your writes by battery otherwise your performance will suffer. You get the semantics of barriers (or anything that flushes to disks and waits for acknowledgment) on your journal and data by using a BBWC.

A NVRAM without the proper support from the OS (VFS) isn't going to help you with anything that BBWC (which is some kind of NVRAM anyway) cant solve. In Linux 2.4 there was support for certain NVRAM devices for accelerating NFSv2/3 that is running synchronously but BBWCs have made them obsolete.

The proper thing to do with flash devices is to not think of them as a block device and use them as what they are - NAND flash. But this would need a redesign of how we think a file system should talk to the underlying storage in a more generic way. There's also no proper API in place in the Kernel to make use of NAND flash at the moment.

share|improve this answer
Not really. The barriers are there for a reason. Certainly the checksums on ext4 make the late barrier pretty much unecessary - but this is not true for the early barrier, nor for anything other than ext4. Also, most SATA disks have a habit of being less than honest about when blocks are committed from their cache (reordering still occurs). Using write-back on jbd2 seriously compromises the integrity of the journal. And, yes there are device drivers to make proper use of flash memory - that's kind of the point of JFFS2 – symcbean Jun 25 '12 at 22:38
Yes, JFFS2 is one example. I wasn't considering that. But again I understand what you want barriers for or you don't trust your BBWC or have drives that lie to you about the status of their caches which the HBA with BBWCs should disable. – pfo Jun 25 '12 at 22:51
up vote 0 down vote accepted

Only answer so far is that from Nils - but as per my comments, there is the iRAM and hyperdrive devices. So I'll close this off

share|improve this answer

SSD drives should not be used for frequent write operations. Why do you not simply put the journal onto a separate fault-proof RAID system (5 or 10) consisting of ordinary disks (at least 4 "small" ones)?

share|improve this answer
No - flash drives are write limited, so not suitable for frequent writes - they are not the only type of non-volatile solid state storage. – symcbean Feb 29 '12 at 9:35
Right. This is what I wrote. Use a separate RAID of classical harddisks. – Nils Feb 29 '12 at 13:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.