On Wednesday 10 April 2002 09:52 am, Steve Best wrote: > A very large part of extendfs functionality is in the file system, > like 100%. Doing this is user space is going to have some challenges, > like there several items that aren't exported by the file system > (i.e. creating a transaction, .....)
The transaction stuff is meaningless in user-space, and the I/O is handled completely differently as well. Rather than trying to port the kernel code to user space, it would be more logical to use the kernel code as a roadmap to rewrite the same function in user space. I'm sure there would be some useful code that can be found in the jfsutils source to do some of the lower-level functions, i.e. reading the inode allocation map pages via the imap inode's xtree. Here is a version of > jfs_extendfs.c that I'm in the process of porting. It still doesn't > compile yet, hopefully it will soon. > > http://oss.software.ibm.com/developer/opensource/jfs/project/pub/jfs_ >extendfswip.c > > Does the extendfs functionality need to be in user space? or can this > functionality be in the file system and just be called from your user > space program? This is a good question. Once the functionality is in the kernel, is there a need for it to be implemented in user space? Note that at least for now, the kernel function is only going to allow the volume to grow, not to shrink. -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
