Here's a patch which is designed to make the kernel play more nicely
with portable computers. I've been using it for a couple of days
and it seems to do the right thing. I'm wondering if anyone has
any comments/suggestions/etc.
To test this code you'll also need
http://www.zip.com.au/~akpm/linux/patches/2.4.20/pdflush-sysctl.patch
(hmm. Server seems to be dead. So the patches are here, as attachments)
Here's the algorithm, from the Documentation/filesystems/proc.txt
section describing /proc/sys/vm/:
laptop_mode
-----------
Setting this entry to '1' will put the kernel's dirty data writeout
algorithms into a mode which is better suited to laptop/notebook
computers. This mode is specifically designed to minimise the
frequency of disk spinups. Laptop mode works as follows:
- Dirty data remains in memory for longer periods of time (controlled
by laptop_writeback_centisecs).
- If there is pending dirty data and the disk is spun up for any
reason (even for a read) then all dirty data will be written back
shortly afterwards. ie: when the disk is spun up, make good use of
it.
- When the decision is made to write back some dirty data, the kernel
will write back all dirty data.
laptop_writeback_centisecs
--------------------------
This tunable determines the maximum age of dirty data when the machine
is operating in Laptop mode. The default value is 30000 - five
minutes. This means that if applications are generating a small amount
of write traffic, the disk will spin up once per five minutes.
If the disk is spun up for any other reason (such as for a read) then
all dirty data will be flushed anyway, and this timer is reset to zero.
laptop_writeback_centisecs has no effect when the machine is not
operating in Laptop mode.
This implementation doesn't try to be very smart - there's a direct
call out of do_ide_request() into the writeback code. This couldn't
be done from within ll_rw_blk.c because then a write to the ramdisk
would spin the disk up. Even as-is, a read from the IDE CDROM
drive will cause the IDE hard disk to spin up and flush data, so
probably that call in do_ide_request() should only be made if the
device is writable. Suggestions are sought, but let's try not to
get too fancy here...
Andrew Morton wrote:
>
> Here's a patch which is designed to make the kernel play more nicely
> with portable computers.
I just had a brainwave. The following text has been added...
Aside: there is another reason why disks spin up more often than
necessary: an application has only read a part of a file, and it needs
to fetch more of that file later on. This commonly happens with the
pagein of executables. To fix this you can increase the readahead
tunable of your disk drive to something enormous (say, one gigabyte):
blockdev --setra 2097152 /dev/hda
Once this is done, the readahead code will effectively read entire
files into memory when the application attempts to read just a small
part of that file. So later access to other parts of that file will
not require another spinup.
-
On Jun 04, 2002 15:54 -0700, Andrew Morton wrote:
> laptop_writeback_centisecs
> --------------------------
>
> This tunable determines the maximum age of dirty data when the machine
> is operating in Laptop mode. The default value is 30000 - five
> minutes. This means that if applications are generating a small amount
> of write traffic, the disk will spin up once per five minutes.
Just FYI, this is probably an optimally bad choice for the default disk
spinup interval, as many laptops spindown timers in the same ballpark.
I would say 15-20 minutes or more, unless there is a huge amount of
VM pressure or something. Otherwise, you will quickly have a dead
laptop harddrive from the overly-frequent spinup/down cycles.
Yes, minutae, I know. Otherwise a nice idea.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Andreas Dilger wrote:
>
> On Jun 04, 2002 15:54 -0700, Andrew Morton wrote:
> > laptop_writeback_centisecs
> > --------------------------
> >
> > This tunable determines the maximum age of dirty data when the machine
> > is operating in Laptop mode. The default value is 30000 - five
> > minutes. This means that if applications are generating a small amount
> > of write traffic, the disk will spin up once per five minutes.
>
> Just FYI, this is probably an optimally bad choice for the default disk
> spinup interval, as many laptops spindown timers in the same ballpark.
> I would say 15-20 minutes or more, unless there is a huge amount of
> VM pressure or something. Otherwise, you will quickly have a dead
> laptop harddrive from the overly-frequent spinup/down cycles.
>
Twenty it is, thanks.
BTW, the "use a gigabyte of readahead" idea would cause VM hysteria
if you access a 600 megabyte file, so I've wound that back to
twenty megs.
Also, it has been suggested that the feature become more fully-fleshed,
to support desktops with one disk spun down, etc. It's not really
rocket science to do that - the `struct backing_dev_info' gives
a specific communication channel between the high-level VFS code and
the request queue. But that would require significantly more surgery
against the writeback code, so I'm fishing for requirements here. If
the current (simple) patch is sufficient then, well, it is sufficient.
-
Andrew Morton writes:
> Setting this entry to '1' will put the kernel's dirty data writeout
> algorithms into a mode which is better suited to laptop/notebook
> computers. This mode is specifically designed to minimise the
> frequency of disk spinups. Laptop mode works as follows:
>
> - Dirty data remains in memory for longer periods of time (controlled
> by laptop_writeback_centisecs).
>
> - If there is pending dirty data and the disk is spun up for any
> reason (even for a read) then all dirty data will be written back
> shortly afterwards. ie: when the disk is spun up, make good use of
> it.
>
> - When the decision is made to write back some dirty data, the kernel
> will write back all dirty data.
Also write out everything just before stopping the disk.
Don't let the disk stop if there is any dirty data.
Am Mittwoch, 5. Juni 2002 01:31 schrieb Andreas Dilger:
> [...]
> Just FYI, this is probably an optimally bad choice for the default disk
> spinup interval, as many laptops spindown timers in the same ballpark.
> I would say 15-20 minutes or more, unless there is a huge amount of
> VM pressure or something. Otherwise, you will quickly have a dead
> laptop harddrive from the overly-frequent spinup/down cycles.
>
What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution.
I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
> Yes, minutae, I know. Otherwise a nice idea.
>
> Cheers, Andreas
Johnny
--snip/snip
> What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution.
> I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
a nice thing for that would be to have unionfs (al viro seems to work on that?),
and mount a ramdisk ontop of your var directory (or shichever directory is
a hotspot. - or mount it over your whole harddrive, doing COW on the ramdisk.
and once the disk reaches a critical high-water-mark sync the whole set to
the underlaying "real" filesystem.
any comments?
tm
--
in some way i do, and in some way i don't.
Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
> Also, it has been suggested that the feature become more fully-fleshed,
> to support desktops with one disk spun down, etc. It's not really
> rocket science to do that - the `struct backing_dev_info' gives
> a specific communication channel between the high-level VFS code and
> the request queue. But that would require significantly more surgery
> against the writeback code, so I'm fishing for requirements here. If
> the current (simple) patch is sufficient then, well, it is sufficient.
Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
could decide what to do.
On Wed, Jun 05 2002, Xavier Bestel wrote:
> Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
>
> > Also, it has been suggested that the feature become more fully-fleshed,
> > to support desktops with one disk spun down, etc. It's not really
> > rocket science to do that - the `struct backing_dev_info' gives
> > a specific communication channel between the high-level VFS code and
> > the request queue. But that would require significantly more surgery
> > against the writeback code, so I'm fishing for requirements here. If
> > the current (simple) patch is sufficient then, well, it is sufficient.
>
> Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> could decide what to do.
And get rid of disk_spun_up(), make it a queue flag instead and signal
the spin up before calling the request_fn instead of shoving it inside
the driver request_fn's.
--
Jens Axboe
Xavier Bestel wrote:
>
> Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
>
> > Also, it has been suggested that the feature become more fully-fleshed,
> > to support desktops with one disk spun down, etc. It's not really
> > rocket science to do that - the `struct backing_dev_info' gives
> > a specific communication channel between the high-level VFS code and
> > the request queue. But that would require significantly more surgery
> > against the writeback code, so I'm fishing for requirements here. If
> > the current (simple) patch is sufficient then, well, it is sufficient.
>
> Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> could decide what to do.
But why?
-
Andrew Morton wrote:
>
> laptop_mode
Great idea!.
>
> This implementation doesn't try to be very smart - there's a direct
> ca
> --- 2.5.20/drivers/ide/ide.c~laptop-mode Tue Jun 4 15:27:54 2002
> +++ 2.5.20-akpm/drivers/ide/ide.c Tue Jun 4 15:27:54 2002
> @@ -1043,6 +1043,7 @@ static void do_request(struct ata_channe
>
> void do_ide_request(request_queue_t *q)
> {
> + disk_spun_up();
> do_request(q->queuedata);
> }
Hugh? Perhaps moving this down to do_request would be
an idea worth consideration?
Le mer 05/06/2002 ? 12:39, Andrew Morton a ?crit :
> Xavier Bestel wrote:
> >
> > Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
> >
> > > Also, it has been suggested that the feature become more fully-fleshed,
> > > to support desktops with one disk spun down, etc. It's not really
> > > rocket science to do that - the `struct backing_dev_info' gives
> > > a specific communication channel between the high-level VFS code and
> > > the request queue. But that would require significantly more surgery
> > > against the writeback code, so I'm fishing for requirements here. If
> > > the current (simple) patch is sufficient then, well, it is sufficient.
> >
> > Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> > could decide what to do.
>
> But why?
e.g. not mess with cdroms, autoalimented disks, some mp3-players seen as
usb-storage, whatever.
I just realized your patch was partly ide-specific, perhaps what I said
doesn't apply ?
Jens Axboe wrote:
>
> On Wed, Jun 05 2002, Xavier Bestel wrote:
> > Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
> >
> > > Also, it has been suggested that the feature become more fully-fleshed,
> > > to support desktops with one disk spun down, etc. It's not really
> > > rocket science to do that - the `struct backing_dev_info' gives
> > > a specific communication channel between the high-level VFS code and
> > > the request queue. But that would require significantly more surgery
> > > against the writeback code, so I'm fishing for requirements here. If
> > > the current (simple) patch is sufficient then, well, it is sufficient.
> >
> > Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> > could decide what to do.
>
> And get rid of disk_spun_up(), make it a queue flag instead and signal
> the spin up before calling the request_fn instead of shoving it inside
> the driver request_fn's.
Then writes to the ramdisk would cause a spinup.
Yes, it could be per-queue. That would add complexity to
the already-murky fs/fs-writeback.c. It that justifiable?
-
On Wed, Jun 05 2002, Andrew Morton wrote:
> Jens Axboe wrote:
> >
> > On Wed, Jun 05 2002, Xavier Bestel wrote:
> > > Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
> > >
> > > > Also, it has been suggested that the feature become more fully-fleshed,
> > > > to support desktops with one disk spun down, etc. It's not really
> > > > rocket science to do that - the `struct backing_dev_info' gives
> > > > a specific communication channel between the high-level VFS code and
> > > > the request queue. But that would require significantly more surgery
> > > > against the writeback code, so I'm fishing for requirements here. If
> > > > the current (simple) patch is sufficient then, well, it is sufficient.
> > >
> > > Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> > > could decide what to do.
> >
> > And get rid of disk_spun_up(), make it a queue flag instead and signal
> > the spin up before calling the request_fn instead of shoving it inside
> > the driver request_fn's.
>
> Then writes to the ramdisk would cause a spinup.
No of course not, that is what the queue flag would say (is this a disk
or not, or something to that effect). Besides, ram disk doesn't even use
a request_fn.
> Yes, it could be per-queue. That would add complexity to
> the already-murky fs/fs-writeback.c. It that justifiable?
I dunno, it's up to you. I guess this is mainly IDE specific anyways,
but you apply the same logic to just one (for instance) of your disks on
a home desktop system.
--
Jens Axboe
On Wed, Jun 05, 2002 at 12:02:07PM +0200, Thomas 'Dent' Mirlacher wrote:
> --snip/snip
[snip/snip the Cc: list too..]
> > What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution.
> > I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
>
> a nice thing for that would be to have unionfs (al viro seems to work
> on that?), and mount a ramdisk ontop of your var directory (or shichever
> directory is a hotspot. - or mount it over your whole harddrive, doing
> COW on the ramdisk. and once the disk reaches a critical high-water-mark
> sync the whole set to the underlaying "real" filesystem.
>
> any comments?
Things like logfile appending...
(Do I need to say more ?)
I myself mount laptop filesystem with noatime option.
Also killing cron/at helps somewhat.
> tm
/Matti Aarnio
On Wed, Jun 05, 2002 at 01:41:28PM +0200, Hans-Christian Armingeon wrote:
> What parts of the filesystem needs to be accessed very often? I
> think, that placing var on a ramdisk, that is mirrored on the
> hd and is synced every 30 minutes, would be a good solution.
> I think, that we should add a sysrq key to save the ramdisk to
> the disk. Is there a similar project, that loads an image into
> a ramdisk at mount, and writes it back at unmount?
It's all there already. Just killall -STOP kupdated, use
sys_readahead() to read your often needed files into pagecache
and SysRq+S to sync, if needed.
Your solution involves copying things twice and using memory
twice, so it is not the right approach.
Andrews point was to control flushing by the power state of the
ide device.
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
On Tue, Jun 04, 2002 at 11:41:57PM -0400, Albert D. Cahalan wrote:
> Also write out everything just before stopping the disk.
> Don't let the disk stop if there is any dirty data.
The kernel doesn't currently do spin-down at all, does it? Andrew,
are you planning to change this? I'm not a kernel programmer, but
it seems like a good idea to me: The kernel could flush writes as
usual while the disk is spun up, but still spin down after a bit if
the rate is low enough. The disk would never spin itself down in
that case. Maybe there are also cases where the kernel would delay
spin-down, if it hasn't started writing but thinks it might soon.
I'm excited to try this. Thanks for writing it against 2.4!
Andrew
On Wed, Jun 05, 2002 at 01:07:35PM -0400, Andrew Pimlott wrote:
> > Also write out everything just before stopping the disk.
> > Don't let the disk stop if there is any dirty data.
> The kernel doesn't currently do spin-down at all, does it? Andrew,
People interested in this should also have a look at noflushd
(http://noflushd.sourceforge.net/), which does something quite
similar. Only problem atm is it doesn't play nice with journalling
filesystems.. The bugs only list reiserfs, but I didn't have any luck with
it on ext3 either a while back.
--
Frank v Waveren Fingerprint: 0EDB 8787
fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 09B9 6EF5 6425 B855
Public key: hkp://wwwkeys.pgp.net/[email protected] 7179 3036 E136 B85D
On Wed, Jun 05, 2002 at 08:04:38PM +0200, Frank v Waveren wrote:
> similar. Only problem atm is it doesn't play nice with journalling
> filesystems.. The bugs only list reiserfs, but I didn't have any luck with
> it on ext3 either a while back.
Oops, it does say it doesn't work with any journaling elsewhere on the
page. my bad.
--
Frank v Waveren Fingerprint: 0EDB 8787
fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 09B9 6EF5 6425 B855
Public key: hkp://wwwkeys.pgp.net/[email protected] 7179 3036 E136 B85D
On Wed, Jun 05, 2002 at 01:07:35PM -0400, Andrew Pimlott wrote:
> On Tue, Jun 04, 2002 at 11:41:57PM -0400, Albert D. Cahalan wrote:
> > Also write out everything just before stopping the disk.
> > Don't let the disk stop if there is any dirty data.
>
> The kernel doesn't currently do spin-down at all, does it? Andrew,
> are you planning to change this? I'm not a kernel programmer, but
> it seems like a good idea to me: The kernel could flush writes as
> usual while the disk is spun up, but still spin down after a bit if
> the rate is low enough. The disk would never spin itself down in
> that case. Maybe there are also cases where the kernel would delay
> spin-down, if it hasn't started writing but thinks it might soon.
>
> I'm excited to try this. Thanks for writing it against 2.4!
At that point, you might as well be in userspace - particularly, you
might as well be running/enhancing noflushd.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
I think a per-disk laptop mode is reasonable... one might have virtual
ATA devices like this 128MB flash chip I have (you plug it right into an
ATA socket, no cables needed. But I also agree that's a limited set of
cases, and the additional complexity may not be worth it.
I've also thought in the past of having a "machine_policy" global
variable, which could indicate to random userspace and kernel code a
"laptop mode" or "file server mode" or "database server mode" etc.
Jeff
Jens Axboe wrote:
>
> ...
> > Yes, it could be per-queue. That would add complexity to
> > the already-murky fs/fs-writeback.c. It that justifiable?
>
> I dunno, it's up to you. I guess this is mainly IDE specific anyways,
> but you apply the same logic to just one (for instance) of your disks on
> a home desktop system.
Well it's a convenience thing. Not really worth a lot of code.
I expect most of the proposed functionality could be provided
from userspace anyway via the disk IO number in /proc/stat:
old_counts=get_counters()
while 1 {
sleep 5
if (old_counts != get_counters()) {
sync
sleep 10
old_counts = get_counters()
}
}
This doesn't have the "if we flushed for any reason, reset the
timer" optimisation. But it will work in 2.4.
So I think I'll just settle for making the ext3 journal timer
expiries tunable.
-
Jeff Garzik wrote:
> I've also thought in the past of having a "machine_policy" global
> variable, which could indicate to random userspace and kernel code a
> "laptop mode" or "file server mode" or "database server mode" etc.
I'm not too sure this level of abstraction is needed by userspace.
It would be enough if the appropriate things were all controlable
in /proc/sys/ etc. and then you just have:
/etc/sysctl.{laptop,server,desktop}.conf
It would be better to have it explicit in userspace as you're
always going to need to tweak things IMHO.
Padraig.
I agree that this level of abstraction is the kernel's job. Deciding this
sort of thing is best left for a user level tool (or the user with 'echo').
A generic set of tunables in /proc/sys/ makes sense, but deciding the best
policy for a given set of parameters is a big problem and would be best
solved outside of the kernel.
This is definitely the sort of thing that can be pushed to the user and
should be.
} I'm not too sure this level of abstraction is needed by userspace.
} It would be enough if the appropriate things were all controlable
} in /proc/sys/ etc. and then you just have:
} /etc/sysctl.{laptop,server,desktop}.conf
} It would be better to have it explicit in userspace as you're
} always going to need to tweak things IMHO.
}
} Padraig.
}
} -
} 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/
Hi!
> > Here's a patch which is designed to make the kernel play more nicely
> > with portable computers.
>
> I just had a brainwave. The following text has been added...
>
>
> Aside: there is another reason why disks spin up more often than
> necessary: an application has only read a part of a file, and it needs
> to fetch more of that file later on. This commonly happens with the
> pagein of executables. To fix this you can increase the readahead
> tunable of your disk drive to something enormous (say, one gigabyte):
This was not required in my configs...
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> laptop_mode
> -----------
>
> Setting this entry to '1' will put the kernel's dirty data writeout
> algorithms into a mode which is better suited to laptop/notebook
> computers. This mode is specifically designed to minimise the
> frequency of disk spinups. Laptop mode works as follows:
>
> - Dirty data remains in memory for longer periods of time (controlled
> by laptop_writeback_centisecs).
>
> - If there is pending dirty data and the disk is spun up for any
> reason (even for a read) then all dirty data will be written back
> shortly afterwards. ie: when the disk is spun up, make good use of
> it.
>
> - When the decision is made to write back some dirty data, the kernel
> will write back all dirty data.
Nice!
> laptop_writeback_centisecs
> --------------------------
>
> This tunable determines the maximum age of dirty data when the machine
> is operating in Laptop mode. The default value is 30000 - five
Well, I run my notebooks in similar mode with writeback set essentialy to
infinity. I do it even on my home server....
> This implementation doesn't try to be very smart - there's a direct
> call out of do_ide_request() into the writeback code. This couldn't
> be done from within ll_rw_blk.c because then a write to the ramdisk
> would spin the disk up. Even as-is, a read from the IDE CDROM
> drive will cause the IDE hard disk to spin up and flush data, so
It would nice to do this per disk.... If you have server with one active
and one inactive disk, you want the inactive one to sleep.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> BTW, the "use a gigabyte of readahead" idea would cause VM hysteria
> if you access a 600 megabyte file, so I've wound that back to
> twenty megs.
Twenty megs is still way too much I believe. Well, definitely way too much
on 32MB machine, and I do not think it is required at all.
> Also, it has been suggested that the feature become more fully-fleshed,
> to support desktops with one disk spun down, etc. It's not really
> rocket science to do that - the
Hi!
> > > Also, it has been suggested that the feature become more fully-fleshed,
> > > to support desktops with one disk spun down, etc. It's not really
> > > rocket science to do that - the
Hi!
> > Yes, it could be per-queue. That would add complexity to
> > the already-murky fs/fs-writeback.c. It that justifiable?
Doing it per-queue is right, doing is per-system is clearly wrong.
> I dunno, it's up to you. I guess this is mainly IDE specific anyways,
SCSI can do spindowns, too, and it *needs* kernel support for that. On
IDE, this can be (in a racy way) done userspace, too.
> but you apply the same logic to just one (for instance) of your disks on
> a home desktop system.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Wed, 5 Jun 2002, Andrew Morton wrote:
> Jens Axboe wrote:
> >
> > On Wed, Jun 05 2002, Xavier Bestel wrote:
> > > Le mer 05/06/2002 ? 01:43, Andrew Morton a ?crit :
> > >
> > > > Also, it has been suggested that the feature become more fully-fleshed,
> > > > to support desktops with one disk spun down, etc. It's not really
> > > > rocket science to do that - the `struct backing_dev_info' gives
> > > > a specific communication channel between the high-level VFS code and
> > > > the request queue. But that would require significantly more surgery
> > > > against the writeback code, so I'm fishing for requirements here. If
> > > > the current (simple) patch is sufficient then, well, it is sufficient.
> > >
> > > Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> > > could decide what to do.
> >
> > And get rid of disk_spun_up(), make it a queue flag instead and signal
> > the spin up before calling the request_fn instead of shoving it inside
> > the driver request_fn's.
>
> Then writes to the ramdisk would cause a spinup.
>
> Yes, it could be per-queue. That would add complexity to
> the already-murky fs/fs-writeback.c. It that justifiable?
Yes, see Zip and USB/Firewire drives. Laptops can have multiple spindles.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Hi!
> > > Yes, it could be per-queue. That would add complexity to
> > > the already-murky fs/fs-writeback.c. It that justifiable?
> >
> > I dunno, it's up to you. I guess this is mainly IDE specific anyways,
> > but you apply the same logic to just one (for instance) of your disks on
> > a home desktop system.
>
> Well it's a convenience thing. Not really worth a lot of code.
> I expect most of the proposed functionality could be provided
> from userspace anyway via the disk IO number in /proc/stat:
noflushd is about that...
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.