All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timo Reimann <mailinglist-d4LLFNs4DFRA7UZ8SB9NFg@public.gmane.org>
To: linux-nfs@vger.kernel.org
Subject: mountd prevents spindown of non-exported disk
Date: Wed, 20 Feb 2008 22:52:25 +0100	[thread overview]
Message-ID: <47BCA119.2030404@foo-lounge.de> (raw)

Hi all,

I have two disks in my server, one of them (hda) being used for backups
solely. To reduce noise level and power consumption, I have been trying
to keep it running in standby mode (as opposed to active) most of the time.

Although there should be nothing accessing the disk except my custom
backup cron job initiating at 5am daily, something was constantly
bringing it back into active state after a rough 20-25 minutes. With the
help of blktrace, I monitored every single I/O access to the disk and
found a single process only that would cause the wake-up:


$ sudo blkparse -i hda.blktrace.0
Input file hda.blktrace.0 added
[...]
  3,0    0        6    88.950000000  6806  Q   R 447 + 8 [rpc.mountd]
[...]


So for some reason, rpc.mountd issues this disk request in regular
intervals although nothing on the disk is being NFS-exported according
to /etc/exports.

mountd in debug mode did not yield anything further, so I did another
run with mountd hooked up to strace, and found out that the requests
happen when I NFS-mount my other drive on the server (sda), or if it's
already mounted, access files on sda (read: not hda). I assume the
spinup event can be pinpointed down to calls to stat64 or open on hda:

  open("/dev/mapper/backup-backup1", O_RDONLY) = 12

I should mention at this point that both disks have their partitions set
up facilitating LVM2, and additionally use encryption layers through
dm-crypt/LUKS on top of that. However, both sda and hda are treated in
completely separate physical volumes, respectively, not interweaved in
any way. So any access to sda should not touch hda filesystem-wise.

I'd glad if anyone could help me out by explaining why NFS operations
influence disks that are not participating in a particular operation.
Preferably with a solution how I can have both NFS running on sda and
keep hda asleep unintermittedly.

By the way, I'm using NFSv3.


Cheers,

--Timo

             reply	other threads:[~2008-02-20 22:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 21:52 Timo Reimann [this message]
2008-02-21  4:17 ` mountd prevents spindown of non-exported disk Neil Brown
     [not found]   ` <18364.64328.189954.417159-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-02-21 11:18     ` Timo Reimann
2008-02-22  0:25       ` Neil Brown
     [not found]         ` <18366.5777.25957.73691-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-02-22 20:03           ` Timo Reimann
2008-02-25 14:24     ` Timo Reimann
     [not found]       ` <47C2CFB1.4000004-d4LLFNs4DFRA7UZ8SB9NFg@public.gmane.org>
2008-02-25 15:51         ` Benjamin Coddington
2008-02-26 14:04           ` Timo Reimann
2008-02-25 16:32         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BCA119.2030404@foo-lounge.de \
    --to=mailinglist-d4llfns4dfra7uz8sb9nfg@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.