Dag-Erling Smørgrav wrote: > Alexander Motin <m...@freebsd.org> writes: >> I've just added Power Up In Stand-by (PUIS) feature support into CAM >> ATA in HEAD. It is one of the ways to implement staggered spin-up for >> ATA devices. Now CAM will spin-up no more then 4 of such devices at a >> time. > > Hmm, how does that work? Doesn't the BIOS spin the disks up long before > the kernel even loads? Can you set a flag on the disk to tell it not > to?
It depends. I haven't yet seen BIOS (except hardware RAIDs), supporting staggered spin-up. BIOSes I've tested were unaware of PUIS. They were trying to communicate disks in stand-by state, failing and don't even trying to spin them up. In some cases it may be possible to tell BIOS ignore disks on some ports, or completely disable BIOSes on some controllers, to let OS be the first there. On some controllers I've even seen hardware jumpers controlling BIOS operation. Also, as soon as most (all?) BIOSes are unaware of SATA Port Multipliers, disks on ports except first are not probed by BIOS. So disks on first ports could be configured to spun-up as usual, but others may be set to use PUIS. But even if some advanced BIOS will sometimes support PMP and PUIS, OS still should support it also, to be able to handle hot-plug cases. > This is a very real issue for me. I have a file server that can't cold > boot because the disks take too long to spin up and / or the PSU can't > deliver enough power to spin them all up at the same time. I would love > to be able to delay spinning up each disk until it's actually needed > (i.e. /etc/rc.d/zfs start). CAM will spin-up devices with PUIS enabled during initial bus scan. It will do it in stages and system will wait for the completion. Same is for hot-plug. Also, on my tests, PUIS makes hot-plug process less stressful and more controllable. In that case device becomes ready and responsible almost immediately and spin-up process controlled using regular ATA commands. SCSI implements much better spin-up control, but PUIS looks to be the step in right direction, respecting limitations of ATA protocol. -- Alexander Motin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"