From: Andrew Morton <akpm@linux-foundation.org>
To: ykzhao <yakui.zhao@intel.com>
Cc: hirofumi@mail.parknet.co.jp, linux-fsdevel@vger.kernel.org,
Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH] FAT: Readahead FAT table to reduce the read request of FAT tabl
Date: Fri, 21 Jan 2011 00:38:10 -0800 [thread overview]
Message-ID: <20110121003810.837040ea.akpm@linux-foundation.org> (raw)
In-Reply-To: <1290674797.3948.71.camel@localhost.localdomain>
On Thu, 25 Nov 2010 16:46:37 +0800 ykzhao <yakui.zhao@intel.com> wrote:
> >From badc27e6b5f732191fb3b7e964f68da030144c76 Mon Sep 17 00:00:00 2001
> From: Zhao Yakui <yakui.zhao@intel.com>
> Date: Fri, 19 Nov 2010 10:29:33 +0800
> Subject: [PATCH] FAT: Readahead FAT table to reduce the read request of FAT table
>
> On FAT filesystem the FAT table will be accessed very frequently when
> reading/writing the file. Now it reads only block sector from FAT table every
> time and it will have to wait for the completion of read-access. In fact
> as the FAT table is located sequentially on the disk, maybe we can readahead
> the following sectors to reduce the read access of FAT table.
>
> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> ---
> The following is the test result on SD card/U-disk.
> a. Read/Write a large file by using direct mode on SD card
> dd if=sda.bin of=sda.bin2 bs=64k iflag=direct
> The average copy time can be reduced from 470 second to 452 seconds(The file
> of sda.bin is about 1.8G).
>
> a. Read/Write a large file by using direct mode on U-disk
> dd if=sda.bin of=sda.bin2 bs=64k iflag=direct
> The average copy time can be reduced from about 880 to 855 seconds.(The file
> of sda.bin is about 1.8G).
Seems reasonable.
> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
> index b47d2c9..1dfd73f 100644
> --- a/fs/fat/fatent.c
> +++ b/fs/fat/fatent.c
> @@ -67,6 +67,26 @@ static void fat32_ent_set_ptr(struct fat_entry *fatent, int offset)
> fatent->u.ent32_p = (__le32 *)(fatent->bhs[0]->b_data + offset);
> }
>
> +static void fat_table_readahead(struct super_block *sb, sector_t iphys)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(sb);
> + struct buffer_head *bh;
> + int sec, sec_count;
> +
> + sec_count = sbi->fat_readahead_cnt;
> + /*
> + * It will check whether the current block is already obtained from the
> + * disk. If not, we will try to readahead more sectors when
> + * reading the FAT table
> + */
> + bh = sb_find_get_block(sb, iphys);
> + if (bh == NULL || !buffer_uptodate(bh)) {
> + for (sec = 0; sec < sec_count; sec++)
> + sb_breadahead(sb, iphys + sec);
> + }
> + brelse(bh);
> +}
A few things.
a) I'd like to be really really convinced that there's no way in which
this function can wander off the end of the device. Or that the called
functions handle this situation gracefully.
b) Lots of (old) filesystems probably do block-level readahead like this.
We really should have a generic vfs-layer library function, rather than
open-coding it all the time.
c) sb_breadahead() is a truly ancient function. It would be nice to use
the more modern (and probably more efficient)
force_page_cache_readahead(). It should be OK to pass filp==0.
prev parent reply other threads:[~2011-01-21 8:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 8:46 [PATCH] FAT: Readahead FAT table to reduce the read request of FAT tabl ykzhao
2010-12-03 5:44 ` ykzhao
2010-12-30 1:34 ` ykzhao
2011-01-21 8:38 ` Andrew Morton [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=20110121003810.837040ea.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=yakui.zhao@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).