Weekly Edition Return to the Kernel page |
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 kerneldelopments 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 Ciao, P.S. (Totally off topic)
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 almostsure 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
Powered by Rackspace Managed Hosting.