lkml.org 
[lkml]   [1999]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.131 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site