KernelTrap - FUSE

Fuse Writable Mmap

Jeremy — Sat, 17 Nov 2007 03:08:54 +0000

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."

Shadow Directories

Jeremy — Fri, 19 Oct 2007 19:03:52 +0000

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..."

Linux: Batched Writes

Jeremy — Tue, 20 Jun 2006 14:49:14 +0000

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?"

Linux: 2.6.14-rc1, Feature Freeze

Jeremy — Tue, 13 Sep 2005 11:51:38 +0000

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."