LWN.net Logo

The return of write barriers

One of the tasks on the 2.5 "to do" list was the implementation of proper write barriers in the block I/O subsystem. Any code which attempts to implement true transactional behavior on disk-based files needs this capability. Without it, systems like journaling filesystems and database managers lack the control they need over the order in which data is written to disk. Mis-ordered writes can lead to data corruption and other unfortunate things.

The 2.6 block I/O subsystem was designed with barrier support as a core feature. But, at this point, most low-level block drivers do not actually implement barriers, and the filesystems do not use them. Patches to fill in some of the gaps have been around for a while (LWN looked at barriers last October), but have not yet been merged.

There has been a new surge of interest in proper barrier support, perhaps as a result of applications vendors starting to take a hard look at the 2.6 kernel. Now Jens Axboe and Chris Mason have put together a new barrier support patch which gets Linux closer to being able to provide real disk I/O guarantees. With this patch, write barriers work, but only on IDE drives (not SCSI or serial ATA), and only with the reiserfs and ext3 filesystems. Even then, things are qualified: "ext3 works but only if things don't go wrong."

In other words, barrier support will be staying on the "to do" list for a little while longer yet. But the work is being done, and 2.6 should be able to implement real barriers before it is all over.


(Log in to post comments)

Nice to see ReiserFS on the list

Posted Mar 26, 2004 1:27 UTC (Fri) by Duncan (guest, #6647) [Link]

As a user whose entire system is reiserfs based, I've been watching current 2.6 kernel
delopments with interest. Until 2.6.5 rcs, most of the journalling fixes seemed to be ext3
only. Now, reiserfs seems to be getting some attention as well. It DOES seem to be
paying off, as current 2.6.5-rc2 seems more stable, at least here on my dual Opteron,
than anything to this point has been, either 2.4 or 2.6 kernel based (well, minus the last
couple 2.4s, as I've switched to 2.6 entirely, now).

Duncan

Nice to see ReiserFS on the list

Posted Mar 26, 2004 6:47 UTC (Fri) by massimiliano (subscriber, #3048) [Link]

What do you mean by "more stable"?
What kind of instability have you seen so far?

I was finally willing to switch to 2.6 (either with
Gentoo, or with the upcoming Fedora), but your comment
is a bit alarming to me...

Ciao,
Massimiliano

P.S. (Totally off topic)
I do not know if you have actually received my reply
to your comment on mono and patents, long ago...
If you wish to answer privately, my address now is
<code> 'massi' . '@' . 'ximian.com' </code>.
The original thread was http://lwn.net/Articles/71030.

ReiserFS and kernel 2.6 (AMD64)

Posted Mar 26, 2004 10:25 UTC (Fri) by Duncan (guest, #6647) [Link]

The ReiserFS instabilities only apply to AMD64, I believe. If you are running x86,
you should be OK. I'm not sure about other 64-bit archs.

AMD64, and I suppose now i86e (Intel's version), are still bleeding edge in a
number of areas, most of them due to "borrowed" x86 code that isn't 64-bit clean --
assumptions about the size of memory pointers being the same as standard 32-bit
integers, etc. Thus, to some extent, anybody on the platform should be used to
working around various issues already. As well, kernel 2.4 is semi-depreciated for
AMD64, so those on the platform should really be switching to 2.6 anyway, as
that's where any real work on the platform is taking place.

Another factor is that of devfs, if you use that. 2.4 devfs support for AMD64 is, I
am told, entirely blacklisted, now, and not even an an option, on newer 2.4 kernels.
The status of devfs in 2.6 is officially depreciated overall, but Andrew Morton has
said it will continue to be supported thru 2.6, anyway, so official withdrawal isn't
going to be until 2.7 devel kernel at least. Still, despite the fact that it's a
Mandrake (and Gentoo) default, I'm not using devfs any more here (on Mandrake,
and hopefully gentoo, soon), entirely 2.6 kernels tho I may be running at this point.
For now, I'm running a static /dev, but Gentoo udev is said to be ready to mount
over /dev now (unless you have devices not yet ported to sysfs, and then there are
workarounds), and Mdk will likely go that route at some point, particularly as they
have an AMD64 port to worry about as well, altho they will I expect stick to devfs
for some time and backport patches as required to the 2.4.23 or whatever last 2.4
kernel that had it for AMD64, so folks can continue to choose 2.4 or 2.6 kernels and
still continue to use supermount and the traditional Mdk devfs based distrib.

The most tracable problem re 2.6 and ReiserFS (again, on AMD64) has been
repeatable kernel lockups when copying a file from a ReiserFS partition to an
Ext2/3 partition, according to the notes at amd64.gentoo.org. Apparently, it's fairly
common for Gentoo users to install Reiserfs on most of their system but put ext2
on /boot, which isn't mounted by default, on gentoo, and I suppose their thinking is
doesn't need the journalling. They recommend using the -notail option when
mounting a reiserfs /boot, tho I don't know why, unless grub, their boot manager of
choice requires it. That hasn't been required by LILO for a good two years at
least, now, and notail of course negates one of the biggest advantages of reiserfs,
efficient storage of small files.

Anyway, my system is 100% reiserfs, so that shouldn't bother me, but I *HAVE*
had instability issues. Part of that I think is alsa driver related, for the on-board
AMD8111 (using i810 alsa driver) sound. Again, apparently some of it hasn't been
64-bit clean.. either that or there are SMP issues or it's a combination of both.
However, while that accounts for over 50% of my problem, the system has
occasionally frozen for no apparent reason when sound was NOT involved
(without X running therefore no environmental sound effects to trigger it, and with
no sound playing at the console). I had until recently attributed it to other apps
and general 64-bit unclean code traces still around, or to SMP, but after I began
seeing the reiserfs connected stuff, I began to suspect that whatever the problem
is/was, copying from reiserfs to ext2/3 is only the most repeatable trigger for a bug
in reiserfs that other things occasionally ALSO trigger (again, at least on this SMP
AMD64 system).

I do know that the latest 2.6.5-rc2 (and rc1, which I missed) kernel has changelog
entries for BOTH the i810 alsa drivers AND reiserfs, and that my system has
seemed MUCH more stable since I installed it. However, part of that may be due
to upgrading some other Mandrake packages, including XMMS, from
AMD64-Cooker (which I keep updated to), and the fact that the XMMS MP3 plugin
isn't working at all right now due again to 32/64-bit issues, meaning I haven't been
hitting the MP3s as hard as I normally do. I still have to get that resolved..

Still, the kernel DOES seem SOMEWHAT more stable, in any case, since I've been
trying to bootstrap gentoo (probably the reason I haven't gotten the Mdk XMMS
thing worked around) and where I was once having kernel lockups (with 2.6.4,
again, on 100% ReiserFS, on SMP AMD64) half-way thru, now I'm getting simple
process segfaults that don't kill the kernel. The last couple of times I've tried it has
segfaulted in exactly the same spot, and I think it is due to one of the earlier
crashes leaving a garbage file. (You probably know by now what the difference
between metadata and data journalling is, and that reiserfs journals metadata, not
data, guaranteeing a consistent file system, but not necessarily that files open at
the time of a crash will not contain garbage data.. To guarantee the data file itself,
you need ext3 set to data journalling, slow but as close to 100% reliable as it gets,
and even then, there are times it may not be 100%, due to actual drive hardware
caching and the like.) Thus, next I am planning to wipe the partitions I was
installing to and start over. However, the point is that I'm no longer getting the
kernel lockups that were preventing the bootstrap compile b4, so the system is
obviously more stable with 2.6.5-rc2 than it was with 2.6.4.

Anyway, 2.6 on x86 should be comparatively stable, reiserfs or not. It's x86_64
that's not, but that's true for the platform in entirety, not just the kernel on it.

..

As for the other exchange on mono, yes, I did, but I didn't really have a lot more to
go on than gut feelings re MS, it's source. Having expressed those, and seeing I
was obviously talking to someone who knew more about the subject than I did, but
it didn't change my gut feeling and there are other alternatives, I had little more to
say.. However, I still remain interested, and events and other stuff I have read of
late has me a bit more optimistic than I was, tho *I* still wouldn't be putting *MY*
eggs in that basket, but I'm not quite so worried about others doing so, if they
judge the risk worth it for them. Like I said, tho, I'm still interested, and sending
you a private e-mail..

I am a bit surprised.. and encouraged, I guess, that you aren't all SuSE and Red
Carpet, now, but are still doing Gentoo and Fedora.. That's a good sign regarding
Novell and recent developments (having just read the Groklaw writeup on
Brainshare today.. that LWN pointed at).

ReiserFS and kernel 2.6 (AMD64)

Posted Mar 27, 2004 12:43 UTC (Sat) by rise (guest, #5045) [Link]

I'm glad to say my experience with ReiserFS on x86-64 has been flawless so far and I hope that I don't encounter any of the problems you're having.  I've run a series of 2.6 kernels with experimental libata versions patched in to support a Silicon Image 3114 SATA RAID contoller, a setup that should have been bleeding edge that's instead been rock stable for me for months.  The SiL3114 has only been in use for part of that time, but no problems there either.  I'm running SuSE 9.0 for x86-64 and now that they've released a patch CD with kernels supporting my controller I'm running their 2.4 series.  Two caveats are that my system rarely runs under heavy load for long sustained periods (though "make -j" on a kernel compile was fun), ALSA is running but unused and I did see what appeared to be a very slow kernel memory leak (yikes) with 2.6 and the very first libata + experimentall SiL3114 support patch combination.  Nothing since though and never a hang or crash.

ReiserFS and kernel 2.6 (AMD64)

Posted Mar 28, 2004 17:26 UTC (Sun) by Duncan (guest, #6647) [Link]

Are you running SMP? I think it might be SMP related as well, and I'm almost
sure PART of the problem was i810 ALSA support, when actively playing.

I DO know 2.6.5-rc2 has been FAR more stable, tho not perfect. I've been
attempting to install Gentoo from a stage-1 compile and not having much luck, but
I'm finally getting somewhere now that I have 2.6.5-rc2 installed. As I mentioned,
it seems to kernel-freeze MUCH less, now, than with 2.6.4 and earlier (incl. the 2.4
kernels I was on originally). (The problem with the Gentoo install now is that I'm
trying to do it a bit more customized than their handbook has instructions for. <g>
However, I'm progressing, and I was compiling kernels back b4 I'd fully switched
from MSWormOS, while I was still booting back to it to do mail as I hadn't even
gotten a Linux mail client set up yet.. So, yes, I'm accustomed to doing it the hard
way right off -- but ending up knowing FAR more about the system for it. <g>
Anyway, I just found a combination of kernel-sources, glibc, kernel-headers, and
nptl, that seem to work, and am rebuilding glibc as I write.. The nptl is the not
directly documented in the manual part of THIS bootstrap... <g>)

Duncan

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds