From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Fwd: Fwd: VFAT performance.
Date: Fri, 06 Jun 2003 02:54:23 +0900 [thread overview]
Message-ID: <87ptlso1f4.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <20030605141840.C22252@bitwizard.nl>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Rogier Wolff <R.E.Wolff@BitWizard.nl> writes:
> The way to fix this would be to be able to assign a higher cache
> priority (*) to the blocks in the FAT, and to read more than just 4k
> per seek to the FAT.
I tried it by attached *stupid* patch.
copying 500M data
root@devron (x)[1014]# time dd if=/dev/hda6 bs=1M count=500 > /dev/null
500+0 records in
500+0 records out
524288000 bytes transferred in 44.988916 seconds (11653715 bytes/sec)
real 0m45.011s
user 0m0.008s
sys 0m8.723s
2.5.70-bk9
root@devron (a)[1032]# time dd if=file bs=1M count=500 > /dev/null
500+0 records in
500+0 records out
524288000 bytes transferred in 75.510951 seconds (6943205 bytes/sec)
real 1m15.538s
user 0m0.015s
sys 0m16.493s
2.5.70-bk9+patch
root@devron (a)[1024]# time dd if=file bs=1M count=500 > /dev/null
500+0 records in
500+0 records out
524288000 bytes transferred in 52.034399 seconds (10075796 bytes/sec)
real 0m52.041s
user 0m0.006s
sys 0m17.594s
You're right. It seems that that optimization has sufficient effect to
non fragment file. Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fat_test.patch --]
[-- Type: text/x-patch, Size: 2350 bytes --]
fs/fat/cache.c | 22 +++++++++++++++++-----
fs/fat/inode.c | 4 +++-
include/linux/msdos_fs_sb.h | 1 +
3 files changed, 21 insertions(+), 6 deletions(-)
diff -puN fs/fat/cache.c~fat_test fs/fat/cache.c
--- linux-2.5.70/fs/fat/cache.c~fat_test 2003-06-06 01:51:46.000000000 +0900
+++ linux-2.5.70-hirofumi/fs/fat/cache.c 2003-06-06 02:14:49.000000000 +0900
@@ -17,7 +17,7 @@ int __fat_access(struct super_block *sb,
struct msdos_sb_info *sbi = MSDOS_SB(sb);
struct buffer_head *bh, *bh2, *c_bh, *c_bh2;
unsigned char *p_first, *p_last;
- int copy, first, last, next, b;
+ int copy, first, last, next, b, i;
if (sbi->fat_bits == 32) {
first = last = nr*4;
@@ -28,10 +28,22 @@ int __fat_access(struct super_block *sb,
last = first+1;
}
b = sbi->fat_start + (first >> sb->s_blocksize_bits);
- if (!(bh = sb_bread(sb, b))) {
- printk(KERN_ERR "FAT: bread(block %d) in"
- " fat_access failed\n", b);
- return -EIO;
+ bh = NULL;
+ for (i = 0; i < 16; i++) {
+ if (sbi->fat_bh[i]->b_blocknr == b) {
+ bh = sbi->fat_bh[i];
+ break;
+ }
+ }
+ if (bh == NULL) {
+ for (i = 0; i < 16; i++) {
+ brelse(sbi->fat_bh[i]);
+ sbi->fat_bh[i] = sb_bread(sb, b + i);
+ if (sbi->fat_bh[i] == NULL)
+ return -EIO;
+ get_bh(sbi->fat_bh[i]);
+ }
+ bh = sbi->fat_bh[0];
}
if ((first >> sb->s_blocksize_bits) == (last >> sb->s_blocksize_bits)) {
bh2 = bh;
diff -puN fs/fat/inode.c~fat_test fs/fat/inode.c
--- linux-2.5.70/fs/fat/inode.c~fat_test 2003-06-06 01:52:44.000000000 +0900
+++ linux-2.5.70-hirofumi/fs/fat/inode.c 2003-06-06 02:12:45.000000000 +0900
@@ -158,7 +158,9 @@ void fat_clear_inode(struct inode *inode
void fat_put_super(struct super_block *sb)
{
struct msdos_sb_info *sbi = MSDOS_SB(sb);
-
+ int i;
+ for (i = 0; i < 16; i++)
+ brelse(sbi->fat_bh[i]);
fat_clusters_flush(sb);
if (sbi->nls_disk) {
unload_nls(sbi->nls_disk);
diff -puN include/linux/msdos_fs_sb.h~fat_test include/linux/msdos_fs_sb.h
--- linux-2.5.70/include/linux/msdos_fs_sb.h~fat_test 2003-06-06 01:53:11.000000000 +0900
+++ linux-2.5.70-hirofumi/include/linux/msdos_fs_sb.h 2003-06-06 02:01:55.000000000 +0900
@@ -59,6 +59,7 @@ struct msdos_sb_info {
spinlock_t cache_lock;
struct fat_cache cache_array[FAT_CACHE_NR], *cache;
+ struct buffer_head *fat_bh[16];
};
#endif
_
prev parent reply other threads:[~2003-06-05 17:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-05 12:18 Fwd: Fwd: VFAT performance Rogier Wolff
2003-06-05 17:54 ` OGAWA Hirofumi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ptlso1f4.fsf@devron.myhome.or.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=R.E.Wolff@BitWizard.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.