From: Miklos S. <mi...@sz...> - 2007-05-28 13:28:48
|
> 1. shared writable mmap. - I saw your patches on the linux-kernel on > feb-28th for this. but i dont see the fixes gone into the mainstream > kernel yet. (is it present in the -mm?) No. > neither do i see it in the > fuse cvs too (obviously since it depends on complementary changes in > the mm/?). Yes, it depends on this: http://lkml.org/lkml/2007/5/10/161 which is not -mm yet. > when can one expect mmap() to work smoothly over files > opened with O_RDWR ? Are there specific applications, which you know to be broken because of the lack of writable mmap? Or is it just an item you want to check off? > 2. fuse_writepages - this i presume will help improve write > performance for filesystems. does this mean that if an application > does write(fd,buf,131072) then filesystem gets entire 128kb, or, even > if application does multipel write(fd,buf,4k) then it would get > aggregated to some extent and filesystem gets an aggregated chunk? No, unfortunately that doesn't work with fuse. The reason is that all file attributes, including size and modification time are accounted in the userspace filesystem, not in the kernel. You can imagine the confusion this could cause if writes are not immediately propagated to userspace. > also same as previous, when will fuse_writepages be available, atleast > in cvs? is this available in some other private repository of yours? > I'm very anxious for this! Why? > 3. is there any way to get inode's i_generation access to the > filesystem? (instead of fuse sending only fuse_ino_t). in glusterfs, > the glusterfs server uses underlying filesystem for storing files and > folders. glusterfs server can detect inode number recycling (reiserfs > does very aggressive inode number recycling) but the glusterfs client > (based on fuse) cannot express whether the inode number sent by the > fuse kernel is the latest or older generation. i also understand that > the generation sent by filesystem to fuse kernel is currently not > being used, correct me if i'm wrong. It's not quite clear to me what your requirements are wrt. the generation number. In the low level library interface ->lookup(), ->mknod(), etc. can supply a generation number to the kernel, which is used to set i_generation, but which is not actually used by the VFS, only for NFS exporting, which is only supported by the out-of-tree fuse module. > 4. the readahead and channel is peaked at 128kb, by changing few thing > in the kernel module (fuse_conn->bdi.ra_pages) i was able to increase > this to bigger readahead value (ofcourse by increasing channel size > too). why is the 128kb hard limit? what is the side-effect of having > ra_pages beyond VM_MAX_READAHEAD pages? can this lead to any issues? I don't really know. Actually there's some current effort to improve the readahead algorithm, so you may be better asking on linux-fsdevel and/or Fengguang Wu in particular. > 5. how can a fuse based filesystem detect if the application did an > fcntl(fd,F_SETFL, O_DIRECT) on an fd which was not opened with > O_DIRECT during the read() and write() operations? it would be > convinient if the fi.flags be set with direct_io for all file based > operations. fcntl(O_DIRECT) should return EINVAL. If not then that's a bug. O_DIRECT is not supported by FUSE, and I don't see any reason to add support. Don't confuse this with the fuse_file_info->direct_io. > 6. (unrelated to fuse) is the VM's readahead careful enough not to > readahead into locked regions (hence causing an wrong 'block' in case > mandatory locks was enabled). taking this to the next level, is there > a trick for a fuse based filesystem detect what part of the read() > request is belonging to a valid application's request and how much is > from the VM's readahead logic (to ensure it doesnt > accidentally+wrongly get blocked into a mandatory locked region held > by another client machine?.) I understand disabling kernel's readahead > is one of the ways around, but kernel's readahead is tremondously > increasing performance by drastically reducing context switches. Hmm, interesting question. ->readpages() doesn't receive any hint about which part of the read is from the application and which is speculative. Possibly the right solution would be to disable readahead on for those files which currently have mandatory locks. But this is not currently possible either. Miklos |