Re: [RFC] Early flush (was: spindown)

2001-06-22 Thread Daniel Kobras
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

Re: spindown

2001-06-22 Thread Daniel Kobras
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 memori

Re: MO-Drive under 2.4.3

2001-05-01 Thread Daniel Kobras
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 fi

Re: MO drives (2048 byte block vfat fs) in lk 2.4

2001-04-23 Thread Daniel Kobras
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

Re: MO-Drive under 2.4.3

2001-04-14 Thread Daniel Kobras
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

Re: Oops accessing file on 2048 bytes/sector vfat MO in 2.4.0

2001-01-27 Thread Daniel Kobras
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 filesy

Re: monitoring I/O

2001-01-24 Thread Daniel Kobras
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

Re: Problems with bigblock support of fat

2001-01-15 Thread Daniel Kobras
01 @@ -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_VERS

Re: 2.4.0-prerelease & 2048-byte FAT sectors

2001-01-01 Thread Daniel Kobras
ault_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 Dani

Re: Notebook disk spindown

2000-09-12 Thread Daniel Kobras
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

Re: Notebook disk spindown

2000-09-09 Thread Daniel Kobras
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