Kernel Traffic #225 For 31 Jul 2003

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test1/2.6.0-test1-mm1/

• Lots of bugfixes.
• A big one-liner from Mark Haverkamp fixes some hanges which were being seen with the aacraid driver and may fix the problem which people have seen on other SCSI drivers: everything getting stuck in io_schedule() under load.
• Another interactivity patch from Con. Feedback is needed on this please - we cannot make much progress on this fairly subjective work without lots of people telling us how it is working for them.

I have been testing interactivity now for for a while. The only symptom (subjective) that I can see is occasional but repeatable (if you get what I mean) video _only_ skips in xine. The audio does not skip. The video skips are very short, only a 4-5 frames at most.

They occur _only_ when performing such operations as rendering a large bitmap to the screen. They do _not_ occur when dragging windows (with contents visible during drag,) nor does CPU load seem to have an effect.

Playing games with nice/renice on xine or on other processes, especially GIMP etc., does not seem to have an effect.

>From this it seems to my limited view that the remaining skips might be XFree86 issues?

Some pertinent details:

2 x P4 Xeon 2.4 Mhz, 512Mb ram.
Radeon VQ + Matrox Mystique.
Premptive kernel
Hyperthreading enabled.
IDE DVD, no SCSI in system.

No problems at all, only minor niggles since 2.5.67. (I have been following -mm patches.)

Thanks for the wonderful work!

One argument i have against it: KDB is incredibly ugly code. Before it could be even considered for merging it would need quite a lot of cleanup. I actually started on porting the KDB backtracer recently to get reliable frame pointer based backtraces, but it turns out the code for that is so complicated and ugly that the chances of ever merging it would be very slim.

KDB is usually not useful for debugging hangs on desktop boxes (and even many servers) because you have usually X running. When the machine crashes and goes in KDB you cannot see the text output and debug anything. I learned to type "go<return>" blind when I had still an KDB aware kernel, but it's not very useful overall.

On a development machine you can avoid that by connecting a serial cable, but that's usually not easily possible for a desktop box. Doing a post-mortem after reboot is more practical. That is what LKCD/mcore do.

Disadvantage is that the current crash dump mechanisms (lkcd, mcore crash, netdump) are all still not very reliable and have horrible error handling. And you can eat a lot of disk space for the dumps and they tend to overflow your file systems. But still it's the only realistic option for "desktop bugs"

BTW debugging on the X server works on linuxppc/mac with xmon because it has a fbcon based console and X server. The debugger can just work on the X background while the X server is stopped. Very nifty. But I don't see the x86 XFree86 switching to a similar fbcon model any time soon, so it's unlikely to help.

Here's a patch to add a quasi-filesystem ("CacheFS") that turns a block device into a general cache for any other filesystem that cares to make use of its facilities.

This is primarily intended for use with my AFS filesystem, but I've designed it such that it needs to know nothing about the filesystem it's backing, and so it may also be useful for NFS, SMB and ISO9660 for example.

Ok. Sounds good. In fact, it's something I've wanted for a while, since it's also potentially the solution to performance-critical things like virtual filesystems based on revision control logic etc (traditionally done with fake NFS servers).

I did a very very quick scan, and didn't see anything that raised my hackles. But it's late in the 2.6.x game, and as a result I'm not going to apply it until I get a lot of feedback from actual users too.

The message containing the patches doesn't seem to have made it into either the LKML or the linux-fsdevel mailing lists.

The basic code can be found in:

http://cvs.infradead.org/cgi-bin/cvsweb.cgi/afs/

In directories:

Documentations/filesystems/
include/linux/
fs/cachefs/

I'll see about putting the patch up for download when I get to OLS.

The following is a straight port of Phillip Lougher's SquashFS (http://squashfs.sf.net). The port is based on squashfs 1.2 for 2.4.20.

The patch is on top of, and tested with, 2.6.0-test1-ac2. It applies cleanly on vanilla 2.6.0-test1 (since -ac2 is mostly bugfixes, there is not much point testing with vanilla, though).

There are four things that are different from the 2.4 version (is there "notes on porting filesystems from 2.4 to 2.6" somewhere, btw?).

• Hooks in init/do_mounts.c to mount things in initramfs seems to have removed (there is no mention of CRAMFS there anymore), so that part of the patch has been removed.
• 2.6 vfs calls dir_ops.readdir without BKL held, and expected to do that itself if needed. The attached port mimics what cramfs/inode.c does differently between 2.4 and 2.6.
• struct super_block in 2.6 vfs has removed the embedded union for filesystem private data. Filesystems are expected to use void *s_fs_info member in it to hang private data in kmalloc'ed memory if needed. The attached port again mimics what cramfs/inode.c does differently between 2.4 and 2.6.
• struct inode in 2.6 vfs has removed the embedded union for filesystem private data. Filesystems with private data now define its own xxx_inode_info struct that embeds struct inode. IOW, containment has become inside out. The attached port defines alloc_inode (and corresponding destroy_inode) members in the super_operations struct, mimicking what ext3/super.c does differently between 2.4 and 2.6.

This is the second round of the port. I have fixed the following, based on suggestions from the list, since the initial patch:

• A couple of character buffers allocated on the stack in the original 2.4 code are allocated with kmalloc(GFP_KERNEL) now.
• A bit more readable Kconfig help message has been added.