I am running out of ideas. Does anyone know how to wake a disk with a non-blocking, and non-caching method? I have tried the following commands: dd if=/dev/sdh of=/dev/null bs=4096 count=1 iflag=direct,nonblock hdparm --dco-identify /dev/sdh (This gets cached after the 3~10th time running) hdparm --read-sector 48059863 /dev/sdh Any ideas? On Wed, Aug 13, 2014 at 9:07 AM, Adam Talbot <ajtalbot1@xxxxxxxxx> wrote: > Arg!! Am I hitting some kind of blocking at the Linux kernel?? No > matter what I do, I can't seem to get the drives to spin up in > parallel. Any ideas? > > A simple test case trying to get two drives to spin up at once. > root@nas:~# hdparm -C /dev/sdh /dev/sdg > /dev/sdh: > drive state is: standby > > /dev/sdg: > drive state is: standby > > #Two terminal windows dd'ing sdg and sdh at the same time. > root@nas:~/dm_drive_sleeper# time dd if=/dev/sdh of=/dev/null bs=4096 > count=1 iflag=direct > 1+0 records in > 1+0 records out > 4096 bytes (4.1 kB) copied, 14.371 s, 0.3 kB/s > > real 0m28.139s ############# WHY?! ################ > user 0m0.000s > sys 0m0.000s > > #A single drive spin-up > root@nas:~/dm_drive_sleeper# time dd if=/dev/sdh of=/dev/null bs=4096 > count=1 iflag=direct > 1+0 records in > 1+0 records out > 4096 bytes (4.1 kB) copied, 14.4212 s, 0.3 kB/s > > real 0m14.424s > user 0m0.000s > sys 0m0.000s > > On Tue, Aug 12, 2014 at 8:23 AM, Adam Talbot <ajtalbot1@xxxxxxxxx> wrote: >> Thank you all for the input. At this point I think I am going to write a >> simple daemon to do dm power management. I still think this would be a good >> feature set to roll into the driver stack, or madam-tools. >> >> As far as wear and tear on the disks. Yes, starting and stopping the drives >> shortens their life span. I don't trust my disks, regardless of >> starting/stopping, that is why I run RAID 6. Lets say I use my NAS with it's >> 7 disks for 2 hours a day, 7 days a week @ 10 watts per drive. The current >> price for power in my area is $0.11 per kilowatt-hour. That comes out to be >> $5.62 per year to run my drives for 2 hours, daily. But if I run my drives >> 24/7 it would cost me $67.45/year. Basically it would cost me an extra >> $61.83/year to run the drives 24/7. The 2TB 5400RPM SATA drives I have been >> picking up from local surplus, or auction websites are costing me $40~$50, >> including shipping and tax. In other words I could buy a new disk every >> 8~10 months to replace failures and it would be the same cost. Drives don't >> fail that fast, even if I was start/stopping them 10 times daily. This is >> also completely ignoring the fact that drive prices are failing. Sorry to >> disappoint, but I am going to spin down my array and save some money. >> >> >> >> >> On Tue, Aug 12, 2014 at 2:46 AM, Wilson, Jonathan >> <piercing_male@xxxxxxxxxxx> wrote: >>> >>> On Tue, 2014-08-12 at 07:55 +0200, Can Jeuleers wrote: >>> > On 08/12/2014 03:21 AM, Larkin Lowrey wrote: >>> > > Also, leaving spin-up to the controller is >>> > > also not so hot since some controllers spin-up the drives sequentially >>> > > rather than in parallel. >>> > >>> > Sequential spin-up is a feature to some, because it avoids large power >>> > spikes. >>> >>> I vaguely recall older drives had a jumper to set a delayed spin up so >>> they stayed in a low power (possibly un-spun up) mode when power was >>> applied and only woke up when a command was received (I think any >>> command, not a specific "wake up" one). >>> >>> Also as mentioned some controllers may also only wake drives one after >>> the other, likewise mdriad does not care about the underlying >>> hardware/driver stack, only that it eventually responds, and even then I >>> believe it will happily wait till the end of time if no response or >>> error is propagated up the stack; hence the time out in scsi_device >>> stack not in the mdraid. >>> >>> >>> >>> > -- >>> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in >>> > the body of a message to majordomo@xxxxxxxxxxxxxxx >>> > More majordomo info at http://vger.kernel.org/majordomo-info.html >>> > >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
