An error occurred fetching the project authors.
- 27 Jan, 2006 1 commit
-
-
Steve French authored
-
- 18 Jan, 2006 1 commit
-
-
Steve French authored
error path of new cifs_readpages code. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 12 Jan, 2006 1 commit
-
-
Steve French authored
from server when mount forcedirectio. Allowing update of file size with non forcedirectio mounts should be allowed in the fiture but requires carefully writing out the last page in the local file if it is a partial page in order to avoid corruption and careful serialization Thanks to Maximiliano Curia who suggested similar changes and provided a testcase. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 09 Jan, 2006 1 commit
-
-
OGAWA Hirofumi authored
This patch add EXPORT_SYMBOL(filemap_write_and_wait) and use it. See mm/filemap.c: And changes the filemap_write_and_wait() and filemap_write_and_wait_range(). Current filemap_write_and_wait() doesn't wait if filemap_fdatawrite() returns error. However, even if filemap_fdatawrite() returned an error, it may have submitted the partially data pages to the device. (e.g. in the case of -ENOSPC) <quotation> Andrew Morton writes, If filemap_fdatawrite() returns an error, this might be due to some I/O problem: dead disk, unplugged cable, etc. Given the generally crappy quality of the kernel's handling of such exceptions, there's a good chance that the filemap_fdatawait() will get stuck in D state forever. </quotation> So, this patch doesn't wait if filemap_fdatawrite() returns the -EIO. Trond, could you please review the nfs part? Especially I'm not sure, nfs must use the "filemap_fdatawrite(inode->i_mapping) == 0", or not. Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 13 Dec, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 02 Dec, 2005 1 commit
-
-
Steve French authored
memcpy. Part 1 Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 18 Nov, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 20 Oct, 2005 1 commit
-
-
Steve French authored
need to get in ahead of it that depend on that file handle. Fixes occassional bad file handle errors on write with heavy use multiple process cases. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 12 Oct, 2005 2 commits
-
-
Steve French authored
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Steve French authored
New cifs_writepages routine was not updated bytes written in cifs stats. Also added ability to clear /proc/fs/cifs/Stats by writing (0 or 1) to it. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 10 Oct, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 06 Oct, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 05 Oct, 2005 3 commits
-
-
Steve French authored
This allows cifs_writepages to send data in larger chunks from the page cache, without requiring larger memory allocations in other cases. Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Steve French authored
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Steve French authored
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 03 Oct, 2005 1 commit
-
-
Steve French authored
eliminate the double copy, and improve cifs write performance and help the server by upping the typical write size from 4K to 16K (or even larger if wsize set explicitly) for servers which support this. Part 1 of 2 Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 16 Sep, 2005 2 commits
-
-
Steve French authored
we do not request more than negotiated buffer size even if buffer size is small (smaller than one page) Signed-off-by: Steve French (sfrench@us.ibm.com)
-
Steve French authored
Fix some compiler warnings noticed on x64 by me and ppc64 by Shaggy Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 01 Sep, 2005 1 commit
-
-
Steve French authored
Handle small negotiated read sizes (under 4K) and finish up read and write support. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 31 Aug, 2005 1 commit
-
-
Steve French authored
Fix WriteX support for old servers which do not support large files. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 30 Aug, 2005 1 commit
-
-
Steve French authored
This argument was added in a recent patch, but is unnecessary, since the superblock is easily obtained from the dentry. Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 26 Aug, 2005 1 commit
-
-
Steve French authored
The recent change to locks_remove_flock code in fs/locks.c changes how byte range locks are removed from closing files, which shows up a bug in cifs. The assumption in the cifs code was that the close call sent to the server would remove any pending locks on the server on this file, but that is no longer safe as the fs/locks.c code on the client wants unlock of 0 to PATH_MAX to remove all locks (at least from this client, it is not possible AFAIK to remove all locks from other clients made to the server copy of the file). Note that cifs locks are different from posix locks - and it is not possible to map posix locks perfectly on the wire yet, due to restrictions of the cifs network protocol, even to Samba without adding a new request type to the network protocol (which we plan to do for Samba 3.0.21 within a few months), but the local client will have the correct, posix view, of the lock in most cases. The correct fix for cifs for this would involve a bigger change than I would like to do this late in the 2.6.13-rc cycle - and would involve cifs keeping track of all unmerged (uncoalesced) byte range locks for each remote inode and scanning that list to remove locks that intersect or fall wholly within the range - locks that intersect may have to be reaquired with the smaller, remaining range. Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 25 Aug, 2005 1 commit
-
-
Steve French authored
of Read support. Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 24 Aug, 2005 1 commit
-
-
Steve French authored
Make cifs_stats code conditional in the header files to avoid ifdefs in the main code. Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
-
- 21 Aug, 2005 1 commit
-
-
Steve French authored
missing. Most importantly SMB reads were undercounted. Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 24 Jun, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 23 Jun, 2005 1 commit
-
-
Jeremy Allison authored
Signed-off-by: Steve French@sfrench@us.ibm.com Signed-off-by: Jeremy Allison (jra@samba.org)
-
- 13 Jun, 2005 1 commit
-
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com)
-
- 09 Jun, 2005 1 commit
-
-
Steve French authored
and add_to_page_cache fails. Thanks to Shaggy for pointing out the fix. Signed-off-by: Steve French (sfrench@us.ibm.com) Signed-off-by: Shaggy (shaggy@us.ibm.com)
-
- 29 Apr, 2005 3 commits
-
-
Steve French authored
if cifsd thread is no longer running to demultixplex responses. Do not send FindClose request when FindFirst failed without reaching end of search. Signed-off-by: Steve French (sfrench@us.ibm.com) Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com) Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Steve French authored
Protect access to cifs file list in cifs_close path Signed-off-by: Steve French (sfrench@us.ibm.com) Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-