[RFC]
Hi, I tried running oprofile to identify performance bottlenecks of the linux cifs client. I was actually doing the large read from the samba server to the client machine over the gigabit ethernet connection. The results of running oprofile indicated that nearly 70% of samples were attributed to the cifs_readpages() function: of 0x00 (Unhalted core cycles) count 6 warning: could not check that the binary file /cifs has not been modified since the profile was taken. Results may be inaccurate. samples %symbol name 1769068.5951 cifs_readpages 4.3080 cifs_demultiplex_thread 850 3.2960 cifs_writepages 768 2.9780 is_valid_oplock_break 747 2.8966 cifs_closedir 464 1.7992 SendReceive2 338 1.3106 sesInfoFree 255 0.9888 DeleteMidQEntry 255 0.9888 allocate_mid 237 0.9190 decode_negTokenInit 212 0.8221 SendReceive 212 0.8221 wait_for_response 184 0.7135 cifs_fsync 180 0.6980 header_assemble 168 0.6514 CIFSSMBRead 161 0.6243 cifs_close 139 0.5390 cifs_NTtimeToUnix ... Looking further into "opannotate --assembly" results, I noticed that virtually all sample hits were attributed to the "rep movsl %ds:(%esi),%es:(%edi)" instruction : 129d9: mov0x40(%esp),%esi 17187 66.6447 : 129dd: rep movsl %ds:(%esi),%es:(%edi) 4 0.0155 : 129df: subl $0x1000,0x44(%esp) which corresponds to the "memcpy(target, data, PAGE_CACHE_SIZE);" line of the cifs_copy_cache_pages() function, which was inlined by gcc. What this seemed to mean was that we're doing memcpy most of the cifs running time, copying the data from the temporary buffer, allocated from cifs_demultiplex_thread, to the page cache. My first thought was that if we managed to avoid doing this unnecessary copy and read directly from the socket to the page cache, there would be a performance boost on reads. I tried modifying the cifs source code to eliminate that memcpy -- in fact, I only commented out the memcpy line of cifs_copy_cache_pages() just to have an idea how big can be a performance win if we would eliminate an unnecessary copy without updating actual pages... Surprisingly enough, I haven't noticed big differences between unmodified and modified versions (the latter was about 3-5% faster) on copying a big file on the same setup. Are the results of oprofile inaccurate in some way or am I missing something important? The only instruction (memcpy) taking the most of cifs running time seems really odd... Thanks, Kirill - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] isofs: mounting to regular file may succeed
On Sat, Jul 14, 2007 at 09:16:51PM +0200, Jan Engelhardt wrote: > > On Jul 14 2007 03:47, Kirill Kuvaldin wrote: > > > >We then can mount it to a regular file: > > Wow, this is news to me. Since when is it possible to mount files to files? > It is possible to mount a regular file to another one with --bind. The problem in question is that mounting a malformed ISO 9660 image to a directory fails, but to a regular file - succeeds. Kirill - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] isofs: mounting to regular file may succeed
On Sat, Jul 14, 2007 at 03:47:21AM +0400, Kirill Kuvaldin wrote: > $ dd if=correct.iso of=bad.iso bs=4k count=8 Oops, sorry, the right command should be: dd if=correct.iso of=bad.iso bs=4k seek=8 Kirill - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] isofs: mounting to regular file may succeed
It turned out that mounting a corrupted ISO image to a regular file may
succeed, e.g. if an image was prepared as follows:
$ dd if=correct.iso of=bad.iso bs=4k count=8
We then can mount it to a regular file:
# mount -o loop -t iso9660 bad.iso /tmp/file
But mounting it to a directory fails with -ENOTDIR, simply because
the root directory inode doesn't have S_IFDIR set and the condition
in graft_tree() is met:
if (S_ISDIR(nd->dentry->d_inode->i_mode) !=
S_ISDIR(mnt->mnt_root->d_inode->i_mode))
return -ENOTDIR
This is because the root directory inode was read from an incorrect
block. It's supposed to be read from sbi->s_firstdatazone, which is
an absolute value and gets messed up in the case of an incorrect image.
In order to somehow circumvent this we have to check that the root
directory inode is actually a directory after all.
Signed-off-by: Kirill Kuvaldin <[EMAIL PROTECTED]>
diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c
index 5c3eecf..ce5062a 100644
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -840,6 +840,15 @@ root_found:
goto out_no_root;
if (!inode->i_op)
goto out_bad_root;
+
+ /* Make sure the root inode is a directory */
+ if (!S_ISDIR(inode->i_mode)) {
+ printk(KERN_WARNING
+ "isofs_fill_super: root inode is not a directory. "
+ "Corrupted media?\n");
+ goto out_iput;
+ }
+
/* get the root dentry */
s->s_root = d_alloc_root(inode);
if (!(s->s_root))
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
