Safely spinning down SCSI ReiserFS disk

Safely spinning down SCSI ReiserFS disk

[Greg Ward]

Hi all -- I'd like to make it so my primary disk, which is a very noisy
10000 RPM SCSI disk, spins down at night.  (I also plan to "apm
--suspend" the system immediately after spinning the disk down, so I'm
not worried about normal system activity failing because of a "dead"
disk.  And of course the first thing the system will do when it wakes up
in the morning will be to spin up the disk!)

From searching the list archives, I know I'm not the only one who wants
to do this, but I'm having problems that might be ReiserFS-related.
Specifically, it looks like ReiserFS is trying to write journal data to
the disk after it's spun down, even though I run /bin/sync before the
spindown.

Here's my setup: / is /dev/sda2; the only other partitions on sda are
swap and /scratch.  /home, /var, /tmp, /usr/local are all on that one
partition.  I also have a big (and blissfully quiet) IDE disk at my
disposal.

Here's how I spin the disk down now:

  * create a ramdisk with a few minimal tools -- mainly the
    scsi-spin binary from scsitools 0.3-2 (Debian package)

  * write a script in the ramdisk that runs
      sync
      scsi-spin --force --down /dev/sda
      sleep 5
      scsi-spin --force --up /dev/sda

  * sync and chroot to the ramdisk and run that script in it

The disk spins down fine, and then comes back up -- but any process that
tries to access the disk blocks forever, and there's a "kernel bug" dump
on my console.  At that point I have to reboot -- good thing I built the
"Magic SysRq key" feature into my kernel, since I can't even run the
"reboot" binary!

Is this sort of behaviour expected?  Is there anything more I should be
doing to safely spin down the disk containing ReiserFS filesystems?
Would it be useful if I provided that "kernel bug" dump?  (Maybe I can
write it to my IDE disk before rebooting... hmmm...)

Thanks --

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/

Re: Safely spinning down SCSI ReiserFS disk

[Oleg Drokin]

Hello!

On Sat, Apr 26, 2003 at 05:16:38PM -0400, Greg Ward wrote:

> >From searching the list archives, I know I'm not the only one who wants
> to do this, but I'm having problems that might be ReiserFS-related.
> Specifically, it looks like ReiserFS is trying to write journal data to
> the disk after it's spun down, even though I run /bin/sync before the
> spindown.

By running /bin/sync you seem to access /bin/sync and force atime update on the
/bin/sync

Why don't you just rely on apm --suspend thing that is supposed to spin-down
everything by itself after OS is sleeping?

>   * create a ramdisk with a few minimal tools -- mainly the
>     scsi-spin binary from scsitools 0.3-2 (Debian package)
>   * write a script in the ramdisk that runs
>       sync
>       scsi-spin --force --down /dev/sda
>       sleep 5
>       scsi-spin --force --up /dev/sda
>   * sync and chroot to the ramdisk and run that script in it
> The disk spins down fine, and then comes back up -- but any process that
> tries to access the disk blocks forever, and there's a "kernel bug" dump
> on my console.  At that point I have to reboot -- good thing I built the
> "Magic SysRq key" feature into my kernel, since I can't even run the
> "reboot" binary!

Well, what's the BUG message? We cannot tell you what it means before you
give us this information.

> Is this sort of behaviour expected?  Is there anything more I should be

I don't even know what part of the kernel emits this BUG for you.

> doing to safely spin down the disk containing ReiserFS filesystems?

To safely spin-down the fisk with reiserfs you need to make sure nobody writes/accesses to
the fs when the disk is spun-down (this is only if you want the disk to stay spun-down).
Also when disk spins-up, it must be functional in order to continue the work.
(I believe these requirements are the same for any FS, anyway)

> Would it be useful if I provided that "kernel bug" dump?  (Maybe I can
> write it to my IDE disk before rebooting... hmmm...)

Yes, that might shed some light on what's going on.

Bye,
    Oleg

Re: Safely spinning down SCSI ReiserFS disk

[Greg Ward]

On 28 April 2003, Oleg Drokin said:
> By running /bin/sync you seem to access /bin/sync and force atime
> update on the /bin/sync

That's why I put the necessary binaries (including /bin/sync) on a
ramdisk, and chroot to the ramdisk to run the spindown script.  (I'm not
sure how to do this in the context of APM suspend; for now I'm just
trying to get a spindown/spinup cycle that doesn't crash my computer.)

I realized that I forgot to remount all filesystems readonly, so I'll be
sure to add that next time I give this a try.

> Why don't you just rely on apm --suspend thing that is supposed to spin-down
> everything by itself after OS is sleeping?

That would be nice, but this is a SCSI disk -- as I understand it (from
Googling several times over the past week or so -- this seems to come up
regularly on various lists), Linux does not spinup SCSI disks
automatically on access, and therefore never spins them down
automatically.

At least for my disk, this makes sense: it takes a good 10 sec to spin
the disk down, and roughly as long to spin it up again.  I sure wouldn't
want that to happen outside of my control!

The only way I have found to spin the disk down or up is the scsi-spin
utility, part of the scsitools package.  Obviously this goes on my
chroot ramdisk along with sync!

> Well, what's the BUG message? We cannot tell you what it means before you
> give us this information.

ARghh... I went to great lengths to save this dump to my IDE disk the
last time I experimented, but it seems to have disappeared.  I guess
sync didn't actually sync the IDE disk once the kernel was confused
about the SCSI disk.  (Insert wildy handy-waving speculative gestures
here.)  I'll give it another try now -- see if I can't save the bug dump
to a floppy.

Thanks for your help -- hope I can get some more data soon...

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
I'd like some JUNK FOOD ... and then I want to be ALONE --

Re: Safely spinning down SCSI ReiserFS disk

[Greg Ward]

On 28 April 2003, I said:
> I realized that I forgot to remount all filesystems readonly, so I'll be
> sure to add that next time I give this a try.

This seems to have done the trick.  I had to bring the system to single-user
mode in order to remount / ro; I suspect syslog or some other daemon was
trying to write to / after I spun it down.  I'll post a more detailed recipe
when I'm not so tired.

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
"Very funny, Scotty.  Now beam my *clothes* down."

Re: Safely spinning down SCSI ReiserFS disk

[bscott]

On Mon, 28 Apr 2003, at 8:33pm, gward@python.net wrote:
> ... Linux does not spinup SCSI disks automatically on access ...

  There are kernel patches floating around that add this functionality.  I
used to use them when I ran a SCSI HDD in my home PC.

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |