Miklos Szeredi posted a request for comments titled "fuse writable mmap design". He explained, "writable shared memory mappings for fuse are something I've been trying to implement forever. Now hopefully I've got it all worked out, it survives indefinitely with bash-shared-mapping and fsx-linux. And I'd like to solicit comments about the approach." He went on to describe the patch:

"fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM. It copies the contents of the original page, and queues a WRITE request to the userspace filesystem using this temp page. From the VM's point of view, the writeback is finished instantly: the page is removed from the radix trees, and the PageDirty and PageWriteback flags are cleared. The per-bdi writeback count is not decremented until the writeback truly completes. [...] On dirtying the page, fuse waits for a previous write to finish before proceeding. This makes sure, there can only be one temporary page used at a time for one cached page."

Jaroslav Sykora posted a series of five patches to handle the kernel portion of what he described as "shadow directories", providing an example which utilized FUSE to access the contents of a compressed file from the command line. His first example was cat hello.zip^/hello.c about which he explained, "the '^' is an escape character and it tells the computer to treat the file as a directory. The kernel patch implements only a redirection of the request to another directory('shadow directory') where a FUSE server must be mounted. The decompression of archives is entirely handled in the user space. More info can be found in the documentation patch in the series."

There were numerous problems suggested. Jan Engelhardt noted, "too bad, since ^ is a valid character in a *file*name. Everything is, with the exception of '\0' and '/'. At the end of the day, there are no control characters you could use." Later in the thread an lwn.net article from a couple years ago was quoted, "another branch, led by Al Viro, worries about the locking considerations of this whole scheme. Linux, like most Unix systems, has never allowed hard links to directories for a number of reasons;" The article had been discussing Reiser4, which treats files as directories. In the current discussion, Al Viro added, "as for the posted patch, AFAICS it's FUBAR in handling of .. in such directories. Moreover, how are you going to keep that shadow tree in sync with the main one if somebody starts doing renames in the latter? Or mount --move, or..."

Hans Reiser [interview] described a recently posted patch as, "it revises the existing reiser4 code to do a good job for writes that are larger than 4k at a time by assiduously adhering to the principle that things that need to be done once per write should be done once per write, not once per 4k." He went on to explain, "this code empirically proves that the generic code design which passes 4k at a time to the underlying FS can be improved. Performance results show that the new code consumes 40% less CPU when doing 'dd bs=1MB .....'" Referring to generic_file_write(), he further noted that currently when writing 64MB of data, "it may go to the kernel as a 64MB write, but VFS sends it to the FS as 64MB/4k separate 4k writes." It was acknowledged that this could also be accomplished in a non-generic way, howevever earlier feedback had suggested that such improvements should be made available to all.

Andrew Morton [interview] responded to the proposed changes saying, "there's nothing which leaps out and says 'wrong' in this. But there's nothing which leaps out and says 'right', either. It seems somewhat arbitrary, that's all." He pointed out that reiser4 was currently the only filesystem to benefit from the changes, "to be able to say 'yes, we want this' I think we'd need to understand which other filesystems would benefit from exploiting it, and with what results?" In the resulting discussion, it was determined that both FUSE [story] and XFS [story] would benefit from these changes prompting Hans to ask, "Is it enough?" Andrew agreed, "Spose so. Let's see what the diff looks like?"

In an email titled "read my lips: no more merges", Linux creator Linus Torvalds announced that the feature freeze, part of the newly improved development process [story], is now in effect for the 2.6.14 kernel. "Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13, and that means that the merge window is closed," Linus explained. "I've released a 2.6.14-rc1, and we're now all supposed to help just clean up and fix everything, and aim for a really solid 2.6.14 release." He went on to add, "be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok?"

As for what was merged, Linus noted that there was "a lot of stuff all over the place." He began by pointing out that "pretty much every architecture got some updates," including alpha, arm, x86, x86-64, ppc, ia64, mips, and sparc. There was also "an absolutely _huge_ ACPI diff, largely because of some re-indentation." Other subsystems listed as receiving updates include drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, pci, pcmcia, scsi, usb, sound driver, and network, "people may appreciate that the most common wireless network drivers got merged - centrino support is now in the standard kernel." Finally, Linus also noted, "on the filesystem level, FUSE got merged, and ntfs and xfs got updated. In the core VFS layer, the 'struct files' thing is now handled with RCU and has less expensive locking."

Andrew Morton [interview] provided an update on the current development status of the Linux kernel. As of his announcement, the latest development release is 2.6.13-git5, with 2.6.14 expected around October 7'th. At this time, Andrew is tracking 144 bugs though he notes, "I haven't culled these yet - some may be fixed." Indeed, a number of replies indicated that several of the listed bugs have been fixed.

As for what will likely be merged in the next couple of weeks and be part of the upcoming 2.6.14 release, Andrew listed several filesystems including relayfs [story], v9fs [story], and FUSE [story]. Regarding the latter he noted that he was, "fed up with arguing - any remaining problems can be fixed up in-tree if anyone can think of how to fix them." As for much anticipated Reiser4, Andrew summarized, "Stuck. Last time we discussed this I asked the reiser4 team to develop and negotiate a bullet-point list of things to be addressed. Once that's agreed to, implement it and then we can merge it. None of that has happened and as far as I know, all the review feedback which was provided was lost."

In response to whether or not he had any objections to merging FUSE [story] into the mainline kernel, Andrew Morton [interview] offered some insight into what new features were slated for the upcoming 2.6.12 kernel. Andrew began, "I was planning on sending FUSE onto Linus in a week or two," going on to add "that and cpusets are the notable features which are 2.6.12 candidates."

Andrew then referred to several other patches currently in his -mm patchset [story], discussing their likelihood of being merged into the mainline kernel. He described crashdump [story] as seeming "permanently not-quite-ready". He noted that perfctr "works fine", but that it was "similar-to-but-different-from" the IA64 perfmon subsystem, and "might not be suitable for ppc64". Both nfsacl [thread] and the device-mapper multipath [thread] patches were deemed "OK for 2.6.12". Regarding cachefs, Andrew noted it "is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help." Finally, regarding whether or not he planned to merge reiser4 [story], he said this was "less clear" going on to add "once all the review comments have been addressed and we start seeing a bit of vendor pull for it, maybe."