> Could some of the changes in the new linux device drivers have > introduced this same race condition?
What device driver changes are you talking about? Unless you are using OSKit-Mach instead of GNUmach, nothing about the device drivers has changed much at all in a long time. I suspect that you are in fact referring to changes in the Hurd ext2fs filesystem server. In the Hurd, device drivers and filesystems are very separate; in fact, the device drivers are in the Mach kernel, and the filesystems are individual Hurd server programs. > I realize that we don't use ioctl's in the servers, but perhaps they get > called in some way through the C library when running standard Linux > utilities, which results in the rpc analog of this ioctl being invoked. > For example, the "pokel_sync" routine of the ext2fs server seems like a > possible candidate. There is nothing like any of the Linux BLK* ioctls in the Hurd. Moreover, the fundamental design and implementation of things like synchronization issues in filesystems are vastly different in the Hurd than in the Linux kernel. It is certainly the case that there might be a bug of a broadly similar character in the Hurd, but for a thing like this a Linux implementation detail is wholly unrelated to how the Hurd does things. So, your intuitions about this are right in part and also dead wrong. It is the case that some sort of synchronization race issue is surely at the heart of the Hurd's ext2fs corruption problems. It is also right on that pokel_sync is an integral part of how synchronization is handled in the ext2fs server, and that it (or more likely its callers) are in the tangle that produces the filesystem corruption. But to draw a direct parallel between some particular bug fix in the Linux buffer cache infrastructure and what is going on in the Hurd, is straight out of left field. To come equally from left field vis a vis this message, if we suspect a problem in the pokel weirdness (and well we might), then a useful data point to get would be to make an ext2fs with a blocksize of 4096 and see if the filesystem corruption bug can be reproduced on that partition. > I'm attaching the final "successful" patch for your review, in the > hope that it will be helpful. I may never comprehend why people find it necessary to use uuencode or base64-encoded attachments to send a few hundred lines of text. The uuencoding is nearly twice the size of the actual patch, and I have to go out of my way to read it. I did go out of my way and read it, just to make sure it was the sort of thing I thought it was. This is a whole layer of implementation abstraction where Linux and the Hurd share just about nothing at all.
