Messages in this thread | | | Date | Mon, 13 Dec 1999 03:42:00 -0500 (EST) | From | Alexander Viro <> | Subject | [CFT][PATCH] symlinks in pagecache. |
| |
Folks, please help testing the patch below. Goodies: * symlinks are cached. * symlink-handling code in filesystems got seriously simplified - almost all code duplication in this area is gone. * due to much smaller stack footprint the limit on the depth of nested symlinks had been raised to 32. And it takes _less_ than it used to do with old limit (5). * interface remains the same - old code will keep working (but switching to the new variant is _good_ idea - it's much simpler). * about -0.8KLOC. Eat that, IBMers ;-)
Summary: * new functions: page_readlink() and page_follow_link(). If you have ->readlink() that places the symlink contents into pagecache at offset 0 - put those as ->readlink() and ->follow_link() and be done with that. In that case stack footprint of lookup_dentry()=>do_follow_link()=> ->follow_link()=>lookup_dentry() is 104 bytes on x86. Compared to ~1Kb in the worst cases in 2.3.30-pre2... * if you are using the above with block_read_full_page() _and_ you support link creation - use block_symlink() to write the link contents (see minix_symlink() for example of usage). * if you have symlink contents in-core and it's not going to go away (autofs, /proc/self, /proc/ide/hda, etc.) - let your ->follow_link() and ->readlink() call vfs_readlink() and vfs_follow_link(). The thing will not be cached (no need to do that), but it will save you some bothering with details. See fs/autofs/symlink.c for example of that.
Remaining problems: * UMSDOS symlinks over DMSDOS. Currently broken (UMSDOS over normal msdosfs should be OK). * UFS still creates only slow symlinks (bug shared with the main tree). It's unrelated to this patch, but related to symlinks ;-) To be fixed RSN. * QNX symlinks are still broken (fix is trivial, but I'ld rather wait for qnx4_get_block()). * Any bugs I haven't catch ;-)
As far as I'm concerned it's damn close to final variant. Unless there are unknown bugs it can go into the main tree as is. The problem being to make sure that there is no such bugs, indeed.
Please, help with testing. It seems to be safe on ext2 and NFS, but the rest of filesystems needs good testing. Things to test: symlink creation, reading and following through. I'm reasonably sure in normal UNIX-like filesystems, but things EFS/HPFS/ISOFS/NCPFS may be trickier. I think that they are OK, but...
The thing definitely builds (minus usual troublemakers - NTFS, HFS, AFFS and QNX4). So there... Patch is too large for l-k and fsdevel, so I'm putting it on ftp.math.psu.edu/pub/viro/as-patch-22. Bug/success reports are more than welcome. Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |