Re: New SCSI subsystem in 2.4, and scsi idle patch

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Robert Love]

On Sun, 2001-09-09 at 14:21, Phillip Susi wrote:
> P.S.  I'd like to use a user mode daemon to detect disk idle, and issue the 
> existing ioctl code to spin the disk down, and rely on the kernel to spin it 
> back up as needed.  Isn't there somewhere in /proc that keeps IO counters on 
> the disk I can monitor?  Also, is there a way I could ask the kernel to not 
> flush dirty pages to disk unless it gets a whole lot of them so the disk 
> won't be spun up all the time just to write a few KB?

You can change the behavior of how dirty pages are flushed using
/proc/bdflush.

[18:41:55]rml@phantasy:/proc/sys/vm# cat bdflush 
30	64	64	256	500	3000	60	0	0

Of these 9 parameters, you probably care about the first and sixth.  The
first is percent of buffer full before bdflush kicks in and starts
flushing.  Setting this to 60% is fine, and will work towards your aim.

Note that, Documentation/sysctl/vm.txt is outdated (I will send a patch
off...) this is the correct values of the fields on bdflush:

union bdflush_param {
	struct {
		int nfract;	/* Percentage of buffer cache dirty to 
				   activate bdflush */
		int dummy1;	/* old "ndirty" */
		int dummy2;	/* old "nrefill" */
		int dummy3;	/* unused */
		int interval;	/* jiffies delay between kupdate flushes */
		int age_buffer;	/* Time for normal buffer to age before we flush it */
		int nfract_sync;/* Percentage of buffer cache dirty to 
				   activate bdflush synchronously */
		int dummy4;	/* unused */
		int dummy5;	/* unused */
	} b_un;
	unsigned int data[N_PARAM];
} bdf_prm = {{30, 64, 64, 256, 5*HZ, 30*HZ, 60, 0, 0}};

Finally, I like your idea.  I have an all SCSI system and would like my
disks to spin down. Good luck.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Frank Schneider]

Robert Love schrieb:
> 

(..details...)
 
> Finally, I like your idea.  I have an all SCSI system and would like my
> disks to spin down. Good luck.

I can only agree!
I sleep near a 4-disk-box, and it would be nice if i could spin down the
disks at night...:-)

At the times of 2.0.xy, i also played around with the
"scsi-idle"-package and it worked quite well...but i noticed one effect:
Since i used it the first time, one of my disks spinned down
randomly....it stayed then still for about 10secs and started again...it
had no effect on the system (not even a logentry), but it costed me a
CD-R one time, and so i stopped using "scsi-idle".

I dont know if this was disk-dependant (the disk died some weeks ago
after working for about 3 years, it could have been defect), but it
started after the first use of "scsi-idle"...

But i would be glad to test a new version of "scsi-idle", if you write
one...:-)

Solong..
Frank.

--
Frank Schneider, <SPATZ1@T-ONLINE.DE>.                           
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
... -.-

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Daniel Kobras]

On Sun, Sep 09, 2001 at 06:21:13PM +0000, Phillip Susi wrote:
> I'm trying to get my 2.4.9 system to spin down my scsi disk(s) when idle.  
> Aparently, this is supported on IDE disks, but not SCSI.  I found an old 
> patch to add support for this to the 2.0.34 kernel, and have been trying to 
> use it as a guide to fixing the 2.4.9 kernel.  It seems that major changes 
> have been done to the scsi layer, so I'm a little confused.  Any help is 
> appreciated.  Here is my current status:

I had played around with scsi spinup a couple of months ago but then had to
give away my scsi system, so the patch remained unfinished. Let me dig in the
dust...

Trying to trap NOT_READY was fine, but I believe the tricky part was one
should avoid to allocate a new request for the spinup command. The number
of requests in the queue is limited, so an additional request issued from
an incomplete request might deadlock. So you have to piggyback the spinup
on the original command, catch it when it completes, and re-issue the
command. Some of the error handlers do similar stuff, but clobber a few
entries from the original command. I therefore added new backup fields to
Scsi_Cmnd in scsi.h. The other changes were local to scsi_lib.c, IIRC.

> P.S.  I'd like to use a user mode daemon to detect disk idle, and issue the 
> existing ioctl code to spin the disk down, and rely on the kernel to spin it 
> back up as needed.

As already suggested elsewhere in this thread, please have a look at noflushd
(http://noflushd.sourceforge.net). It implements all the user level features
you describe. The scsi code is disabled by default, however, because of the
lack of spinup support in the standard kernel. The lastest scsi spinup patch
shipped with noflushd applies to kernel 2.3.28. If you cook up a patch that
works with recent kernels, please let me know!

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

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Daniel Kobras]

On Mon, Sep 10, 2001 at 09:33:26AM -0700, idalton@ferret.dyndns.org wrote:
> Noflushd can be useful in this case, though it needs a patch to
> include/linux/kernel_stat.h in order to work with more than one
> IDE disk. More information is at <http://noflushd.sourceforge.net>

Tweaking kernel_stat.h is no longer necessary if you're running recent ac.
Alan merged a patch that exposes significantly more devices to /proc/stat.
I haven't checked if it went into the 2.4.10 pres as well. Unfortunately, the
patch also slightly changed the meaning of some of the entries so you'll
need grab current noflushd-CVS to make it work on the second ide channel.
Still, you might prefer that to patching the kernel. :)

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

Re: New SCSI subsystem in 2.4, and scsi idle patch

[idalton]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Mon, Sep 10, 2001 at 10:10:11AM -0400, Mark Hahn wrote:
> > > I'm trying to get my 2.4.9 system to spin down my scsi disk(s) when idle.  
> 
> remember: normal desktop drives have an expected life of only O(50k) 
> spin up/down cycles.  that's twice an hour for a three year warranty...
> 
> regards, mark hahn.

Noflushd can be useful in this case, though it needs a patch to
include/linux/kernel_stat.h in order to work with more than one
IDE disk. More information is at <http://noflushd.sourceforge.net>

Granted, heavy-use servers probably do not want to spin down so much,
though light-use servers could, with an high idle timeout.

-- 
Ferret

I will be switching my email addresses from @ferret.dyndns.org to
@mail.aom.geek on or after September 1, 2001, but not until after
Debian's servers include support. 'geek' is an OpenNIC TLD. See
http://www.opennic.unrated.net for details about adding OpenNIC
support to your computer, or ask your provider to add support to
their name servers.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Mark Hahn]

> > I'm trying to get my 2.4.9 system to spin down my scsi disk(s) when idle.  

remember: normal desktop drives have an expected life of only O(50k) 
spin up/down cycles.  that's twice an hour for a three year warranty...

regards, mark hahn.

Re: New SCSI subsystem in 2.4, and scsi idle patch

[Alistair Riddell]

On Sun, 9 Sep 2001, Phillip Susi wrote:

> I'm trying to get my 2.4.9 system to spin down my scsi disk(s) when idle.  
> Aparently, this is supported on IDE disks, but not SCSI.  I found an old 

AFAIK, the spinning down of IDE disks is done by the disks themselves
rather than by the kernel. The software support consists of a method to
tell the disk controller what idle period to wait before spinning down.

I don't know whether SCSI disks have a similar feature. But if they did it
would be easier to make use of that than to implemement a software
timer...

-- 
Alistair Riddell - BOFH
IT Manager, George Watson's College, Edinburgh
Tel: +44 131 447 7931 Ext 176       Fax: +44 131 452 8594
Microsoft - because god hates us

New SCSI subsystem in 2.4, and scsi idle patch

[Phillip Susi]

I'm trying to get my 2.4.9 system to spin down my scsi disk(s) when idle.  
Aparently, this is supported on IDE disks, but not SCSI.  I found an old 
patch to add support for this to the 2.0.34 kernel, and have been trying to 
use it as a guide to fixing the 2.4.9 kernel.  It seems that major changes 
have been done to the scsi layer, so I'm a little confused.  Any help is 
appreciated.  Here is my current status:

It looks like the code path I need to modify is in 
drivers/scsi/sd.c:rw_intr().  It looks to me that this function is called 
when the HBA completes an SRB and it decides if it was an error or not, and 
completes it correctly.  I think I need to check for the NOT_READY sense 
status here, and if it is found, try to spin up the disk.  

Now for my questions:  

1) In the old patch, if the spin up failed, it calls 
end_scsi_request, and then requeue_sd_request.  I'm not sure why it tries to 
requeue a failed request, but the it seems that neither of these functions 
exist in the 2.4 kernel.  What should I use instead?

2) If the spin up worked, the old code called requeue_sd_request, I assume to 
send down the original read/write request to the disk now that it is on.  
Once again, what should I use instead of requeue_sd_request to do this?  
There is a comment still in the 2.4 code describing this function, but the 
function itself is not there.  

3) The old code called scsi_do_cmd to send down a START_STOP SRB to the drive 
when it decides it should spin the drive back up.  This function is also no 
longer there, so what should I use to send down the START_STOP SRB?  

P.S.  I'd like to use a user mode daemon to detect disk idle, and issue the 
existing ioctl code to spin the disk down, and rely on the kernel to spin it 
back up as needed.  Isn't there somewhere in /proc that keeps IO counters on 
the disk I can monitor?  Also, is there a way I could ask the kernel to not 
flush dirty pages to disk unless it gets a whole lot of them so the disk 
won't be spun up all the time just to write a few KB?

-- 
--> Phill Susi