aboutsummaryrefslogtreecommitdiff
path: root/fs/fat/dir.c
AgeCommit message (Collapse)Author
2006-01-09[PATCH] mutex subsystem, semaphore to mutex: VFS, ->i_semJes Sorensen
This patch converts the inode semaphore to a mutex. I have tested it on XFS and compiled as much as one can consider on an ia64. Anyway your luck with it might be different. Modified-by: Ingo Molnar <mingo@elte.hu> (finished the conversion) Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2006-01-08[PATCH] fat: support ->direct_IO()OGAWA Hirofumi
This patch add to support of ->direct_IO() for mostly read. The user of this seems to want to use for streaming read. So, current direct I/O has limitation, it can only overwrite. (For write operation, mainly we need to handle the hole etc..) Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08[PATCH] fat: s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/OGAWA Hirofumi
All EXPORT_SYMBOL of fatfs is only for vfat/msdos. _GPL would be proper. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08[PATCH] fat: use sb_find_get_block() instead of sb_getblk()OGAWA Hirofumi
We don't need to allocate buffer for checking the buffer is uptodate. This use sb_find_get_block() instead, and if it returns NULL it's not uptodate. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] fat: Remove duplicate directory scanning codePekka Enberg
This patch removes duplicate directory scanning code from fs/fat/dir.c. The two functions that share identical code are fat_readdirx() and fat_search_long(). This patch also renames fat_readdirx to __fat_readdir(). Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] fat: cleanup and optimization of checksumOGAWA Hirofumi
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07[PATCH] Speedup FAT filesystem directory readsKarsten Wiese
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> This speeds up directory reads for large FAT partitions, if the buffercache has to be filled from the drive. Following values were taken from: $ time find path_to_freshly_mounted_fat > /dev/null on an otherwise idle system. FAT with 16KB Clusters on IDE attached drive: Factor 2 FAT with 32KB Clusters on USB2 attached drive: Factor 10 (!) Its less than 1/10 slower, if the buffercache is uptodate. The patch introduces the new function fat_dir_readahead(). fat_dir_readahead() calls sb_breadahead() to readahead a whole cluster, if the requested sector is the first one in a cluster. It is usefull to do this, because on FAT directories occupy whole clusters, with the exception of FAT12/FAT16 root dirs. Readahead is only done, if the cluster's first sector is not uptodate to avoid overhead, when the buffer cache is already uptodate. Note that under memory pressure, the maximal byte count wasted (read: has to be red from disk twice) is 1 cluster's size. Thats 64KB. fat_dir_readahead() is called from fat__get_entry(). There is also an unrelated cleanup at one spot: if (bh) brelse(bh); is replaced with: brelse(bh); brelse() can handle NULL pointer arguments by itself. Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!