Re: [RFC] Early flush (was: spindown)
On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
> Daniel Phillips writes:
> > I'd like that too, but what about sync writes? As things stand now,
> > there is no option but to spin the disk back up. To get around this
> > we'd have to change the basic behavior of the block device and
> > that's doable, but it's an entirely different proposition than the
> > little patch above.
>
> I don't care as much about sync writes. They don't seem to happen very
> often on my boxes.
syslog and some editors are the most common users of sync writes. vim, e.g.,
per default keeps fsync()ing its swapfile. Tweaking the configuration of
these apps, this can be prevented fairly easy though. Changing sync semantics
for this matter on the other hand seems pretty awkward to me. I'd expect an
application calling fsync() to have good reason for having its data flushed
to disk _now_, no matter what state the disk happens to be in. If it hasn't,
fix the app, not the kernel.
> > You know about this project no doubt:
> >
> >http://noflushd.sourceforge.net/
>
> Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in
> .h files! As you say, not really lightweight. There must be a better
> way.
noflushd would benefit a lot from being able to set bdflush parameters per
device or per disk. So I'm really eager to see what Daniel comes up with.
Currently, we can only turn kupdate either on or off as a whole, which means
that noflushd implements a crude replacement for the benefit of multi-disk
setups. A lot of the cruft stems from there.
> Also, I suspect (without having looked at the code) that it
> doesn't handle memory pressure well. Things may get nasty when we run
> low on free pages.
It doesn't handle memory pressure at all. It doesn't have to. noflushd only
messes with kupdate{,d} but leaves bdflush (formerly known as kflushd) alone.
If memory gets tight, bdflush starts writing out dirty buffers, which makes the
disk spin up, and we're back to normal.
Regards,
Daniel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: spindown
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote: > Pavel Machek wrote: > > > Isn't this why noflushd exists or is this an evil thing that shouldn't > > > ever be used and will eventually eat my disks for breakfast? > > > > It would eat your flash for breakfast. You know, flash memories have > > no spinning parts, so there's nothing to spin down. > > Btw Pavel, does noflushd work with 2.4.4? The noflushd version 2.4 I > tried said it couldn't find some kernel process (kflushd? I don't > remember) and that I should use bdflush. The manual says that's > appropriate for older kernels, but not 2.4.4 surely. That's because of my favourite change from the 2.4.3 patch: - strcpy(tsk->comm, "kupdate"); + strcpy(tsk->comm, "kupdated"); noflushd 2.4 fixed this issue in the daemon itself, but I had forgotten about the generic startup skript. (Rpms and debs run their customized versions.) Either the current version from CVS, or ed /your/init.d/location/noflushd << EOF %s/kupdate/kupdated/g w q EOF should get you going. Regards, Daniel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
On Sun, Apr 22, 2001 at 04:36:18AM +0200, Jens Axboe wrote:
> On Sun, Apr 22 2001, Alan Cox wrote:
> > > a) Put in lots of bigblock special case code in FAT;
> > > b) teach submit_bh() or generic_make_request() to transparently reblock
> > >bhs < hw_blksize and remove most special cases from FAT. Specifically,
> > >it ought to stop pretending in sb->s_blocksize to use 2k blocks when
> > >the fs is really tied to 512 byte blocks.
> > >
> > > I tend to favour b), but which one is more likely to be accepted?
> >
> > Al Viro suggested c) which was to transparently make it a loopback mount of
> > the raw device and let a loopback layer do the work.
>
> ... which is basically the same thing, in that we need to support writes
> < hardware block size to devices. This is never going to be an efficient
> mechanism, the read gathering required for a 512b write on a 2048b media
> is scary. Think cd-rw 64kB blocksize for write. Ugh.
Here's my stab at reblocking support. I've tested with VFAT filesystems on a
SCSI magneto-optical with 2k hw block size. losetup /dev/loop0 /dev/sda1 &&
mount /dev/loop0 /mnt/mo. read/write/mmap appear to work, but obviously the code
is in dire need for optimisations. What's the reasoning behind never caching bhs
to the underlying blkdev? Using getblk&friends instead of allocating each bh
ourselves and dropping it right afterwards would make the code a lot less
horrible. But I fear someone must have had good reason not to do so. Does
anyone know details? And moreover, does anyone see problems with this change
other than performance woes?
Regards,
Daniel.
--[snip]--
--- loop.c.vanilla Mon Apr 30 21:08:05 2001
+++ loop.c Tue May 1 17:05:32 2001
@@ -49,6 +49,10 @@
* problem above. Encryption modules that used to rely on the old scheme
* should just call ->i_mapping->bmap() to calculate the physical block
* number.
+ *
+ * Added reblocking support for misdesigned filesystems (read: FAT) that make
+ * strong assumptions about the max block size of the underlying device.
+ * Daniel Kobras <[EMAIL PROTECTED]>, May 1st, 2001.
*/
#include
@@ -381,9 +385,16 @@
loop_add_bh(lo, bh);
}
+static void loop_end_io_sync(struct buffer_head *bh, int uptodate)
+{
+ mark_buffer_uptodate(bh, uptodate);
+ unlock_buffer(bh);
+}
+
static struct buffer_head *loop_get_buffer(struct loop_device *lo,
struct buffer_head *rbh)
{
+ int bs;
struct buffer_head *bh;
do {
@@ -396,7 +407,6 @@
} while (1);
memset(bh, 0, sizeof(*bh));
- bh->b_size = rbh->b_size;
bh->b_dev = rbh->b_rdev;
spin_lock_irq(&lo->lo_lock);
bh->b_rdev = lo->lo_device;
@@ -411,10 +421,21 @@
bh->b_page = alloc_page(GFP_BUFFER);
bh->b_data = kmap(bh->b_page);
+ init_waitqueue_head(&bh->b_wait);
+
bh->b_end_io = loop_end_io_transfer;
bh->b_rsector = rbh->b_rsector + (lo->lo_offset >> 9);
- init_waitqueue_head(&bh->b_wait);
+ bs = loop_get_bs(lo);
+
+ if (rbh->b_size >= bs) {
+ bh->b_size = rbh->b_size;
+ return bh;
+ }
+
+ bh->b_size = bs;
+ bh->b_rsector &= ~((bh->b_size>>9) - 1);
+
return bh;
}
@@ -468,9 +489,31 @@
bh->b_private = rbh;
IV = loop_get_iv(lo, bh->b_rsector);
if (rw == WRITE) {
- set_bit(BH_Dirty, &bh->b_state);
- if (lo_do_transfer(lo, WRITE, bh->b_data, rbh->b_data, bh->b_size, IV))
- goto err;
+ if (bh->b_size == rbh->b_size) {
+ set_bit(BH_Dirty, &bh->b_state);
+ if (lo_do_transfer(lo, WRITE, bh->b_data, rbh->b_data,
+rbh->b_size, IV))
+ goto err;
+ } else {
+ /* FIXME. This, of course, is outright ridiculous.
+* We obviously want to cache the bhs. The naive
+* approch simply uses getblk() in loop_get_buffer(),
+* and we'd just call bread() below. But surely the
+* current code has compelling reasons not to do so?
+* loop eating up too many bhs?
+*/
+ unsigned long off;
+ bh->b_end_io = loop_end_io_sync;
+ generic_make_request(READ, bh);
+ lock_buffer(bh);
+ if (!buffer_uptodate(bh))
+ goto err;
+
Re: MO drives (2048 byte block vfat fs) in lk 2.4
On Sun, Apr 22, 2001 at 10:59:18PM -0400, Douglas Gilbert wrote: > One error report stated that a MO drive with a vfat > fs based on 2048 byte sectors can be mounted and read Read? I don't think so. bread, yes, but read follows a NULL pointer and was never seen again. > but any significant write causes a system lockup. I > have been able to replicate this behaviour. Luckily > Alt-SysRq-P did work. Pressing this sequence multiple > times gave similar addresses. Rebooting the machine > and rerunning the experiment multiple time gave > addresses in the same area. bigblock_fat_bread() in fs/fat/buffer.c kmalloc()s 2k dummy bhs for each 512 byte buffer but only partly initialise them. This works as long as those bogus bhs don't leave the fat realm. Unfortunately, generic_file_write and friends call into the generic block layer that wants to do such evil things on bhs as using their wait_queues or checking their state for BH_Locked. None of which are initialised, and while I haven't checked in detail, certainly lead the way into deadlock country. But even if these minor disturbances magically didn't screw you yet, the fat layer will hand out a buffer address calculated for 512 byte buffers for your 2k buffer, and your data goes bye, bye. The preferred fix seems to be to teach the loop device about reblocking and rip all of the bigblock support from fat. I've spent this weekend to cure my utter and complete ignorance of the blkdev layer, in order to be able to implement a working set up at least. Please allow me another couple of days to spare a little hacking time. I'll take care of the issue. Promised. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MO-Drive under 2.4.3
On Fri, Apr 13, 2001 at 02:08:41PM +0100, Alan Cox wrote:
> > I have a problem using my MO-Drive under kernel 2.4.3. I have several disks
> > formated with a VFAT filesystem. Under kernel 2.2.19 everything works fine.
> > Under kernel 2.4.3 I cannot write anything to the disk without hanging the
> > complete system so that I have to use the reset button. For disks with an
> > ext2 filesystem it works okay.
>
> This is a bug in the scsi layer. [EMAIL PROTECTED], not that any of
> the scsi maintainers seem to care about it right now.
Err..., now I'm confused. Last time this issue popped up, it was my
understanding that it's generic_file_{read,write}'s limitation to filesystems
with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
this all moot, or is the SCSI thing just an additional problem?
Regards,
Daniel.
--
GNU/Linux Audio Mechanics - http://www.glame.de
Cutting Edge Office - http://www.c10a02.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops accessing file on 2048 bytes/sector vfat MO in 2.4.0
Moi!
On Fri, 26 Jan 2001, Stefan Meyknecht wrote:
> I receive a Kernel oops while copying a file from MO-drive (vfat) with
> 2048 bytes sector size. There is no problen with ext2 formatted MOs.
>
> I think it happens because the function pointer cfv_file_read of the
> struct cvf_format is initialized with null.
Yup, that's the cause.
> This oops is 100% reproducable with the kernels: 2.4.0, 2.4.1-pre3,
> 2.4.1-pre7 and 2.4.0-ac11 (probably all >= 2.4.0).
... and on a fair number < 2.4.0. The patch below will give you (dog slow)
read access to your FAT MOs. Apply in fs/fat/. And don't even think about
write() and mmap().
Regards,
Daniel.
--[snip]--
--- cvf.c.vanilla Mon Jan 1 22:46:20 2001
+++ cvf.c Mon Jan 1 23:31:23 2001
@@ -51,6 +51,9 @@
const char *buf,
size_t count,
loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos);
+
struct cvf_format default_cvf = {
0, /* version - who cares? */
@@ -92,7 +95,7 @@
default_fat_access,
NULL,
default_fat_bmap,
- NULL,
+ bigblock_fat_file_read,
default_fat_file_write,
NULL,
NULL
--- file.c.vanilla Mon Jan 1 22:46:26 2001
+++ file.c Tue Jan 16 00:15:16 2001
@@ -4,6 +4,9 @@
* Written 1992,1993 by Werner Almesberger
*
* regular file handling primitives for fat-based filesystems
+ *
+ * 2001-1-1 Daniel Kobras <[EMAIL PROTECTED]>:
+ * Added quick&dirty read operation for large sector media.
*/
#define ASC_LINUX_VERSION(V, P, S) (((V) * 65536) + ((P) * 256) + (S))
@@ -114,6 +117,56 @@
return retval;
}
+/* This is a hack. No readahead and other fancy stuff, but hopefully enough
+ * to get MOs working again. [dk]
+ * FIXME: Not sure whether I got error checking right.
+ */
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct inode *inode = filp->f_dentry->d_inode;
+ int phys, pos;
+ struct buffer_head *bh;
+ size_t to_go, done;
+ char *buf_start = buf;
+
+ /* Taken from 2.2 source. */
+ if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode))
+ return -EINVAL;
+
+ if (*ppos > inode->i_size || !count)
+ return 0;
+
+ if (inode->i_size - *ppos < count)
+ count = inode->i_size - *ppos;
+
+ pos = *ppos>>SECTOR_BITS;
+ to_go = SECTOR_SIZE - (*ppos&(SECTOR_SIZE-1));
+ goto _start;
+
+ do {
+ to_go = SECTOR_SIZE;
+_start:
+ phys = fat_bmap(inode, pos++);
+ if (!phys)
+ return -EIO;
+ bh = fat_bread(inode->i_sb, phys);
+ if (!bh)
+ return -EIO;
+ done = to_go > count ? count : to_go;
+ if (copy_to_user(buf, bh->b_data, done)) {
+ fat_brelse(inode->i_sb, bh);
+ return -EFAULT;
+ }
+ fat_brelse(inode->i_sb, bh);
+ buf += done;
+ *ppos += done;
+ } while ((count -= done));
+
+ return buf - buf_start;
+}
+
+
void fat_truncate(struct inode *inode)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
--- inode.c.vanilla Tue Jan 2 00:36:18 2001
+++ inode.c Tue Jan 2 00:22:04 2001
@@ -820,6 +820,9 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
+ /* FIXME: mmap is broken with large hwblocks! [dk] */
+ if (sb->s_blocksize > 512)
+ inode->i_fop->mmap = NULL;
inode->i_mapping->a_ops = &fat_aops;
MSDOS_I(inode)->mmu_private = inode->i_size;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: monitoring I/O
On Tue, 23 Jan 2001, Nicholas Dronen wrote: > Check out the disk_io field in /proc/stat. Which unfortunately provides only some pieces of information Michael wants to gather. SCT's sard patches give you much improved statistics that should basically do what you want. I'm not sure of the current location of the sard patches but as RedHat puts sard in its kernel, it should be available somewhere on redhat.com, I suppose. Check out the sysstat package for userlevel tools. Earlier versions of sard can be found at ftp.uk.linux.org/pub/linux/sct/fs/profiling/ > On Wed, Jan 24, 2001 at 11:52:36AM +1100, Michael McLeod wrote: > > I am hoping someone can give me a little information or point me in the > > right direction. I would like to write an application that monitors I/O > > on a linux machine, but I need some help in determining where to get the > > information I'm looking for. What I would like to do is 'hook' into the > > kernel and record information such as volume name, type of request (read > > or write), the amount of data being read or written, how long each > > transaction takes Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with bigblock support of fat
On Mon, 15 Jan 2001, Robert Reither wrote:
> I encounted really bad problems with 2048 Bytes/sec MO-Drive.
> I'm using an Olympus PowerMO 640.
> MO was formated with FAT32.
>
> i try to read a file from it (used : 'pico /mo/file.txt') ...
> And got a nice crash : Segmentation Fault
Even worse. Trying to read any file on a 2k hwblk FAT yields an oops
actually.
> OK, was easy to find this bug, fs/fat/cvf.c has a bug in bigblock_cvf struct
> the field with the read function was a NULL.
> I changed this to generic_file_read (like with default blocksize), and
> tested it. First seemed to work fine, but :
>
> If i write a file to an empty MO-Disk, the start-cluster is 2 in the
> table. But the real data was written to (and also read from)
> cluster 33 by linux !
The generic routines do not handle the (rather braindead) case of
hwblksize > logical blksize. FAT uses a logical block (sector/whatever
you like to name it) size of 512 byte, which obviously sucks. Now,
generic_file_read miscalculates the blocks it has to get, but in the same
way as generic_file_write, so two errors yield a working setup, but only
for data you wrote with a buggy kernel. You won't be able to access any
previously written data in this way.
A few days ago, I posted the below patch as a quick band-aid to get at
least the read() part back to a working state again. It also disables the
equally dysfunctional mmap() on 2k media. It ought to disable write() as
well, but I didn't bother. Just don't do it. It's probably best to use the
patch to backup your data and reformat your MOs with a sane fs. Run, don't
walk. ;-)
Regards,
Daniel.
--[snip]--
--- cvf.c.vanilla Mon Jan 1 22:46:20 2001
+++ cvf.c Mon Jan 1 23:31:23 2001
@@ -51,6 +51,9 @@
const char *buf,
size_t count,
loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos);
+
struct cvf_format default_cvf = {
0, /* version - who cares? */
@@ -92,7 +95,7 @@
default_fat_access,
NULL,
default_fat_bmap,
- NULL,
+ bigblock_fat_file_read,
default_fat_file_write,
NULL,
NULL
--- file.c.vanilla Mon Jan 1 22:46:26 2001
+++ file.c Tue Jan 16 00:15:16 2001
@@ -4,6 +4,9 @@
* Written 1992,1993 by Werner Almesberger
*
* regular file handling primitives for fat-based filesystems
+ *
+ * 2001-1-1 Daniel Kobras <[EMAIL PROTECTED]>:
+ * Added quick&dirty read operation for large sector media.
*/
#define ASC_LINUX_VERSION(V, P, S) (((V) * 65536) + ((P) * 256) + (S))
@@ -114,6 +117,56 @@
return retval;
}
+/* This is a hack. No readahead and other fancy stuff, but hopefully enough
+ * to get MOs working again. [dk]
+ * FIXME: Not sure whether I got error checking right.
+ */
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct inode *inode = filp->f_dentry->d_inode;
+ int phys, pos;
+ struct buffer_head *bh;
+ size_t to_go, done;
+ char *buf_start = buf;
+
+ /* Taken from 2.2 source. */
+ if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode))
+ return -EINVAL;
+
+ if (*ppos > inode->i_size || !count)
+ return 0;
+
+ if (inode->i_size - *ppos < count)
+ count = inode->i_size - *ppos;
+
+ pos = *ppos>>SECTOR_BITS;
+ to_go = SECTOR_SIZE - (*ppos&(SECTOR_SIZE-1));
+ goto _start;
+
+ do {
+ to_go = SECTOR_SIZE;
+_start:
+ phys = fat_bmap(inode, pos++);
+ if (!phys)
+ return -EIO;
+ bh = fat_bread(inode->i_sb, phys);
+ if (!bh)
+ return -EIO;
+ done = to_go > count ? count : to_go;
+ if (copy_to_user(buf, bh->b_data, done)) {
+ fat_brelse(inode->i_sb, bh);
+ return -EFAULT;
+ }
+ fat_brelse(inode->i_sb, bh);
+ buf += done;
+ *ppos += done;
+ } while ((count -= done));
+
+ return buf - buf_start;
+}
+
+
void fat_truncate(struct inode *inode)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
--- inode.c.vanilla Tue Jan 2 00:36:18 2001
+++ inode.c Tue Jan 2 00:22:04 2001
@@ -820,6 +820,9 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
+ /* FIXME: mmap is broken with large hwblocks! [dk] */
+ if (sb->s_blocksize > 512)
+ inode->
Re: 2.4.0-prerelease & 2048-byte FAT sectors
On Mon, 1 Jan 2001, Alan Cox wrote:
> > Just installed 2.4.0-prerelease, and it looks like FAT
> > filesystems on hardware 2048-byte sectors are still not
> > working.
> > Are there any plans to fix this, or should I consider
>
> Jens was fixing it for CD-ROM devices. I dont know if anyone was fixing
> for M/O devices currently
>
> > such devices obsolete? I'm keeping 2.2.17 around and
>
> Far from obsolete - its a bug.
This patch works good enough for me to get at the data on my MOs. Buyers
beware! I'm completely ignorant to fs issues, so the implementation is
not only dog slow but very probably also buggy. Anyway, it works for me,
and it should be better than the current oops on read(). Maybe Al can have
a quick look at it?
I also disabled mmap for large hw-block devices because the current
implementation yields incorrect results.
Regards,
Daniel.
--[snip]--
--- fs/fat/cvf.c.vanillaMon Jan 1 22:46:20 2001
+++ fs/fat/cvf.cMon Jan 1 23:31:23 2001
@@ -51,6 +51,9 @@
const char *buf,
size_t count,
loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos);
+
struct cvf_format default_cvf = {
0, /* version - who cares? */
@@ -92,7 +95,7 @@
default_fat_access,
NULL,
default_fat_bmap,
- NULL,
+ bigblock_fat_file_read,
default_fat_file_write,
NULL,
NULL
--- fs/fat/file.c.vanilla Mon Jan 1 22:46:26 2001
+++ fs/fat/file.c Tue Jan 2 00:11:01 2001
@@ -4,6 +4,9 @@
* Written 1992,1993 by Werner Almesberger
*
* regular file handling primitives for fat-based filesystems
+ *
+ * 2001-1-1 Daniel Kobras <[EMAIL PROTECTED]>:
+ * Added quick&dirty read operation for large sector media.
*/
#define ASC_LINUX_VERSION(V, P, S) (((V) * 65536) + ((P) * 256) + (S))
@@ -114,6 +117,54 @@
return retval;
}
+/* This is a hack. No readahead and other fancy stuff, but hopefully enough
+ * to get MOs working again. [dk]
+ * FIXME: Not sure whether I got error checking right.
+ */
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct inode *inode = filp->f_dentry->d_inode;
+ int phys, pos;
+ struct buffer_head *bh;
+ size_t to_go, done;
+ char *buf_start = buf;
+
+ /* Taken from 2.2 source. */
+ if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode))
+ return -EINVAL;
+
+ if (*ppos > inode->i_size || !count)
+ return 0;
+
+ if (inode->i_size - *ppos < count)
+ count = inode->i_size - *ppos;
+
+ pos = *ppos>>SECTOR_BITS;
+ to_go = SECTOR_SIZE - (*ppos&(SECTOR_SIZE-1));
+ goto _start;
+
+ do {
+ to_go = SECTOR_SIZE;
+_start:
+ phys = fat_bmap(inode, pos++);
+ if (!phys)
+ return -EIO;
+ bh = fat_bread(inode->i_sb, phys);
+ if (!bh)
+ return -EIO;
+ done = to_go > count ? count : to_go;
+ if (copy_to_user(buf, bh->b_data, done))
+ return -EFAULT;
+ fat_brelse(inode->i_sb, bh);
+ buf += done;
+ *ppos += done;
+ } while ((count -= done));
+
+ return buf - buf_start;
+}
+
+
void fat_truncate(struct inode *inode)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
--- fs/fat/inode.c.vanilla Tue Jan 2 00:36:18 2001
+++ fs/fat/inode.c Tue Jan 2 00:22:04 2001
@@ -820,6 +820,9 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
+ /* FIXME: mmap is broken with large hwblocks! [dk] */
+ if (sb->s_blocksize > 512)
+ inode->i_fop->mmap = NULL;
inode->i_mapping->a_ops = &fat_aops;
MSDOS_I(inode)->mmu_private = inode->i_size;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Notebook disk spindown
On Tue, 12 Sep 2000, Jamie Lokier wrote: > Dave Zarzycki wrote: > > Personally speaking, I always thought it would be nice if the kernel > > flushed dirty buffers right before a disk spins down. It seems silly to me > > that a disk can spin down with writes pending. > > Absolutely. That allows more time spun down too. Pavel Machek sent me a patch for noflushd to do exactly this. Need not be a kernel issue either. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Notebook disk spindown
On Sat, 9 Sep 2000, Tim Brunne wrote: > I think Jamie is right. The nice feature of the old > bdflushd deamon was, that disk writes were possible > without spin up of the disk, because of RAM > buffering. This is achived again by patching the > kernel later than 2.2.10. It is still possible with current kernels. As Jamie pointed out, just use noflushd, available from every debian mirror in the woody tree, or from http://www.tuebingen.linux.de/~s-kod1/noflushd/. This will provide you with the same functionality as the mobile bdflush or update versions on earlier kernels. Still the other proposals regarding noatime or upping the limits on bdflush params make sense and can be used orthogonal to or without noflushd. But note that there's an entirely user-level solution without the need to hack the kernel. Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
